The EU Cyber Resilience Act formally entered its enforcement window in late 2025, and 2026 is the first full year where vendors selling products with digital elements into the European market are operating under active supervision. The regulation has been on the books for years, but the practical experience of being audited, of having a market surveillance authority knock on the door, and of having to produce evidence under deadline is new for most engineering teams. The first year of enforcement has reshaped how vendors approach the obligations, and several patterns are now visible from the outside.
What did regulators actually audit in the first year?
Market surveillance authorities across member states focused on a small set of foundational obligations during the first enforcement cycle. The most consistent audit ask was for a current Software Bill of Materials and a documented vulnerability handling process. Authorities did not initially attempt to audit the deeper technical controls in Annex I; they audited whether the basic documentation existed, was current, and was reproducible.
The second pattern was incident notification compliance. The CRA requires notifications of actively exploited vulnerabilities and severe incidents within strict timelines, and several authorities issued informational findings against vendors who could not demonstrate a tested notification process. The findings were not always punitive in year one, but they put vendors on a remediation track.
The third pattern, less expected, was provenance and signing. Several audits asked vendors to demonstrate that the binaries shipped to European customers came from the build pipelines described in their conformity documentation. Vendors who relied on word-of-mouth supply chain claims, with no signed attestations, struggled to produce evidence at audit speed.
Where did vendors fail most often?
The most common failure was stale SBOMs. Vendors had SBOM generation in their pipelines, but the SBOMs in their conformity packages had been generated at a release point and never updated against the binaries actually shipping. When auditors compared a downloaded artifact against the declared SBOM, the deltas were often substantial because of patch releases, hotfixes, and silent dependency updates that bypassed the canonical pipeline.
The second common failure was inadequate vulnerability handling documentation. The CRA requires a coordinated vulnerability disclosure policy, a security contact, and a process for handling externally reported issues. Many vendors had a security@ mailbox and nothing else. Auditors asked for the playbook, the SLA tracking, the disclosure history, and the evidence that the program actually ran. Mailboxes without tickets behind them did not satisfy.
A third failure mode was scope confusion. The CRA covers "products with digital elements," and the line between a product, a service, and a component is not always intuitive. Vendors who built embedded systems with bundled software sometimes treated the software as out of scope because they sold the hardware. Auditors disagreed. The pragmatic interpretation that has emerged is to treat any digital element shipped under your brand as in scope unless explicitly carved out.
How did the conformity assessment process actually work?
Most products fell under the self-assessment path, where vendors declare conformity based on internal evidence. Notified body assessment was reserved for important and critical products under the CRA's classification tiers. The self-assessment path is less expensive but transfers all the evidence burden onto the vendor, and the first year of enforcement showed that the evidence bar is meaningful.
A self-declaration of conformity has to be backed by a technical file that includes the product description, the risk assessment, the design and manufacturing controls, the test results, and the SBOM. Auditors spot-check the technical file by asking to see specific items. Vendors who had a templated technical file with citations to actual systems and outputs passed those checks. Vendors who had narrative documents with no traceability did not.
The notified body path, for important and critical products, is more involved and slower. Notified bodies in the first year were learning the regulation alongside the vendors, which made the process iterative and sometimes inconsistent across member states. Several vendors reported substantially different scrutiny levels for the same product evaluated through different bodies, and the European Commission has indicated that harmonization guidance will be published through 2026.
What changed in vendor behavior because of enforcement?
Three changes are visible in the market. First, SBOM hygiene improved sharply for vendors selling into Europe. Generated-at-build SBOMs are becoming standard, with continuous regeneration on every release and storage tied to the artifact identity. Vendors who used to publish a single annual SBOM are now publishing per-release.
Second, vulnerability disclosure programs got more formal. The casual security@ inbox is being replaced by tracked workflows, public policies, and SLA commitments that are written down and enforced internally. CVE issuance practices have also tightened, because the CRA's notification obligations are easier to satisfy when CVE assignment is automated.
Third, build provenance became a procurement requirement, not just a security goal. Customers selling into Europe now ask their upstream vendors for signed attestations because they need to pass through the provenance chain in their own conformity assessments. The downstream pressure has accelerated SLSA adoption far faster than security teams alone were going to drive it.
What enforcement actions have been taken so far?
Public enforcement actions in the first year have been measured. Most regulators issued informational findings, gave remediation deadlines, and reserved penalties for repeat or willful failures. A small number of products have been ordered off the market in specific member states because of unresolved security issues without a credible remediation plan. The pattern signals that regulators are willing to escalate but prefer compliance over punishment in the early phase.
The penalty structure under the CRA includes fines up to fifteen million euros or 2.5 percent of global turnover for the most serious violations, which is large enough to focus attention. The first year did not see any maximum-tier fines, but the existence of the ceiling is shaping how vendors invest in compliance programs. Boards now ask about CRA exposure the way they ask about GDPR exposure.
What changes for year two of enforcement?
Year two is likely to deepen the audit scope. The first year focused on documentation existence; the second year is expected to test documentation quality. Auditors will compare declared SBOMs against actual binaries with stronger tooling, will probe vulnerability handling timelines, and will examine the integration between conformity claims and operational evidence.
Sectoral convergence is also expected. The CRA overlaps with NIS2, the Radio Equipment Directive, the Machinery Regulation, and other sector-specific regulations. The first year saw vendors maintaining parallel compliance programs; the second year will see consolidation, with shared evidence and shared controls reducing the duplicated work.
A subtler change is in customer expectations. European procurement is starting to ask for CRA conformity as a baseline rather than a differentiator, which means vendors who treated the CRA as a project to finish will find that customers now expect continuous evidence, not point-in-time declarations. The compliance program has to be a running process, not a one-time package.
How Safeguard Helps
Safeguard treats CRA conformity as a continuous evidence process rather than a one-time declaration. Lino compliance maps your live software inventory to CRA Annex I controls automatically, generates the technical file content from real pipeline data, and refreshes it on every release so your conformity declarations match the binaries you ship. Continuous SBOM generation through Eagle and the Safeguard ingestion API ensures every artifact has a current, signed SBOM tied to its build provenance, and Griffin reachability analysis surfaces the exploitable subset of vulnerabilities so your handling timelines focus on what actually matters. Coordinated vulnerability disclosure workflows are built in, with SLA tracking, notification automation, and audit trails that satisfy the CRA's incident reporting obligations. When a market surveillance authority asks for evidence, the technical file, the SBOMs, the attestations, and the disclosure history come from one platform with one source of truth.