Regulatory Mapping: CRA, NIS2, and SSDF to Pipeline Controls¶
Disclaimer: This page is an engineering aid, not legal advice. It summarizes publicly available regulatory text at a high level and maps it to pipeline practices. Scope, applicability, and obligations depend on your product, role (manufacturer, importer, entity type), and national transposition. Confirm interpretations with legal counsel and the official texts linked at the bottom. Dates were checked in October 2026 and may change.
Frameworks and Standards lists the regulations that drive DevSecOps adoption. This page goes one step further: for each obligation, which pipeline or process control supports it and which evidence the pipeline can produce. The goal is a single set of controls that satisfies several regimes, rather than parallel compliance artifacts.
Key dates¶
| Regime | Milestone | Date |
|---|---|---|
| EU Cyber Resilience Act (Regulation (EU) 2024/2847) | Entered into force | 10 December 2024 |
| Reporting obligations (Article 14) apply | 11 September 2026 | |
| Main obligations (Article 13, Annex I, conformity assessment) apply | 11 December 2027 | |
| NIS2 (Directive (EU) 2022/2555) | Applies through national transposition laws, which vary by Member State | Check your jurisdiction |
| DORA (Regulation (EU) 2022/2554) | Applies to EU financial entities | 17 January 2025 |
| EU AI Act (Regulation (EU) 2024/1689) | High-risk obligations were postponed by the Digital Omnibus: stand-alone systems to 2 December 2027, AI embedded in regulated products to 2 August 2028 | Verify against the Official Journal; this was reported by secondary sources |
| NIST SSDF (SP 800-218) | v1.1 is final (February 2022); Rev. 1 (SSDF 1.2) was published as an initial public draft on 17 December 2025, with comments closed on 30 January 2026 | No final version confirmed at time of writing |
EU Cyber Resilience Act (CRA)¶
Applies to manufacturers of products with digital elements placed on the EU market. Classes of products and conformity-assessment routes differ; the pipeline controls below are common to all.
| Obligation (CRA reference) | Pipeline or process control | Related SSDF 1.1 practices | Evidence |
|---|---|---|---|
| Report actively exploited vulnerabilities (Article 14(1) and (2)): early warning within 24 hours, vulnerability notification within 72 hours, final report no later than 14 days after a corrective or mitigating measure is available | Incident response runbook with a CRA reporting step; asset-to-product mapping so you know which products are affected; a named owner who decides that a vulnerability is actively exploited. See Vulnerability Management | None (SSDF has no reporting to authorities) | Timed drill records, report timestamps |
| Report severe incidents (Article 14(3) and (4)): early warning within 24 hours, incident notification within 72 hours, final report within one month after the incident notification | Same runbook, with a separate trigger for incidents that affect the security of the product | None | Timed drill records, report timestamps |
| No known exploitable vulnerabilities and secure-by-default configuration (Annex I, Part I, points (2)(a) and (2)(b)) | SAST, SCA, DAST, security gates before release; hardened default configuration | PW.4.4, PW.7, PW.8, PW.9, RV.1, RV.2 | Scan reports per release, gate decisions, documented exceptions, default configuration baseline |
| Exploitation mitigation and limited attack surface (Annex I, Part I, points (2)(j) and (2)(k)) | Compiler and build hardening flags; removal of unused interfaces and services | PW.1, PW.2, PW.6 | Build configuration, design review records |
| Identify and document components, including an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies (Annex I, Part II, point (1)) | Generate an SBOM for every release build. See SBOM | PS.3.2 | SBOM stored with the release artifact |
| Due diligence when integrating third-party components, including free and open-source software (Article 13(5)) | Dependency intake review; SCA policy; component health checks | PO.1.3, PW.4.4 | Intake decisions, SCA policy, component review records |
| Address and remediate vulnerabilities without delay, provide security updates, separately from functionality updates where technically feasible (Annex I, Part II, point (2)) | Vulnerability triage SLAs; VEX statements to record exploitability decisions; patch release process | RV.2, RV.3 | Ticket history, SLA metrics, VEX documents, release notes |
| Effective and regular security tests and reviews (Annex I, Part II, point (3)) | Recurring tests in CI; periodic manual review | PW.7, PW.8, RV.1 | Test history, review records |
| Coordinated vulnerability disclosure policy and a contact address for reports (Annex I, Part II, points (5) and (6)) | Published disclosure policy and intake channel. See VDP and Bug Bounty | RV.1.1, RV.1.3 | Policy URL, security.txt, intake records |
| Public advisories for fixed vulnerabilities, secure update distribution and free security updates with advisory messages (Annex I, Part II, points (4), (7) and (8)) | Signed releases; advisory publication step in the release pipeline | PS.2, RV.2 (the SSDF 1.2 draft adds PS.4, robust and reliable updates) | Signatures, advisories, release notes |
| Cybersecurity risk assessment, taken into account across planning, design, development, production, delivery and maintenance (Article 13(2) to (4)) | Threat modeling at design; living design records. See Threat Modeling | PO.1, PW.1 | Versioned threat models and design records |
| Technical documentation kept up to date (Article 31 and Annex VII) | Documentation generated or versioned with each release | PS.3 | Release-linked documentation |
Notes: Article 14 reports go through ENISA's Single Reporting Platform, launched on 11 September 2026, to the CSIRT designated as coordinator of the Member State of main establishment, with ENISA receiving them at the same time. The SSDF column is an engineering aid: no authority has published an official CRA to SSDF mapping, and SSDF 1.1 predates the CRA.
NIS2 (Directive (EU) 2022/2555)¶
Applies to in-scope essential and important entities, not to products as such. Article 21(2) lists minimum risk-management measures. These points are most relevant to a pipeline:
| Article reference | Pipeline or process control | Evidence |
|---|---|---|
| 21(2)(d) supply chain security, including relationships with direct suppliers and service providers; 21(3) asks entities to consider each direct supplier's vulnerabilities and secure development procedures | Dependency and vendor intake review, SBOM requests from suppliers, artifact signing and provenance. See Artifact Signing and Provenance | Supplier assessments, SBOMs received, signature verification logs |
| 21(2)(e) security in acquisition, development and maintenance, including vulnerability handling and disclosure | Secure SDLC controls (SAST, SCA, gates), vulnerability management, disclosure policy | Same as CRA rows above |
| 21(2)(f) policies to assess effectiveness of risk-management measures | Metrics, internal audits, security benchmarking | Dashboards, audit reports |
| 23(4) significant incident reporting (early warning within 24 hours, incident notification within 72 hours, intermediate report on request, final report no later than one month after the incident notification) | Incident response plan with regulator notification step | Runbook, timed drills |
Implementing Regulation (EU) 2024/2690 adds technical detail for digital infrastructure and digital providers only, such as DNS, cloud, data centre and managed (security) service providers. Its Annex section 6 covers secure development (6.2), security testing (6.5), patch management (6.6) and vulnerability handling and disclosure (6.10). National transposition status varies, so confirm which law applies to you.
CRA Recitals 24 and 125 state that the CRA facilitates the NIS2 supply chain obligations. No provision makes a CRA report count as a NIS2 report, or the other way round, so a manufacturer that is also a NIS2 entity runs both duties, with different triggers and recipients.
NIST SSDF (SP 800-218)¶
SSDF is a baseline of outcomes and is the most direct mapping target for pipeline controls. Practice IDs below follow SSDF 1.1. The 1.2 initial public draft adds two practices, PO.6 (continuous process improvement plan) and PS.4 (robust and reliable software updates), and renumbers none, so re-check when it is finalized.
| SSDF group | Practices (v1.1) | Pipeline or process control | Evidence |
|---|---|---|---|
| PO (Prepare the Organization) | PO.1 to PO.5 | Roles, training, secure toolchain, security gates defined as policy | Policy documents, training records, gate configuration |
| PS (Protect the Software) | PS.1 to PS.3 (PS.3.2 is SBOM and provenance) | Repository hardening, protected branches, signed artifacts, provenance, SBOM | Branch rules export, signatures, attestations, SBOMs |
| PW (Produce Well-Secured Software) | PW.1, PW.2, PW.4 to PW.9 (PW.3 was retired; its tasks moved to PO.1.3 and PW.4.4) | Threat modeling, code review, SAST, SCA, DAST, secrets scanning, secure defaults | Scan results, review records, test reports |
| RV (Respond to Vulnerabilities) | RV.1 to RV.3 (RV.1.3 is the disclosure policy) | Vulnerability intake, triage, remediation SLAs, root-cause analysis, disclosure program | Tickets, SLA reports, advisories |
Brief pointers: DORA and EU AI Act¶
- DORA (financial entities): ICT risk management, incident reporting, resilience testing, and ICT third-party risk. Pipeline-relevant overlap is SBOM and supplier evidence, vulnerability management, and testing records.
- EU AI Act: obligations for high-risk AI systems include risk management, documentation, and logging. Where your pipeline builds or deploys models, keep model and dataset provenance next to software provenance. See the AI/ML items in Frameworks and Standards.
Collecting evidence from the pipeline¶
- Produce evidence automatically at each build: SBOM, scan reports, gate results, provenance attestation, and signature, stored together and immutable.
- Keep VEX alongside SBOM so you can show why a listed vulnerability is not exploitable in your product.
- Retain by release, not by tool run, so an auditor or market surveillance authority can retrieve the evidence for any shipped version for the required period (confirm retention requirements with counsel; the CRA ties documentation to the support period).
- Index evidence by control, not by regulation, then map controls to regimes in a table like the ones above. See Compliance Auditing for continuous compliance and audit-trail practices.
Common pitfalls¶
- Treating the CRA as a September 2026 problem only: reporting applies now, but Annex I requirements (SBOM, disclosure policy, update process) need to be built before December 2027.
- Assuming NIS2 or CRA applies uniformly. Check role, product class, and national law.
- Generating an SBOM once and never updating it, or having no VEX process, which leaves every CVE in a component looking exploitable.
- No owner for the 24-hour reporting clock. Define who decides that a vulnerability is actively exploited.
- Treating a tabletop exercise as proof of the 24-hour clock. Keep timed records of drills, from first awareness to submitted early warning.
- Mapping to SSDF 1.1 identifiers without a plan for the 1.2 changes.
Maturity progression¶
| Level | Characteristics |
|---|---|
| Basic | Manual mapping spreadsheet; SBOMs produced ad hoc; disclosure contact exists |
| Intermediate | SBOM and scan evidence stored per release; triage SLAs; tested reporting runbook |
| Advanced | Evidence generated and signed by the pipeline; VEX published; controls mapped once and reused across regimes; continuous audit-ready reporting |
Further reading¶
- Cyber Resilience Act (European Commission)
- Regulation (EU) 2024/2847 (EUR-Lex)
- NIS2 Directive (EUR-Lex)
- NIST SSDF project
- NIST SP 800-218 Rev. 1 initial public draft
- Implementing Regulation (EU) 2024/2690 (EUR-Lex)
- ENISA/JRC Cyber Resilience Act Requirements Standards Mapping
- DORA (EUR-Lex)
- EU AI Act (EUR-Lex)