There is a free tool to evaluate your CRA compliance. 

The SAMMY tool.

Sammy grew out of the community behind OWASP SAMM. The tool became the go to tool for OWASP SAMM assessment. The popularity of the tool has led to many more frameworks being added along the years. There are currently 24 frameworks available in SAMMY and one of the latest ones is the CRA Framework.

With the CRA Framework in SAMMY, you can assess CRA compliance for your different products. The questions and quality criteria give you a complete checklist of everything that is required by CRA. SAMMY also makes it easy to compare products groups, manage compliance roadmaps and collaborate with team members. 

Go to SAMMY.codific.com

The CRA Framework in SAMMY

The CRA framework has been created by a team made up of Appsec experts and legal experts from Codific, OWASP and the University of Tilburg. It covers all requirements of the legislation and integrates the provisional horizontal and vertical standards where available.

There are four sections to the CRA Framework:

• Risk Assessment
• Technical Requirements
• Vulnerability Management
• Documentary Obligations

1: Risk Assessment

PR: Product Risk Assessment

The CRA framework mandates the implementation of centralized and quantified product risk profiles. Architects must ensure risks are not just identified but quantified throughout the product life cycle to justify security decisions to regulators.

A validated risk assessment must meet these five sub-requirements:

• The risk assessment defines the intended purpose of the product and considers reasonably foreseeable use and misuse.
• Relevant assets, interfaces, and external dependencies are identified and documented.
• Residual cybersecurity risks are identified, evaluated, and justified against the essential cybersecurity requirements.
• The risk assessment is maintained and updated when changes affect the cybersecurity risk profile of the product.
• The risk assessment is documented and retained in a form that can be provided to market surveillance authorities upon request.

Pro-Tip: Status indicators (e.g., “Partially implemented”) within your CRA tool provide an immediate visual of documentation gaps. By using a centralized tool, you can assign “Improvement” tasks to specific owners, ensuring the risk profile is validated before an external audit.

TM: Threat Modeling for CRA Assessment

Threat modeling is a methodology-driven approach used to identify and manage architectural design flaws. By integrating this into your CRA Assessment, you move security “left,” addressing threats before they are baked into the production code.

Key requirements for threat modeling include:

• Considering relevant data flows and trust boundaries, including interactions with external systems and services.
• Utilizing a defined methodology to systematically identify threats and assess design weaknesses.
• Ensuring identified threats and mitigations are traceable to security requirements and architectural decisions.
• Reviewing and updating threat models when changes occur that affect the threat landscape.
• Documenting outcomes and retaining them as part of the technical file.

Pro-Tip: Use your CRA tool to manage the “Next Evaluation Cycle.” Rather than a one-time check, the tool reminds teams to revisit threat models during major version updates, preventing the documentation from becoming obsolete as the product evolves.

Go to SAMMY.codific.com

2: Technical Requirements

SR: Security Requirements and the CRA Tool

Security requirements must be clearly defined and prioritized. The CRA framework requires teams to derive these from Annex 1 Part 1, specifically addressing outcomes like access control, encryption, data minimization, and mandatory features such as factory resets.

Architects must ensure requirements are SMART (Specific, Measurable, Actionable, Relevant, and Time-bound). A digital CRA tool is essential here to track these metrics across the development lifecycle, ensuring that an “agreed-upon structured notation” is maintained for all security artifacts.

AD: Architecture Design

Secure design requires the application of fundamental principles: least privilege, defense in depth, fail-secure mechanisms, and component authentication. The CRA mandates that these principles are documented and stored in an accessible location. From an architectural perspective, this accessibility is vital for cross-functional teams to prevent “design drift” where the final implementation deviates from the intended secure architecture.

TPD: Third-Party Dependencies

Manufacturers must manage the risks of external components through a formal process. A CRA tool automates much of this burden by:

• Maintaining a live Bill of Materials (BOM) for every product.
• Enforcing a list of approved dependencies based on security criteria.
• Automatically evaluating dependencies for newly disclosed vulnerabilities (CVEs) and alerting staff.
• Documenting reporting processes to upstream maintainers and implementing compensating controls where dependencies cannot be fully secured.

RT: Requirements Testing

Testing confirms that security controls like authentication and encryption work as expected. Verification must occur whenever the product’s implementation changes. Your tool must retain all test results—including failures and resolutions—as version-linked evidence to prove compliance during market surveillance.

CH: Configuration Hardening

To minimize the attack surface, architects must harden configurations for every technology stack component. This involves identifying key components, defining secure baselines to prevent unauthorized access, and continuously identifying and correcting deviations from those baselines.

Go to SAMMY.codific.com

3: Vulnerability Management

ID: Incident Detection

The CRA requires a repeatable approach to log data analysis. Products must log security-relevant events with sufficient detail to support investigations. Critically, log retention periods and storage security must be defined and aligned with the product’s support period and risk profile. Analysis frequency must remain commensurate with the product’s criticality.

IR: Incident Response

Manufacturers must establish a formal process for reporting “actively exploited vulnerabilities” and severe incidents. This includes:

• Publishing a Coordinated Vulnerability Disclosure (CVD) policy with guidance for external reporters.
• Meeting strict timelines for notifying relevant authorities about actively exploited vulnerabilities, in accordance with regulatory requirements.
• Specifying user notification channels and content.
• Conducting post-incident reviews for high-severity events to update the risk assessment.

DM: Defect Management

Security defects must be centrally tracked and linked to specific product versions. Architects must distinguish between internal escalation paths (for internal remediation) and mandatory reporting to authorities for exploited defects. A consistent risk-based methodology must evaluate the likelihood and impact of these defects under realistic operating conditions.

ST: Security Testing

Compliance necessitates both automated testing integrated into the CI/CD pipeline and manual penetration testing performed by qualified personnel. All findings must be risk-assessed and resolved according to defined remediation timelines.

PU: Patching and Updating

Manufacturers must monitor relevant sources (OS, container images, packages) for vulnerabilities in the runtime environment. Remediation actions must be prioritized based on exploitation likelihood and delivered without undue delay.

SD: Secure Deploy

The update delivery mechanism must be reliable, ensuring integrity and authenticity. The product must support timely updates (automated or user-initiated) and, where technically feasible, users must be informed when a product has reached its end-of-support date.

Go to SAMMY.codific.com

4: Documentary Obligations

TD: Technical Documentation

Technical files must be finalized and version-controlled before market entry. These files must include risk assessments, BOMs, and test results. Crucially, the CRA allows for efficiency: where product families share documentation, the files must clearly identify which variants are covered and document any variant-specific differences. All documentation must be stored in a central repository with a clear audit trail.

UD: User Documentation (Annex II)

In accordance with Annex II, user documentation must provide:

• Clear product identification (type, version, batch).
• Step-by-step guidance to achieve a secure-by-default state.
• The exact end-of-support date (minimum month and year) in a prominent location.
• Instructions for reporting security issues and installing updates.
• Guidance for downstream integrators regarding residual risks.

PD: Product Documentation (DoC & CE)

The final milestone for EU Market Access involves:

• Issuing a signed Declaration of Conformity (DoC).
• Affixing the CE marking in a visible, legible manner.
• Ensuring the DoC is publicly accessible via a URL.
• Retaining third-party conformity assessment reports or certificates alongside the DoC for products that require them.

Mapping to and from different frameworks.

If you have already done a SAMM assessment in SAMMY you already have a lot of processes inventorized. You can use SAMM assessment to prepopulate your CRA assessment, and vice versa.

The goal of SAMMY is to be a centralized inventory of the applications security posture, and automate all compliance efforts. Check out the latest community call to learn more about the SAMMY Roadmap.

Go to SAMMY.codific.com

Not sure if your product is in scope?

Use the CRA Scope Assessment tool to find out in 3 minutes.