EU CRA Readiness

NEP SERVICES BRIEF: In this brief we look at key aspects that organizations need to build out to ensure that they are fully ready to conform to CRA (Cybersecurity Resiliency Act) a sustainable way.

CRA compliance is looming for vendors and operators alike from now for reporting and in 15 months for product compliance. The ramification for non-compliant products is that they will lose their CE mark if they had it before. More importantly, substantial monetary penalties are possible as well as potential regulatory and legal exposure not previously needed to mitigate against.

What follows are seven domains that, if built properly, can help an organization to ensure that they have processes, accountabilities, artifacts and documentation to ensure sustainable performance under CRA.

Domain 1 — PSIRT Structure, Process, and Accountability

Annex I Part II presupposes a standing function with authority. This aspect is focused on processing of vulnerabilities that have been reported from the field. Here we look at PSIRT structure, accountability, intake channels, triage processing and traceability, reporting determinations, escalation to filing authorities, engineering engagement interface, approval routing, load evidence and P&L independence.

Domain 2 — Article 14 Operational Readiness

Article 14 applies from 11 September 2026. Under Article 69(3) it reaches the entire installed base placed on the market before 11 December 2027, whether or not those products are ever modified — so this is a current-portfolio obligation and not a new-product one. At the time of writing the ENISA Single Reporting Platform is scheduled to be operational on the obligation date itself, with functional and security testing in progress; the client's readiness cannot be contingent on the tool appearing. In this domain we examine CSIRT authorized representative readiness, platform registration/credentials, fallback filing path, early warning packet composition, 72-hour notification readiness, final reporting clocks, installed base enumerations, upstream notification paths, user notification paths, incident response rehearsal, off hours coverage.

Domain 3 — Secure Development and

Annex I Part I Capability

Currently with no presumption of conformity or harmonized standards to point to every Annex I Part I claim must currently be argued from first principles in the technical documentation. That said, enough is known so that we feel that little if any of this guidance would need modifying once harmonized standards are published. Here we look at requirements traceability, threat modeling methods, risk assessment process, secure default configurations, architecture documentation standards, attack surface and interface control, verification linkage, substantial modification criteria, Conformity argument (in the absence of harmonized standards

Domain 4 — Component Provenance, Due Diligence, and Flow-Down

Article 13(5) imposes a due diligence duty when integrating components sourced from third parties, including free and open-source software, and requires that such components not compromise the security of the product. This is a process obligation, not solely a contractual one, and the companion analysis in The CRA Flow-Down article applies here directly.

In this domain we examine component inventory authorization, due diligence methods, supplier conformity and contract clauses. cascade (nesting) depth, free and open-source handling, custom and semi-custom silicon, continuous component monitoring methods, remediation rights and practices, support period.

Domain 5 — DevSecOps Infrastructure, Tooling, and Provenance

This domain should be assessed for its ability to produce evidence as a by-product of building software, rather than as a separate documentation exercise performed afterwards. Here we look at source to binary integrity, SBOM generation, SBOM validation, SBOM retention and versioning, signing and key generation/custody, pipeline security, tool confidence, dependency ingestion control, verification evidence retention, environment reconstitution,

Domain 6 — Documentation Retention and Reconstruction

This domain splits by conformity route. Where a conformity assessment body (notified body) sits in the path — Annex III Class I where harmonized standards are not applied in full, and Class II — there is a genuine audit to be ready for. Where the product is self-assessed under internal control, there is no audit; there is market surveillance, which is post hoc, adversarial, and triggered by an incident or a complaint. Both are documentation tests. The audiences and the timescales differ. Here we look at Annex VII completeness, retention period and basis. release-historical retrieval, custody after resource departure, EU declaration of conformity, CE marking process, Annex II information to users, market surveillance response, notified body engagement process and states.

Domain 7 — Conformity Route and Support Period

Executed first in sequence despite its position here, assess whether a defensible method produced them, whether they are current, and whether they have an owner. Here we assess classification register, role determinations, authorized representation in the EU (if applicable), conformity routing per class, support period determination consistency, legacy fleet positioning, support period exposure.

Most products fall into categories which self-attestation can be used for compliance without the need for notified body engagement. Nexus Engineering Partners offers bespoke service to ensure your organization is ready for CRA compliance and defense - NOA CRA Readiness. Nexus Engineering Partners can help your organization employ and test these domains to ensure full readiness for CRA compliance.

Our service offers full-time engagement where we review readiness as stated in the 7 domains above as well as help to fill gaps where necessary so that your organization is ready. It should be noted that fully formed harmonized standards are yet to be published at this writing. That said, we expect that there will be little changes needed by thoroughly examining the above listed domains to be examined. However, we offer full gap assurance free of charge for any changes are needed post release of the harmonized standards.