CRA Compliance for Engineering Teams: The Complete Guide

The EU Cyber Resilience Act (CRA) introduces mandatory cybersecurity requirements for every product with digital elements sold in the European market. Starting September 11, 2026, manufacturers must report actively exploited vulnerabilities within 24 hours. This guide covers everything engineering teams need to know — deadlines, reporting obligations, product classification, and how to generate the compliance evidence auditors expect.

Key Deadlines

The critical distinction: September 2026 is about reporting — you must have the infrastructure to detect, assess, and notify authorities about vulnerabilities within 24 hours. December 2027 is about design — your products must demonstrably meet secure-by-design requirements from the ground up.

The 3-Step Reporting Timeline

Under the CRA, manufacturers must report any actively exploited vulnerability or severe incident affecting product security to ENISA (the EU Cybersecurity Agency) and their national authority following this strict timeline:

All reports go to ENISA via their Single Reporting Platform (SRP) and to your national authority — the BSI in Germany, NCSC-NL in the Netherlands, CCB in Belgium, or ANSSI in France. The 24-hour window is what keeps engineering leaders awake at night. Manual processes cannot meet it reliably. You need automated detection, pre-mapped product inventories, and evidence pipelines that run before the clock starts ticking.

Product Classification: Which Category Are You?

The CRA classifies products into four tiers based on cybersecurity risk. The classification determines your conformity assessment route — self-assessment vs. mandatory third-party audit.

The Default category is the most significant for engineering teams. Ninety percent of products can self-assess — but that means no third-party auditor walks you through what evidence to produce. You are responsible for demonstrating compliance yourself. That requires tooling that maps your engineering practices directly to CRA requirements and generates evidence automatically.

CRA and NIS2: Where the Requirements Overlap

Engineering teams are dealing with CRA and NIS2 simultaneously. Both regulations originate from the EU's broader cybersecurity strategy, but they target different things:

• CRA targets products — the software and connected devices themselves. It requires secure-by-design development, vulnerability handling, and incident reporting.
• NIS2 targets organisations — the entities operating essential and important services. It requires risk management, incident reporting, and supply chain security.

The overlap is significant: both require incident reporting timelines (CRA: 24h/72h/14d; NIS2: similar structure), both require evidence of security practices, and both create penalties for non-compliance. If you're building software products used by NIS2-regulated entities, you face obligations from both directions. The engineering practice data that satisfies CRA's secure-by-design requirements often maps directly to NIS2's risk management evidence needs.

What “Secure-by-Design” Evidence Actually Looks Like

CRA Article 10 requires that products be “designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity.” For engineering teams, that translates to demonstrable practices across your entire SDLC:

• CI/CD pipeline configuration as evidence of secure development processes. Are builds automated? Are security checks gated? Are deployments traceable?
• Code review standards as evidence of quality assurance. Are pull requests reviewed before merge? Are review requirements enforced, not optional?
• Branch protection policies as evidence of access control. Can anyone push to main? Are force-pushes blocked? Are status checks required?
• Testing coverage as evidence of vulnerability assessment. Do you have automated tests? Are there coverage thresholds? Do tests run on every commit?
• Dependency management as evidence of SBOM compliance. Can you enumerate every third-party component? Are dependencies scanned for known vulnerabilities? Can you produce a Software Bill of Materials on demand?
• Incident response procedures as evidence of vulnerability handling. Do you have runbooks? Are roles assigned? Can you trace from detection to resolution?

This is where most engineering teams get stuck. The data exists — in Git, in CI/CD configs, in project management tools — but it's scattered across platforms and nobody has translated it into the evidence format compliance officers need. The gap isn't capability. It's translation.

Concordance addresses this by scoring 50 engineering protocols across 6 SDLC phases — Requirements, Design, Development, Testing, Release, and Operations — and mapping the results directly to CRA, NIS2, SOC 2, and ISO 27001 requirements from a single scan. The same practice data that tells you whether your code review standards are mature also generates the compliance evidence an auditor needs.

CRA Gap Analysis: Where to Start

If you're an engineering leader preparing for CRA, start with these questions:

1. Product inventory: Do you know which of your products have digital elements and are sold in the EU? Can you classify each one as Default, Important, or Critical?
2. SBOM readiness: Can you produce a Software Bill of Materials for every product? Are dependencies tracked and scanned automatically?
3. Vulnerability detection: Do you have automated vulnerability scanning in your CI/CD pipeline? How quickly can you identify which products are affected by a new CVE?
4. Notification infrastructure: Can you file a report with ENISA within 24 hours? Do you have templates ready? Do you know your national authority contact?
5. Practice documentation: Can you demonstrate that code review, testing, branch protection, and deployment gating are consistently followed — not just enabled?
6. Cross-framework mapping: If you already comply with SOC 2 or ISO 27001, do you know which controls overlap with CRA requirements and which gaps remain?

SBOM Requirements Under the CRA

The CRA requires manufacturers to identify and document the components contained in their products, including third-party and open-source dependencies. While the regulation doesn't prescribe a specific SBOM format, it requires that you can enumerate your software components and demonstrate ongoing vulnerability monitoring.

For engineering teams, this means dependency management must be automated and continuous. Manual spreadsheets won't survive the first audit. You need tooling that scans your dependency trees, generates SBOMs in standard formats (CycloneDX or SPDX), and cross-references components against known vulnerability databases. This is an engineering practice problem, not a compliance paperwork problem — and it starts in your build pipeline.

Does the CRA Apply to Open-Source Software?

This is one of the most frequently asked questions. The short answer: the CRA applies to open-source software only when it is supplied as part of a commercial activity. Purely volunteer-developed open-source projects distributed for free are generally exempt. However, if you integrate open-source components into a commercial product, you as the manufacturer are responsible for the security of those components within your product. The open-source steward concept in the CRA creates certain due diligence obligations for organisations that systematically provide open-source software for commercial use.

Frequently Asked Questions