From NIST SSDF to CRA Compliance

Julian Meroi · Published 30 September 2026 · Last reviewed 30 September 2026

If your team already builds software to NIST’s Secure Software Development Framework, some of what the Cyber Resilience Act asks you to show may already exist somewhere in your development records. The work is deciding which of it counts, for which product, and what is still missing.

This page maps specific SSDF tasks onto specific CRA provisions, says what each one can contribute as evidence, and says plainly where it stops.

Who this is for, and what it assumes

You are a US company placing software or a product with digital elements on the EU market, you run an SSDF program, and you want to know how much of it is reusable. The page assumes the practices are implemented and operating. A policy that names the framework is not enough on its own.

Two things decide everything that follows, and neither is a development question:

• Which product, and which legal entity. The CRA applies to products with digital elements made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network (Article 2), and Article 3 defines what counts as a product and what counts as remote data processing. A development process that follows SSDF tells you nothing about whether a given offering is in scope.
• Which category the product falls into, which decides your conformity assessment route (Article 7, Article 8 and Article 32). Category follows the product’s core functionality. SSDF maturity is not a category test.

Which versions this maps

• NIST SP 800-218, SSDF version 1.1, final, February 2022. Every task ID and page number below refers to that document.
• SSDF 1.2 exists as an initial public draft (SP 800-218 Rev. 1, December 2025). It is not mapped here, and its task wording is deliberately not mixed in. Status as at 2026-09-29.
• Regulation (EU) 2024/2847, the CRA, as published in the Official Journal.

What your SSDF program can contribute

Each group below names the SSDF tasks, the CRA provision the evidence speaks to, and the part the SSDF task does not reach. Treat every row as potential reuse: it still depends on the product in scope, the release, whether the practice actually ran, and the quality of what it produced.

Security requirements and risk assessment

SSDF: PO.1.2 (p.5), PW.1.1 and PW.1.2 (p.11).

Your documented software security requirements, threat models, and the record of risks and design decisions speak directly to Article 13(2) and 13(3), and belong in the technical documentation under Annex VII(3).

What to check: Article 13(3) requires the risk assessment to state whether and how each requirement in Annex I Part I(2) applies to this product, and how it is implemented. Where a requirement does not apply, Article 13(4) requires a clear justification in the technical documentation. Check whether your threat model answers that requirement by requirement. Article 13(3) also sets the minimum content: intended purpose, reasonably foreseeable use, conditions of use such as the operational environment and the assets to be protected, and the length of time the product is expected to be in use.

Third-party components and the SBOM

SSDF: PO.1.3 (p.5), PW.4.1 (p.12), PW.4.4 (p.13), PS.3.2 (p.10).

Supplier criteria, component review records, dependency monitoring and your component provenance data speak to Article 13(5) on due diligence for integrated components, and to Annex I Part II(1) on the software bill of materials.

Three points to check:

• PO.1.3 covers requirements communicated to third parties providing commercial components. Open-source and other third-party components are expressly covered by PW.4.1 and PW.4.4. Article 13(5) requires due diligence for all integrated third-party components, including free and open-source components that were not made available in the course of a commercial activity, so check that your component reviews reach every component in the shipped product.
• Article 13(6) adds a duty SSDF does not: when you identify a vulnerability in an integrated component, you report it to the person or entity manufacturing or maintaining that component, and where you have developed a fix, you share the relevant code or documentation with them.
• PS.3.2 names an SBOM as an example of provenance data. The CRA is specific: a commonly used, machine-readable format, covering at least the top-level dependencies. Check your format and depth against that before treating an existing inventory as sufficient.

Design review, code review and testing

SSDF: PW.2.1 (p.12), PW.7.2 (p.14), PW.8.2 (p.15).

Design review by qualified people not involved in the design, by automated toolchain processes, or both, together with code review and analysis and scoped testing with recorded and triaged findings, are the natural evidence for Annex I Part II(3), which requires effective and regular tests and reviews of the product’s security, and for Annex VII(6), which asks for the reports of the tests carried out to verify conformity.

Annex VII(6) covers conformity of both the product and the vulnerability handling processes, so a test report that only exercises product features leaves half the item unanswered. Tool output on its own does not establish conformity. Article 13(8) applies the Annex I Part II requirements for the support period, so plan the tests and reviews to recur across it.

Secure defaults and release integrity

SSDF: PW.9.1 and PW.9.2 (p.16), PS.2.1 (p.10).

A defined secure baseline, the implemented default settings and the administrator documentation speak to Annex I Part I(2)(b), which requires products to be made available with a secure by default configuration, subject to a qualification for tailor-made products agreed with a business user.

Two cautions:

• Part I(2)(b) also concerns the possibility of resetting the product to its original state. Check both settings and reset behavior against the delivered product.
• Release integrity information under PS.2.1 is a contribution to Annex VII(2)(b), which asks for a description of the technical solutions chosen for the secure distribution of updates. It is not by itself evidence for Annex I Part II(7), which is about the distribution mechanism working: updates reaching users in a timely way, and automatically where that applies. Hashes and signatures are one input to that, and the mechanism needs its own evidence.

Vulnerability intake, disclosure and response

SSDF: RV.1.1 and RV.1.2 (p.16), RV.1.3 (p.17), RV.2.1 (p.17), RV.2.2 (p.18), RV.3.1 to RV.3.4 (p.18).

This is the densest overlap. Intake from users and public sources, investigation records, your disclosure policy, triage decisions, remediation tickets and root-cause work speak to Article 13(7) and 13(8) and to most of Annex I Part II.

Article 13(8) is worth reading closely: it requires vulnerabilities to be handled effectively for the support period, it tells you how to determine that period, it sets a floor of five years unless the product is expected to be in use for less, and it expressly requires coordinated vulnerability disclosure policies of the kind Annex I Part II(5) describes. An RV.1.3 policy is real evidence for that last point.

Where the CRA adds specific requirements:

• Regulatory reporting. RV.1.3 establishes the roles and processes behind a disclosure and remediation policy. The framework does not specify the CRA’s legal recipients or deadlines, which come from Article 14. Your implementation may already name the people who would submit a notification, so check it before treating the capability as missing. The rules themselves:
  • Early warning and notification run from the moment you become aware: without undue delay and in any event within 24 hours for the early warning, and within 72 hours for the notification. The same two stages apply to an actively exploited vulnerability (Article 14(2)(a) and (b)) and to a severe incident having an impact on the security of the product (Article 14(4)(a) and (b)).
  • Final reports have different triggers. For an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c)). For a severe incident, within one month after the incident notification was submitted (Article 14(4)(c)).
  • The notification and the final report are not required where the relevant information has already been provided.
  • Notifications are submitted through the single reporting platform established under Article 16, to the CSIRT designated as coordinator, and are simultaneously accessible to ENISA.
  • After becoming aware of either, you also inform the impacted users, and where appropriate all users, including where necessary the mitigation and corrective measures they can deploy (Article 14(8)).
• Where to report from outside the EU. Article 14(7) decides which Member State’s CSIRT receives your notifications. A manufacturer with no main establishment in the Union follows a fixed order, based on the information available to it: the Member State where the authorized representative acting for the largest number of its products is established; failing that, the importer placing the largest number on the market; then the distributor making the largest number available; then the Member State with the largest number of users. A US manufacturer should work out in advance whether it has a main establishment in the Union and, if not, which Member State this order points to.
• Reporting already applies. Article 14 has applied since 11 September 2026 (Article 71(2)), and Article 69(3) extends it to in-scope products placed on the market before 11 December 2027. It does not wait for the rest of your CRA work.
• Update behavior. Annex I Part I(2)(c) requires that vulnerabilities can be addressed through security updates, including, where applicable, automatic security updates installed within an appropriate timeframe and enabled as a default setting, with a clear and easy-to-use opt-out, notification to users of available updates, and the option to postpone them temporarily. SSDF does not specify these features. An implementation can still hold evidence for them: PO.1.2 documents security requirements and PW.8.2 tests against them, so look for update-behavior requirements and tests in your records before concluding they are absent.
• Update delivery. Annex I Part II(2) asks for new security updates to be provided separately from functionality updates where technically feasible, and Part II(8) requires updates to be disseminated without delay and, subject to the tailor-made business-user qualification, free of charge with advisory messages. Check your release records for both.

Documentation, archives, roles and training

SSDF: PO.3.3 (p.7), PO.4.1 and PO.4.2 (p.8), PS.3.1 (p.10), PO.2.1 and PO.2.2 (p.6).

Tool-generated artifacts, defined check criteria, safeguarded records, archived release files and your role and training records are inputs to the technical documentation required by Article 31 and Annex VII.

Three distinctions that catch people out:

• Development artifacts are inputs to the technical documentation. The file itself has to contain the Annex VII elements, be drawn up before placing on the market and be continuously updated, where appropriate, at least during the support period (Article 31(2)).
• An internal release archive (PS.3.1) is not the same duty as Article 13(9), which requires each security update issued during the support period to remain available to users for at least ten years after it was issued, or the rest of the support period, whichever is longer. Nor is it Article 13(13), which keeps the technical documentation and the EU declaration of conformity at the disposal of market surveillance authorities for at least ten years after placing on the market, or the support period, whichever is longer. Three different clocks.
• SDLC roles (PO.2.1) are organizational evidence. Check whether your existing role assignments cover CRA notification authority, submission and escalation within the Article 14 deadlines.

Assessing what you already have

The following example is hypothetical. It is written to show the questions that decide reuse. It is not a client engagement, an audit result or a claim about what any company’s records contain.

A US vendor sells downloadable business software to EU customers and has run an SSDF 1.1 program for three years. Four artifacts look promising.

An action table is a practical way to hold the output: artifact, CRA provision, reuse decision, missing work, owner. Those columns are an implementation suggestion, and the CRA does not prescribe them. Some CRA documents do have a prescribed structure: the EU declaration of conformity follows the model in Annex V, with a simplified version in Annex VI (Article 28(2)).

CRA work still to verify or complete

The points below are where a CRA assessment has to reach, whatever your SSDF records already contain. For several of them your records may hold real engineering and test evidence; the assessment is what establishes that.

1. Scope and role. Which products, and whether you act as manufacturer (Articles 2 and 3).
2. Classification and conformity route. Default, important class I or II, or critical, and the procedure that follows (Articles 7, 8 and 32, with Annexes III and IV).
3. The product requirements themselves. Every point of Annex I Part I(2), assessed against your risk assessment. The topics below are abbreviated summaries for orientation. The linked text sets out the complete requirements and their qualifications, and the assessment has to work from that text: (a) no known exploitable vulnerabilities when made available; (b) secure by default configuration, and the possibility to reset; (c) vulnerabilities addressable through security updates, including update notification and temporary postponement; (d) protection from unauthorized access; (e) confidentiality of data; (f) integrity of data, commands, programs and configuration; (g) data minimization; (h) availability of essential and basic functions, including resilience against denial-of-service attacks; (i) minimizing negative impact on the availability of services provided by other devices or networks; (j) limited attack surfaces, including external interfaces; (k) exploitation mitigation to reduce the impact of an incident; (l) security-related information from recording and monitoring internal activity, with an opt-out; (m) secure and easy permanent removal of data and settings, and secure transfer where data can be transferred. The SSDF groups above map to some of these. A full product assessment against every point is still needed.
4. Reporting. Articles 14 and 16. Already applicable, and covered in the vulnerability section above, including the separate final-report rules and the Article 14(7) routing for manufacturers outside the EU.
5. Support period and update availability. Article 13(8) and 13(9).
6. Conformity evidence. Technical documentation, the conformity assessment procedure, the EU declaration of conformity and CE marking (Article 13(12) and 13(13), Articles 28, 30, 31 and 32, and Annexes II, V and VII).

A sequence that works

Start now, in parallel with everything else: establish the Article 14 reporting capability. It already applies, so it cannot wait for the steps below. That means named people with authority to submit, registration on the single reporting platform, and your Article 14(7) Member State worked out.

Then:

1. Fix the scope: product, entity, and the versions you will assess.
2. Classify the product and pick the conformity assessment route.
3. Run the Annex I Part I(2) applicability pass, requirement by requirement, against your risk assessment.
4. Inventory your existing SSDF evidence against the groups above, and mark each item reusable, reusable with work, or not applicable.
5. Close the gaps the applicability pass found. Examples to check include update notification and postponement, reset behavior and secure update distribution. Your actual list comes from step 3.
6. Assemble the technical documentation to Annex VII and keep it current.