CRA readiness is not a checklist — it is an operating model change

Most of the CRA coverage we see in the industry treats the regulation as a compliance exercise: produce the documentation, get the declaration, ship the product. That framing underestimates the regulation — and misreads where parallel US guidance is heading.

CRA, in combination with NIST’s secure-software-development framework and the associated agency guidance, is an operating model change. It moves security from a release-time concern to a lifecycle concern, and it pushes responsibility for security posture further up the supply chain than most wired-edge product teams are structured for today.

This post is a reading of where the regulation actually bites for wired-edge products, and what the foundation is shipping to help members absorb it without doubling their engineering cost.

Where the regulation actually bites

Three places. In order of severity for most member product lines.

Continuous vulnerability handling. CRA obligates manufacturers to handle vulnerabilities across the product’s entire support lifecycle — not just during active development. For wired-edge products with ten- to fifteen-year field lives, that is a structural change. Most product lines were not budgeted, staffed, or architected for a decade of mandatory security updates.

Software bill of materials. Both CRA and NIST guidance require SBOMs that are complete, machine-readable, and kept current. Practically, that means every build produces a signed SBOM, every third-party dependency is tracked, and every field-deployed firmware image can be correlated back to a specific SBOM. Many wired-edge products today produce an SBOM on request; almost none maintain a continuous SBOM pipeline.

Risk assessment and documentation. Products must ship with a documented risk assessment, a threat model, and evidence that security requirements were part of design — not bolted on. For regulators, missing documentation is indistinguishable from missing security. This is a real exposure for product lines whose security work is implicit in tribal knowledge rather than explicit in artefacts.

What craKit is, and what it is for

craKit is the foundation’s practical response. It is not a compliance product. It is a reusable toolkit and knowledge base that shortens the path from “we should be CRA-ready” to “we are, and we can prove it.”

The toolkit is deliberately scoped. It does not replace a lawyer, a certification body, or a security engineer. It does give engineering teams the artefacts they would otherwise rebuild from scratch.

What is in it today

• Threat models for common wired-edge product categories — gateways, CPE, industrial controllers, substation communications, smart-building edge.
• SBOM templates — CycloneDX and SPDX, with CI pipeline snippets for the most common build systems.
• Hardening profiles — opinionated baselines for the most common wired-edge platforms, mapped to both CRA essential requirements and NIST SP 800-218 practices.
• Risk-assessment scaffolding — a documentation skeleton that pre-populates the sections regulators look for, keyed to the product categories above.
• Update-flow reference — a signed, rollback-safe firmware update reference implementation, designed for resource-constrained edge devices.

What is next

• Conformance evidence templates that align with how notified bodies are starting to assess — drafts land this quarter.
• Vulnerability disclosure and handling playbooks, including a reference coordinated-disclosure workflow for multi-vendor dependencies.
• Mixed-media deployment profiles, because a plant with Ethernet, G.hn, MoCA, and PON has an attack surface that is not the union of the four individual profiles.

The common misreading: “we’re a chip vendor, this is not our problem”

We hear a version of this from silicon and PHY vendors fairly regularly. The logic is that CRA applies to the final product, and silicon vendors are upstream.

That is technically correct and practically incomplete. Downstream members who integrate silicon have no way to meet their obligations without cooperation from their silicon vendors — specifically on SBOMs for embedded firmware, on documented security properties of silicon features, and on coordinated vulnerability handling for issues that originate in silicon.

A silicon vendor whose downstream customers cannot meet CRA obligations because of missing upstream artefacts will feel that pressure through the procurement channel, whether or not they are directly regulated. The earlier the foundation can establish shared conventions for upstream artefacts, the less painful this becomes for everyone.

What you can do this quarter

If you ship anything with firmware into the EU market — or you ship into US critical infrastructure — three concrete steps.

1. Run the craKit gap check against one of your product lines. It takes half a day and produces a prioritized list.
2. Adopt a continuous SBOM pipeline. Not an on-request SBOM, not a release-time SBOM. A SBOM that is produced by every build and correlated with every deployed image.
3. Assign a named owner for security lifecycle. One person, named in the org chart, whose remit spans design, shipping, and ten-plus years of field support. If no one has that remit, the regulator will eventually name a defendant instead.

The foundation’s security working group meets biweekly and is open. Bring real problems; we will not waste your time on theatre.

— Security Working Group