EU Cyber Resilience Act 2027 Deadlines: A DevSecOps Compliance Checklist

The CRA clock is already ticking, and most teams are reading the wrong date off it.

Everyone has December 11, 2027 circled, the day every product with digital elements needs an SBOM, a vulnerability process, a support period, and a CE mark. But one obligation went live more than a year earlier. Since September 11, 2026, you’ve had just 24 hours to report an actively exploited vulnerability to the authorities, and that duty applies to products you shipped years ago.

The penalties match the ambition. Breaching the essential requirements can cost up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Here’s the good news for engineering teams: almost every CRA obligation maps to something your pipeline can produce automatically. An SBOM on every build. Scan results stored against the release tag. Signed artifacts, a support-end date in your version metadata, a reporting runbook wired into your ticket queue. Do it by hand in a spreadsheet and it won’t survive the CRA’s 10-year documentation window. Generate it on every build and compliance becomes a by-product of shipping.

This checklist works backward from the 2027 deadline. It maps each Annex I requirement to a pipeline stage, an owner, and the evidence an auditor can inspect, then breaks the remaining months into four phases you can tick off, starting with the reporting gap that’s already open.

EU Cyber Resilience Act 2027 Deadlines at a Glance 

The CRA does not switch on all at once. It phases in over three years, and each date triggers a different kind of work for engineering teams. 

Date	What applies	What it means for DevSecOps teams
November 20, 2024	Regulation (EU) 2024/2847 published in the Official Journal	The legal text is final. Start reading Annex I.
December 10, 2024	Entry into force	The 36-month transition clock starts.
June 11, 2026	Chapter IV: notification of conformity assessment bodies	Third-party assessors for important and critical products can be designated.
September 11, 2026	Article 14 reporting obligations (European Commission)	Live now. 24-hour early warnings for exploited vulnerabilities and severe incidents.
Late 2026	Harmonized standards due from CEN, CENELEC, and ETSI	Standards give a “presumption of conformity.” Track them closely.
December 11, 2027	Full application: Annex I requirements, conformity assessment, CE marking	Every in-scope product placed on the EU market must comply.

Two details trip teams up. First, the September 2026 reporting duty covers products already on the market, including ones you shipped years ago. Second, open-source software stewards only pick up their reporting duties on December 11, 2027. 

The practical takeaway is simple. Reporting is 2026 work. Secure development, SBOMs, and conformity evidence are 2027 work, but they take longer to build, so they belong on this quarter’s roadmap too. 

What happens if you miss December 11, 2027? 

Non-compliant products can be pulled from the EU market. Fines are tiered under Article 64: 

Violation	Maximum fine
Breaching Annex I essential requirements or Article 13/14 obligations	€15 million or 2.5% of worldwide annual turnover, whichever is higher
Breaching other CRA obligations	€10 million or 2% of worldwide annual turnover
Supplying incorrect or misleading information to authorities	€5 million or 1% of worldwide annual turnover

Who the CRA Covers (and Who It Skips)

The CRA covers any “product with digital elements” made available on the EU market, whether software or hardware. If your product connects to a device or a network, directly or indirectly, assume it is in scope until proven otherwise. 

That includes desktop and mobile apps, firmware, IoT devices, browsers, password managers, VPN clients, routers, operating systems, and the remote data processing a product needs to work. Your company does not need an EU office. Selling into the EU is enough. 

A few categories sit outside the CRA because other EU rules already cover them: 

• Medical devices and in vitro diagnostics 
• Motor vehicles and aviation products 
• Marine equipment 
• Products built only for national security or defense 
• Free and open-source software that is not monetized as part of a commercial activity 

The three product categories 

Your category decides how you prove conformity. Most products land in the default category and can self-assess. 

Category	Examples	How you prove conformity
Default	Most apps, games, photo editors, smart speakers, generic software libraries sold commercially	Self-assessment (Module A)
Important, Class I	Identity management systems, browsers, password managers, VPNs, network management tools, boot managers, smart home security devices	Self-assessment only if you apply harmonized standards in full; otherwise third-party assessment
Important, Class II	Hypervisors, container runtimes, firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors	Mandatory third-party assessment
Critical	Hardware devices with security boxes, smart meter gateways, smartcards and secure elements	European cybersecurity certification may be required

Example: a SaaS company with a desktop agent 

Pure SaaS is generally regulated under NIS2 rather than the CRA. The picture changes when you ship something the customer installs. 

Take a monitoring vendor that runs a SaaS dashboard and also distributes a Linux agent through a package repository. The agent is a product with digital elements. The backend API the agent depends on to function counts as its remote data processing. Both now fall under the CRA’s secure development, SBOM, and reporting rules. 

The same logic applies to CLI tools, browser extensions, mobile apps, and on-premises editions. Inventory every downloadable artifact you ship before you decide you are out of scope. 

Mapping CRA Requirements to Your DevSecOps Pipeline

Every CRA obligation needs evidence, and your pipeline is the cheapest place to generate it. A market surveillance authority can request your technical documentation at any time, and you must keep it for 10 years or the length of the support period, whichever is longer. Evidence produced automatically on every build survives that window. Evidence assembled by hand in a spreadsheet usually does not. 

The table below links Annex I to the pipeline stage that should own it. Use the last column as your audit artifact list. 

CRA requirement (Annex I)	Pipeline stage	DevSecOps control	Evidence artifact to retain
Cybersecurity risk assessment (Art. 13)	Plan / design	Threat modeling per release or major feature	Threat model file versioned in the repo
No known exploitable vulnerabilities at release	Build / test	SCA, SAST, and container scanning with fail thresholds	Scan reports attached to the release tag
Secure by default configuration	Build / package	IaC and config scanning, hardened base images	Policy-as-code results, image digests
Protection of confidentiality and integrity	Build / release	Artifact signing, provenance attestation	Signatures and SLSA provenance files
Minimize attack surface	Design / build	Dependency pruning, distroless images	Diff of dependency count per release
Identify components via SBOM	Build	SBOM generation on every release build	CycloneDX or SPDX file per version
Address vulnerabilities without delay	Operate	Continuous SBOM rescanning against new CVEs	Ticket history with timestamps
Security updates separate from feature updates	Release	Dedicated patch release branch and channel	Release notes tagged “security”
Coordinated vulnerability disclosure policy	Operate	Published CVD policy and security.txt	Public URL plus intake log
Free security updates through the support period	Release / operate	End-of-support dates tracked per version	Support matrix published to users

Why the support period belongs in your pipeline

 Article 13(8) requires a support period of at least five years, unless the product is expected to be in use for less time. You must state the end date clearly at the point of sale. 

That date is a release attribute, so store it next to your version metadata. When a version passes its end-of-support date, your pipeline should stop building patches for it and your website should say so. Teams that track this in a wiki page tend to discover the gap only when a customer asks. 

The CRA DevSecOps Compliance Checklist, Phase by Phase 

Work backward from December 11, 2027. The checklist below splits the remaining 14 months into four phases, each ending with something you can show an auditor. Tick items off as you go. 

Phase 1: October to December 2026 (inventory and reporting)

 Reporting obligations are already in force, so this phase closes the most urgent gap first. 

☐ List every product, version, and SKU sold or downloadable in the EU, including legacy versions still in use 

☐ Assign each product a CRA category (default, Class I, Class II, critical) and record the reasoning 

☐ Set up access to ENISA’s Single Reporting Platform and confirm which national CSIRT acts as your coordinator 

☐ Name a 24/7 reporting owner and a backup for every product line 

☐ Publish a coordinated vulnerability disclosure policy and a security.txt file 

☐ Write the 24/72/14 reporting runbook (template later in this article) 

☐ Run one tabletop exercise against a real past CVE in your dependency tree 

Phase 2: January to March 2027 (pipeline controls) 

This phase turns Annex I into automated gates. 

☐ Generate an SBOM on every release build in CycloneDX or SPDX format 

☐ Add SCA, SAST, and container scanning with a documented fail threshold 

☐ Sign release artifacts and container images, and store provenance attestations 

☐ Add IaC and configuration scanning so default settings ship hardened 

☐ Store every scan result against the release tag, not in a CI log that expires after 30 days 

Phase 3: April to June 2027 (risk assessment and documentation) 

This phase produces the paperwork the CRA calls technical documentation. 

☐ Complete a cybersecurity risk assessment per product, backed by a threat model 

☐ Define and publish the support period and end-of-support date for each product 

☐ Draft user-facing security information: secure setup, update process, end of support 

☐ Map each Annex I requirement to its evidence artifact (use the table above) 

☐ Check the harmonized standards published by then against your controls 

Phase 4: July to December 2027 (conformity and CE marking) 

This phase is where late teams get stuck, because third-party assessors will have queues. 

☐ Book a notified body early if any product is Class II, critical, or Class I without full standards coverage 

☐ Run the conformity assessment and fix the gaps it finds 

☐ Sign the EU declaration of conformity and affix the CE marking 

☐ Run a dry-run documentation request: can you hand over the full file for one product within 48 hours? 

☐ Freeze the evidence process so every release after December 11, 2027 produces the same artifacts automatically 

Who owns what 

CRA work fails when it belongs to “security” in general. Give each workstream a named owner. 

Workstream	Typical owner	Supporting team
Product inventory and classification	Product management	Legal, security
SBOM and scanning gates	DevSecOps or platform engineering	Development teams
Vulnerability handling and reporting	Product security (PSIRT)	Support, legal
Risk assessment and threat models	Security architecture	Development leads
Technical documentation and CE marking	Compliance	Engineering, QA

SBOM and Vulnerability Handling in Practice

Annex I, Part II requires an SBOM “in a commonly used and machine-readable format covering at least the top-level dependencies of the product.” Top-level is the legal floor. In practice, generate the full transitive tree, because that is where most exploitable vulnerabilities live. Log4Shell reached most affected products as a transitive dependency. 

The SBOM also has to stay useful after release. Vulnerability handling under the CRA runs for the whole support period, so the file you generate today is the file you will rescan against tomorrow’s CVEs. 

Example: SBOM and scan gate in GitLab CI

The job below generates a CycloneDX SBOM with Syft, scans it with Grype, fails on critical findings, and keeps both files for a year. The install scripts fetch the latest release, so pin a specific version in production. Flag syntax changes between releases, so test the job in a lab runner before rolling it out. 

cra_sbom_gate:   stage: test   image: alpine:3.20   script: – apk add –no-cache curl – curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s — -b /usr/local/bin – curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s — -b /usr/local/bin – syft dir:. -o cyclonedx-json=sbom-${CI_COMMIT_TAG}.cdx.json – grype sbom:sbom-${CI_COMMIT_TAG}.cdx.json –fail-on critical -o json > vulns-${CI_COMMIT_TAG}.json   artifacts: paths:   – sbom-*.cdx.json   – vulns-*.json expire_in: 1 year   rules: – if: $CI_COMMIT_TAG

One year of CI artifact retention is far short of the CRA’s 10-year documentation window. Copy both files to long-term storage, such as a versioned object bucket or your artifact registry, keyed by product and version. 

Example: the daily rescan that catches tomorrow’s CVE 

A release-time scan only proves the product was clean on the day it shipped. The CRA expects you to keep watching. 

Schedule a nightly job that pulls every SBOM for every supported version and rescans it against the latest vulnerability data. When a new critical CVE matches, open a ticket automatically with the product, version, component, and timestamp. That timestamp matters. It can become the moment your organization “became aware,” which starts the reporting clock if the vulnerability is actively exploited. 

Tools like DefectDojo or Dependency-Track can deduplicate these findings across versions so one CVE does not open fifty tickets. 

Use VEX to cut the noise

Many CVEs in your SBOM will not be exploitable in your product. A Vulnerability Exploitability eXchange (VEX) statement records that decision in machine-readable form, for example “not affected: vulnerable code not in execute path.” 

VEX gives your triage decisions a paper trail. When an authority asks why a known CVE shipped in a release, you point to the VEX entry and the analysis behind it. 

SBOM practice	Legal minimum	What works in production
Dependency depth	Top-level dependencies	Full transitive tree
Format	Commonly used, machine-readable	CycloneDX or SPDX JSON, never PDF
Frequency	Kept up to date	Every release build, rescanned nightly
Exploitability context	Not required	VEX statements per CVE decision
Storage	Part of technical documentation	Versioned storage for 10+ years

If your team needs hands-on practice with Syft, SBOM scanning, artifact signing, and SLSA builds, the Certified Software Supply Chain Security Expert labs cover those tasks in GitLab. Container-heavy teams can pair this with container security training for image scanning and signing. 

The 24/72/14 Reporting Workflow (Live Since September 2026) 

Article 14 gives manufacturers three reporting deadlines once they become aware of an actively exploited vulnerability or a severe incident. All notifications go through ENISA’s Single Reporting Platform, which reaches the national CSIRT acting as coordinator. 

Stage	Deadline	Exploited vulnerability	Severe incident
Early warning	24 hours after awareness	Product affected, and EU member states where it is available	Whether caused by unlawful or malicious acts, plus member states affected
Notification	72 hours after awareness	General nature of the exploit, corrective or mitigating measures taken, sensitivity of the information	Nature of the incident, initial assessment, corrective measures
Final report	14 days after a corrective measure is available	Description, severity, impact, threat actor info if known, details of the fix	Due within one month of the 72-hour notification

You must also inform affected users, and where appropriate all users, about the vulnerability or incident and the mitigations they can apply. 

Example: what the clock looks like in a real week

Suppose a researcher emails your security inbox at 4:10 p.m. on a Friday with proof that an authentication bypass in your desktop agent is being exploited in the wild. 

1. Friday 4:10 p.m.: awareness. Your PSIRT confirms exploitation evidence, and the clock starts. 
2. Friday 9:00 p.m.: the on-call engineer maps the affected versions using stored SBOMs and the support matrix. 
3. Saturday 2:00 p.m.: early warning submitted to the Single Reporting Platform, inside the 24-hour window. 
4. Monday 2:00 p.m.: full notification submitted, with a temporary mitigation (disable the vulnerable login flow by config flag). 
5. Wednesday: patched version released through the security update channel, and users notified. 
6. Wednesday plus 14 days: final report filed with root cause and the fix. 

Notice that step 2 only took five hours because the SBOMs and version data already existed. A team without them spends the first 24 hours finding out what it shipped. 

Make the runbook executable 

A runbook that lives in a PDF fails at 4:10 p.m. on a Friday. Build it into tooling instead: 

• Route security inbox emails and bug bounty reports into one ticket queue with an “exploited” flag 
• Start a 24-hour timer automatically when the flag is set 
• Pre-fill report fields (product name, versions, EU availability) from your product inventory 
• Page the reporting owner and the backup at the same time 
• Log every decision with a timestamp, since the log itself becomes evidence of good faith 

Teams that already practice incident response through threat modeling tend to adapt fastest, because they already know which components are exposed and how an attacker would reach them. 

7 CRA Mistakes DevSecOps Teams Keep Making 

The biggest risk in CRA programs is running them as a documentation project and bringing engineering in at the end. These are the patterns that most often leave teams exposed close to the deadline. 

1. Assuming the 2027 date is the only date 

Reporting has applied since September 11, 2026, including for products shipped before that date. If you have no reporting owner today, fix that before anything else on this list. 

2. Generating SBOMs once and never rescanning 

An SBOM sitting in a release folder proves nothing about vulnerabilities disclosed next month. The value comes from the nightly rescan across every supported version. 

3. Letting CI logs act as the evidence store 

Most CI platforms expire logs and artifacts in weeks or months. The CRA asks for 10 years. Move evidence to durable, versioned storage on the day it is created. 

4. Ignoring old versions still in the field 

Customers keep running versions you stopped thinking about. If an old version is still within its support period, it needs patches and coverage in your rescans. 

5. Mixing security fixes into feature releases 

Annex I asks for security updates to be available separately from functionality updates where technically feasible. If your only patch path is “upgrade to the next major version,” you need a security release channel. 

6. Self-classifying too optimistically

 A product that manages identities or network traffic is likely Class I or II. Misclassifying it to avoid third-party assessment is a compliance failure waiting to surface during market surveillance. 

7. Leaving it all to one security engineer 

CRA compliance touches product, legal, support, and every development team. A single champion cannot carry it. Spread ownership using the table in the checklist section, and train developers to run the controls themselves. A security champion program helps here by putting one trained person inside each development team. 

Build the Pipeline Skills with the Certified DevSecOps Professional (CDP) 

Most of this checklist comes down to one skill: wiring SCA, SAST, DAST, and security-as-code checks into CI/CD so evidence appears on every build. That is the core of the Certified DevSecOps Professional (CDP) course from Practical DevSecOps (our own training, so weigh it accordingly). You build those gates in browser-based labs, then prove it in a hands-on practical exam. Teams going further into compliance-as-code and vulnerability management can follow the DevSecOps learning path into the Certified DevSecOps Expert course. 

Conclusion: Make CRA Evidence a By-Product of Every Build 

The teams that will pass CRA conformity in 2027 are the ones whose pipelines already produce SBOMs, scan results, signatures, and support dates on every build. Compliance then becomes a by-product of shipping. Anything still done by hand in late 2027 will be done badly, under a notified body’s queue and a hard legal date. 

Start with the reporting gap, because that obligation is live today. Then move through the four phases above, one quarter at a time. If you want a structured place to start, the DevSecOps courses and certifications page lists the hands-on paths, and enterprise training covers whole engineering teams. 

Want to see how the labs work before you commit? Start your 7-day free trial and build your first security gate in a browser-based CI/CD lab today. 

Certified AI Security Professional (CAISP)·7-day free trial

Open a live AI security lab in your browser today

Real targets, real terminals, no local setup.

Start your free trial
No credit card required.

caisp-lab-03

$ ./inject.py –target bot

[*] probing prompt boundary

[+] injection successful

$

Frequently Asked Questions