.svg.png)
The European Commission’s June 2026 guidance confirmed the EU Cyber Resilience Act (Regulation (EU) 2024/2847) has moved from policy ambition to operational reality. Vulnerability and incident reporting obligations under Article 14 take effect on September 11, 2026, with the full set of essential requirements, including secure-by-design controls, technical documentation, conformity assessment, and CE marking, applying from December 11, 2027. Any company placing digital products on the EU market must now convert CRA requirements into working product security programs, defensible evidence, and governance that can hold up under regulatory scrutiny.
The urgency is compounded by a more hostile threat environment. ENISA’s 2025 incident analysis points to faster vulnerability exploitation, professionalized cybercrime, automated social engineering, and persistent software supply chain risk. For manufacturers, importers, and distributors, CRA readiness proves that security is engineered in from architecture through post-market monitoring (and not bolted on) before an audit.
Why Readiness Can’t Wait
The compliance timeline rewards early movers and penalizes late ones, meaning companies cannot wait to build readiness. Before the broader 2027 deadline, manufacturers need functioning vulnerability intake, triage, product-impact analysis, and reporting workflows for actively exploited vulnerabilities and severe incidents. Reports must reach ENISA and the relevant national CSIRT through the CRA Single Reporting Platform. An early warning must be received within 24 hours of awareness, and a full notification within 72 hours.
Software supply chain research reinforces the urgency. Reviews of software bill of materials (SBOM) practice consistently find that SBOMs strengthen supply chain assurance only when the underlying tooling produces reliable, decision-ready evidence; not just a compliance artifact filed away after release.
Confirm Which Products Are in Scope
Scoping is the first real technical step. Companies should inventory every product with digital elements sold, imported, or distributed in the EU, identify which entity holds the «manufacturer» role under the CRA for each one, and flag product variants or configurations that could shift classification or obligations.
IoT and connected-product environments deserve particular scrutiny. As reflected in a 2025 survey in Future Internet, heterogeneous devices, distributed networks, pervasive connectivity, and resource-constrained endpoints all complicate scope decisions. In these environments, scoping is an architectural risk exercise, not a spreadsheet inventory task.
Map Obligations to the Product Portfolio
Once scope is set, businesses need a product cyber resilience inventory that translates regulatory language into traceable, product-level evidence: risk classification, vulnerability response ownership, conformity pathway, and the documentation needed to answer customer or regulator questions.
Classification then determines the applicable compliance route (i.e., default, important, or critical category). Each path should tie back to a concrete evidence set proving the relevant requirements were engineered into the product, not asserted after the fact.
Build Security by Design Into Engineering
CRA readiness is ultimately an engineering discipline rather than a compliance checklist. Secure-by-design engineering practices need to be part of standard development workflows and tailored to each product’s use case, environment, and exposure profile, not added late as a pre-release gate. These controls include:
- Threat modeling
- Secure coding standards
- Dependency review
- Application security testing
- Secrets management
- Vulnerability scanning
- Penetration testing
- Release gates
Secure-by-design also means secure defaults: minimized attack surfaces, least-privilege access, strong authentication and authorization, data protection, integrity validation where relevant, and update delivery through protected channels. Connected and embedded products should be tested specifically against misuse scenarios, including compromised credentials, exposed interfaces, supply chain manipulation, insecure configuration, and failed updates.
Design intent isn’t enough on its own. Organizations need to preserve product security evidence (e.g., requirements, design records, test results, code review artifacts, remediation logs, release approvals, and monitoring data) to show that controls were implemented, verified, and maintained over time, not just specified.
Strengthen Vulnerability Management and Reporting
Because reporting obligations start first, vulnerability response deserves priority investment now. That means a coordinated disclosure process with clear incident and vulnerability handling procedures and named owners for each step. Meeting the 24-hour and 72-hour windows requires this to already be running, not designed under deadline pressure.
Automation can help (vulnerability intelligence feeds, CVE monitoring, SBOM matching, VEX status tracking, reachability analysis, and incident escalation should work together), but accuracy matters as much as speed. Research on SBOM-based vulnerability management found that downstream vulnerability scanners produced a 92.0% false-positive rate in a study of 2,414 open-source repositories, largely because alerts included vulnerabilities in unreachable code; function-call analysis reduced those false alarms by 61.9%. In short, tooling that floods triage teams with noise will slow reporting rather than speed it up.
Get Documentation and Evidence in Order
Technical documentation is where CRA readiness becomes demonstrable rather than aspirational. Businesses need a structured evidence file connecting:
- Risk assessments
- Product architecture
- Software and firmware composition
- Secure development controls
- Vulnerability handling records
- Test results
- Conformity rationale
- User security instructions
SBOMs should be treated as living engineering artifacts, not static compliance attachments: machine-readable, version-controlled, regenerated at every release, linked to build pipelines, and mapped to vulnerability intelligence, supplier data, and deployment artifacts. SBOM quality varies significantly depending on the generation tool and method used, so documented quality checks and repeatable generation processes matter. An SBOM that can’t be trusted is worse than no SBOM at all.
Documentation should also cover lifecycle security and support governance. Without assigned ownership, compliance knowledge fragments across teams and becomes unusable exactly when it’s needed most.
Assess Conformity and CE Marking
Conformity assessment is where cybersecurity work connects to market access. Organizations should determine the applicable route for each product based on classification, risk category, and intended use (i.e., default, important, or critical).
The most effective approach translates CRA requirements into testable product controls. For instance, secure update obligations should map directly to update architecture, code signing, rollback controls, integrity checks, and other assurance controls.
CE marking should be treated as the output of an ongoing assurance process rather than a one-time administrative milestone. The supporting evidence file, including risk analysis, test results, conformity rationale, post-market monitoring plans, and more, needs to stay current as products evolve.
Extend Readiness to Suppliers and Partners
CRA obligations don’t stop at the company’s own code. Many digital products depend on a broad connected supply chain or third-party technology ecosystem, so supplier contracts, procurement standards, and open-source governance policies need to clearly assign lifecycle cybersecurity responsibilities.
When a third-party issue affects an EU-market product, supplier requirements should include:
- Machine-readable SBOMs
- Component provenance
- Vulnerability disclosure commitments
- Patch timelines
- Secure development attestations
- Clear notification obligations
VEX records or equivalent exploitability documentation help separate theoretical component exposure from actual product-relevant risk, reducing noise and supporting more defensible reporting decisions.
Build a Phased Roadmap
A phased approach turns CRA complexity into an executable program:
- Near term (before September 2026): Complete scoping, assign accountable owners, establish cross-functional governance, close tooling gaps, and test reporting workflows end to end.
- Mid term: Mature the technical foundation by embedding secure-by-design controls, improving SBOM generation and validation, integrating vulnerability intelligence, updating supplier contracts, and assembling conformity evidence packages.
- After December 2027: Update documentation at every release, refresh threat models when architecture changes, run periodic audits, monitor supplier performance, and maintain continuous post-market vulnerability surveillance.
Turn Compliance Into Competitive Advantage
For companies that act early, CRA compliance can become more than a regulatory obligation. It can strengthen product security, improve software supply chain visibility, accelerate vulnerability response, and build customer confidence in a more closely scrutinized EU market. The organizations best positioned for the CRA will treat readiness as an engineering discipline, not a filing exercise, by building an integrated cyber resilience operating model that makes security assurance continuous, evidence-driven, and defensible.
Building that model takes specialized expertise. At Oxford, we connect businesses with the talent needed to turn a CRA roadmap into a functioning program. Because readiness rarely fits neatly into one role, we can help close gaps across conformity assessment, technical documentation, supplier governance, and post-market monitoring. Our consultants can support targeted projects, embed within existing teams, or help build a permanent security function as requirements mature.
Whether your business needs one expert to close a critical gap or a broader team to stand up an evidence-driven security program, we are ready to help.
Frequently Asked Questions About CRA Readiness
What is the EU Cyber Resilience Act?
The EU Cyber Resilience Act is a cybersecurity regulation for products with digital elements placed on the EU market. It requires companies to build security into products, maintain technical documentation, manage vulnerabilities, and provide evidence that products meet applicable requirements.
When do CRA requirements take effect?
Vulnerability and incident reporting obligations begin on September 11, 2026. The broader requirements, including secure-by-design controls, technical documentation, conformity assessment, and CE marking, apply from December 11, 2027.
Which businesses need to prepare for the CRA?
Any manufacturer, importer, or distributor placing digital products on the EU market should assess whether its products are in scope. This includes connected devices, software-enabled products, embedded systems, and products that rely on third-party or open-source components.
What should businesses do first?
Companies should start by confirming which products are in scope, assigning accountable owners, and testing vulnerability reporting workflows. Early readiness work should also include SBOM quality, supplier governance, and evidence collection.
How can Oxford help with CRA readiness?
Oxford offers three flexible engagement models — staff augmentation, co-managed, and fully managed delivery — so you can choose how much of the program to own, from closing a single gap to running full execution across scoping, conformity assessment, documentation, supplier governance, vulnerability management, and post-market monitoring.
Where Oxford Fits In
CRA readiness rarely fits a single delivery model, so we offer three flexible ways to engage, depending on how much of the program you want to own. Whether you need one specialist to close a single gap or a fully managed team running the program end-to-end, we scale with you as requirements evolve.
Across all three models, we draw on deep bench strength spanning the full range of CRA disciplines:
- Engineering and product security: Product Security, Secure Coding/AppSec, Embedded/Firmware Security, DevSecOps, and Penetration Testing
- Documentation and conformity: CRA Compliance, Technical Documentation, Conformity Assessment, and Regulatory Affairs
- Vulnerability management: Vulnerability Management, Incident Response, and SBOM/Supply Chain Risk
- Governance and leadership: CRA Program Management, GRC, and Third-Party Risk/Vendor Security Auditing
If you’re working out where your CRA program has gaps, we’re here to talk through it.
