EU CRA Readiness

NOA SECURITY 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 pillars that, if built properly, can help an organization to ensure that they have processes, accountabilities, artifacts and documentation to ensure sustainable performance under CRA.

Pillar 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. Aspects to account for are:

Accountable owner. A single named individual holding documented authority to declare a reportable event and to authorize publication of an advisory, with a named deputy and defined out-of-hours coverage.

Intake channels. A published coordinated vulnerability disclosure policy per Annex I Part II(5), a monitored contact address, and a documented acknowledgement target.

Triage and severity assignment. A documented method for assigning severity and for establishing exploitation status, distinct from a CVSS base score taken in isolation.

Reportability determination. An explicit decision step separating an ordinary vulnerability from an actively exploited vulnerability and from a severe incident having an impact on the security of the product. The three are different triggers on different clocks.

Escalation to filing authority. A path from triage to the person able to authorize a regulatory filing inside twenty-four hours, including legal review that does not itself consume the window.

Interface to engineering. A mechanism converting a triaged vulnerability into a scheduled remediation with a tracked due date and an owner, across the system boundary between the security function and engineering.

Advisory production. Approval routing, distribution list, and the relationship to the Annex II information supplied to users.

Load evidence. Volume handled in the trailing twelve months, median time to triage, current backlog, and oldest open item (while not required to meet any compliance requirement this measure aids the organization for resource planning and responsiveness)

Independence from product P&L. Whether the function can compel a release, or compel disclosure, against commercial objection from a product line owner. Stated plainly, the inability for a commercial decision to overrule a release required to resolve the exploited vulnerability.

Pillar 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.

Coordinating CSIRT identified. Main establishment determination within the Union, or where the manufacturer is established outside it, the Article 22 authorized representative and the resulting coordinating CSIRT, named in a controlled document rather than known to one person.

Platform registration and credentials. Registration status with the Single Reporting Platform, named submitters, credential custody, and whether registration has been exercised rather than merely completed.

Fallback filing path. A documented alternative where the platform is unavailable at the moment the obligation bites, including direct CSIRT contact details and a rule requiring the attempt and its timestamp to be retained.

Early warning pack. A pre-drafted twenty-four-hour early warning template populated to the point that only incident-specific fields remain open.

Seventy-two-hour notification. The warning pack template plus the analytical inputs it presumes affected including version enumeration, corrective or mitigating measures available, and exploitation indicators.

Final report clocks. Ability to distinguish the fourteen-day final report following availability of a corrective or mitigating measure for an actively exploited vulnerability from the one-month final report for a severe incident.

Installed base enumeration. Ability to identify all product versions made available on the Union market, including product placed before 11 December 2027, and to map a newly disclosed vulnerability onto affected versions within the twenty-four hour window.

Upstream notification path. Article 13(6) requires the manufacturer that identifies a vulnerability in an integrated component to report it to the person or entity maintaining that component. Ensure that an operative path exists, including for free and open-source components where no supplier relationship does.

User notification. The duty to inform affected users of the incident or vulnerability and, where appropriate, of corrective measures and risk-mitigating action available to them. Develop a notification procedure, distribution mechanism and a working template.

Dress Rehearsal. Simulate an event against a live twenty-four hour clock, with retained artifacts and a recorded lessons register. Demonstrate a simulated event with recorded with designated personnel, evidentiary notes with appropriate timestamps.

Coverage. Out-of-hours, weekend, and public holiday coverage across the manufacturer's actual geography. Ensure that your process can perform the function 24/7/365

Pillar 3 — Secure Development and

Annex I Part I Capability

Note the current condition: the harmonized standards requested under mandate M/606 are still in development, so no presumption of conformity is available. 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.

Requirement traceability.  Determination of whether Annex I Part I requirements are represented as controlled requirements traceable forward to design, verification, and release evidence, or whether conformity is asserted retrospectively over a completed product. It should be the former.

Threat modelling method. A documented method, a defined lifecycle gate at which it is executed, a defined trigger for re-execution on change, and a defined retained output artifact. Methods should be documented; gate evidence in the release checklist; retained output.

Risk assessment process. Article 13(2) requires the risk assessment to be documented, updated as appropriate, and included in the technical documentation. Process existence, currency rule, and retention are assessed. Establish procedure and retain assessments. Each should document specific remediations for Annex 1 Essential Requirements.

Secure default configuration. Process assurance that products are made available with a secure by default configuration and with reset-to-secure-state capability where applicable.

Architecture documentation standard. Whether a defined internal standard governs the depth of architectural description required, calibrated against Annex VII expectations, or whether depth is left to the individual engineer - strive for rationale on depth across the engineering organization.

Attack surface and interface control. Process evidence that external interfaces are enumerated, justified, and minimized at a defined gate rather than as an ad hoc review.

Verification linkage. Whether security requirements carry defined verification methods and whether results are retained per release and bound to the released artifact.

Substantial modification criteria. Documented criteria determining when a change constitutes a substantial modification, with the consequences for re-assessment and for Article 69(2) legacy positioning stated. Harmonized standards could provide guidance here once published.

Conformity argument in the absence of harmonized standards. The declared method by which intent to demonstrate Annex I Part I conformity while no harmonized standard confers a presumption, and whether that question has a named owner. Carefully prepared responses are important here to avoid conflicts of statements of conformity prior to release of the harmonized standards.

Pillar 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 Flow-Down applies here directly.

Component inventory authority. Appointment of a single authoritative source of integrated third-party and free and open-source components per released version, and whether it is generated or maintained by hand.

Due diligence method. A documented method for the Article 13(5) duty, including selection criteria, security posture assessment, and a recorded basis for rejection.

Supplier clause set. The CRA-relevant clauses in the agreements actually in force for principal components, where present is executed in text.

Cascade depth. Obligations reach beyond tier one, and how firmware blobs, silicon vendors, and reference-design inheritance are handled where the supplier declines to accept flow-down.

Free and open-source handling. Where no supplier exists to accept flow-down, examine what compensating process applies: fork policy, in-house maintenance capability, or accepted risk with a named owner.

Custom and semi-custom silicon. Where custom ASIC or FPGA content is present, the topology determination and the resulting position on who is making the component available. Ensure complete topology descriptions with documented author.

Continuous component monitoring. Determine whether component vulnerability monitoring is continuous rather than a release-time scan, and how components lacking CPE or PURL identifiers are covered. Release risks can be alleviated by continuous monitoring.

Remediation rights and practice. Contractual and practical ability to obtain a fix from a component supplier inside the declared support period, and the fallback where the supplier will not act.

Support period. The position where a component's supported life ends before the products declared support period. This is the structural fault line in long-lived OT product and is frequently unowned.

Pillar 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.

Source-to-binary integrity. Whether the released binary can be tied to a controlled source state, and whether that tie is verifiable, Build records with commit identifier.

SBOM generation. Automated generation at build time, declared format, declared depth including whether transitive dependencies are captured, and coverage of firmware, binary blobs, and vendor-supplied images.

SBOM validation. Whether SBOM output is validated against the actual artifact rather than against the declared manifest. A manifest-derived SBOM records intent, not content

SBOM retention and versioning. One retained SBOM per released artifact version, held for the support period plus retention margin, retrievable by version rather than only for the current release.

Signing and key custody. Code and firmware signing, custody of signing material in a hardware security module or secure element, rotation policy, and demonstrated revocation capability. Key custody documentation; revocation procedure.

Pipeline security. Access control over the build and release path, protected branches, and separation between the authority to build and the authority to release.

Tool confidence. Where tools generate, transform, or verify security-relevant artifacts without subsequent independent review, whether any confidence argument exists for those tools. Tool inventory with the review status of each output; any confidence rationale.

Dependency ingestion control. Whether external dependencies enter through a controlled proxy or repository with retained provenance or are pulled directly from public registries at build time. Build logs with resolution sources

Verification evidence retention. Test and analysis evidence retained per release and bound to the artifact hash rather than to a build number

Environment reconstitution. Ability to rebuild a release of vintage in its original toolchain, including compiler version, and to reproduce or explain any divergence from the retained artifact.

Pillar 6 — Documentation Retention and Reconstruction

The 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 and the deliverable reports them separately.

Annex VII completeness map. A controlled map from each Annex VII item to the document that satisfies it and its location, maintained rather than assembled on request.

Retention period and basis. Whether the retention schedule reflects the requirement to keep the technical documentation and the EU declaration of conformity for ten years after the product is placed on the market, or for the support period where that is longer.

Release-historical retrieval. The reconstruction test. Produce the risk assessment, component inventory, verification evidence, and release approval as they stood at that release.

Custody after departure. Whether retrieval dependent on an individual's personal knowledge or local storage, and what happens when that individual is unavailable.

EU declaration of conformity. Existence of a template meeting Annex V, the identified signing authority, and the retention route.

CE marking process. The process by which the marking is affixed and the point in the release flow at which the conformity decision is recorded. This point may be moot if the mark is already present. However, requirements for the mark need to be traceable to the DOC.

Annex II information to users. The information supplied with the product, including the point of contact for vulnerability reporting, the declared support period, and where applicable the means of accessing the software bill of materials.

Market surveillance response. A named owner, a target response time, and a language position for a request from a market surveillance authority, together with the pre-assembled pack that would answer it.

Notified body engagement state. Where Class I without full application of harmonized standards, or Class II, applies: application status, expected queue position, and the state of the documentation pack against the body's stated intake requirements. Need for intake checklist; internal readiness assessment.

Pillar 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.

Classification register. Existence, currency, method, and named owner of the -declared classification of products in the domain against Annex III and Annex IV.

Role determination. Manufacturer, importer, or distributor per product, including the position on rebranded third-party product and on product the client substantially modifies. Integrators who reflash or rebrand a third-party controller acquire manufacturer obligations and frequently have not recognized it.

Authorized representative. For manufacturers established outside the Union, the Article 22 appointment and the mandate content, including whether the mandate covers the tasks the manufacturer expects the representative to perform.

Conformity route per class. The selected assessment route for each classification band present in the domain, and whether the resource and lead time implications have been carried into a plan with dates.

Support period determination. The method by which the support period is determined against the expected use lifetime, the recorded basis for each sample, and the position where the determined period falls at the five-year floor while the product's field life plainly exceeds it

Support period consistency. Whether the declared support period is consistent across the supply contract, the datasheet, the user information supplied under Annex II, and any framework agreement with a major account. Divergence here is a commercial exposure as much as a regulatory one.

Legacy fleet position. A recorded position distinguishing product out of scope for the product requirements under Article 69(2) from product in scope for reporting under Article 69(3), with the resulting obligation set stated for each.

Support period exposure. Where the declared support period is shorter than the contractual commitment to a major account or shorter than the installed base's evident expectation, whether the exposure has been quantified and owned.

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 - CRA Readiness Engagement. Nexus Engineering Partners can help your organization employ and test these pillars so ensure full readiness for CRA compliance.

Our service offers 3 weeks of full-time engagement where we review readiness as stated in the 7 pillars above as well as 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. However, we offer full support free of charge if any changes are needed when these standards become fully published.