Cyber Resilience Act 2026: SBOM, AI and post-quantum

On September 11, 2026 , Article 14 of the Cyber Resilience Act (EU 2024/2847) will come into effect. It mandates the notification of actively exploited vulnerabilities within 24 hours . To meet this deadline, software vendors and industry players must structure a SBOM/VEX inventory and adapt their security to address the risks of AI and post-quantum technologies.

1. CRA Article 14: Deadlines of September 11, 2026

The Cyber Resilience Act (CRA) classifies digital products by level of criticality (default products, Class I, Class II, critical). While the overall requirements (CE marking, technical documentation) will apply from December 11, 2027, the reporting obligation will come into effect on September 11, 2026 (Article 14 of EU Regulation 2024/2847).

Legal calendar for CRA notifications:

• H+24: Transmission of an early warning as soon as the vulnerability is detected.
• H+72: Sending of the detailed incident notification with initial analysis.
• Day 14: Submission of the final report after the correction has been made available.

An often overlooked point: the obligation also applies to products already on the market , not just new ranges. The CRA's "full" obligations (technical documentation, CE marking) will not fully come into effect until December 11, 2027, but the notification process itself allows no grace period.

In practical terms, any company without a PSIRT (Product Security Incident Response Team), a coordinated disclosure channel (CVD), or a notification workflow has a crucial task to undertake immediately: identifying a security contact, establishing a triage procedure, and reviewing contractual clauses with its suppliers to ensure rapid escalation in the event of an incident at a subcontractor. A second, inextricably linked task is updating the software nomenclature . The European Commission published non-binding guidelines at the end of July 2026 to clarify the scope, but the timeline remains unchanged.

2. SBOM, VEX and CBOM: mandatory software traceability

Rapidly reporting an exploited vulnerability requires knowing, within hours, which vulnerable components are present and on which systems they are deployed. Without a reliable inventory, it is impossible to meet the deadlines of Article 14.

The SBOM (Software Bill of Materials) is the exhaustive list of software components of a product, including open source and sub-dependencies. The reference formats expected by the CRA are CycloneDX and SPDX. It answers the question "what's inside?".

The Vulnerability Exploitability Exchange (VEX) addresses a different but equally critical question: "Is this vulnerable component actually exploitable in my product?" A Common Vulnerabilities and Exposures (CVE) published for a library does not necessarily mean that the product containing it is affected. The VEX documents this status (affected, unaffected, being remediated, fixed) and prevents a security team from manually reprocessing thousands of irrelevant alerts.

An up-to-date SBOM and VEX combination allows you to answer the question "Am I affected by this CVE?" in minutes, not days, to document unexploitability for an auditor, and to build the required audit trail. The SBOM is now integrated into the CI/CD pipeline and is automatically generated with each build; the VEX, however, is a long-term record requiring continuous monitoring for each new CVE published in the component catalog.

This is no longer a "for 2027" issue: postponing the SBOM by betting on the December 2027 deadline does not hold up in the face of the notification obligation, which is active from September 2026.

3. Post-quantum cryptography: anticipating a threat HNDL

The post-quantum timeline gives a false sense of security: computers capable of breaking encryption algorithms like RSA or elliptic curves are not yet available. The problem is that the threat is already at work through Harvest Now, Decrypt Later attacks [3]: data encrypted today is being collected by malicious actors, awaiting a quantum computer powerful enough to decrypt it. Any data that must remain confidential beyond the quantum horizon is therefore, even today, at risk.

The NIST (National Institute of Standards and Technology) has finalized an initial set of post-quantum standards, and agencies such as the ANSSI (French National Cybersecurity Agency) recommend a hybrid approach : combining a post-quantum algorithm with a proven classical algorithm within a single certificate. This approach provides a safety net for systems not yet compatible with post-quantum cryptography, while simultaneously offering quantum resistance to those that are.

For embedded systems in particular, an area we know well at Smile, the transition is not trivial: key size and signatures, impact on microcontroller performance, compatibility with existing secure boot chains (U-Boot, OP-TEE). A phased migration, with tools like Yocto to integrate the new primitives into the build chains, avoids last-minute scrambles, especially for long-life products (ten or fifteen years, typical of industrial or defense applications), which risk becoming security obsolete well before the end of their lifecycle.

One preliminary question remains: how do we migrate what hasn't been mapped? This is the role of the CBOM (Cryptography Bill of Materials) , an extension of CycloneDX to cryptographic assets (algorithms, keys, certificates), which allows us to precisely locate where a quantum-vulnerable algorithm is used. The CBOM is a natural prerequisite for clients already engaged in a SBOM/VEX approach.

4. Generative AI: Accelerating vulnerability detection and triage

The last front is the most volatile: generative AI has brought vulnerability discovery into an unprecedented, double-edged phase of acceleration.

On the defense side , the results are spectacular. The Linux kernel has integrated over 400 security patches in a single development cycle, some of which were detected by AI tools—even identifying a vulnerability that had been dormant for nearly nine years in just one hour. Linus Torvalds is now calling it a new standard for the project.

In terms of volume , this same capability poses a problem of scale: reports of AI-related vulnerabilities have increased by 210% in one year, according to HackerOne. AI lowers the level of expertise required to produce an actionable report, but widens the gap between detecting a vulnerability and truly understanding its impact. The result: security teams under pressure, overwhelmed by reports that are sometimes redundant or poorly categorized.

On the attacker's side , the same mechanism operates in reverse: intrusion campaigns have already shown that a relatively unskilled actor, assisted by AI, can compromise hundreds of network devices in numerous countries by automating the exploitation of misconfigurations and weak credentials rather than exploiting entirely new vulnerabilities. AI is industrializing and democratizing the execution of already known attack vectors.

For our clients, the consequence is threefold: the window between discovery and exploitation narrows (yet another argument for an up-to-date SBOM/VEX); AI must be integrated as a triage tool, not just feared as an offensive accelerator; and basic hygiene (configurations, strong authentication, credentials) becomes a priority again, because it is what offensive AI exploits first.

In summary

At Smile, we support our clients in each of these areas – from code auditing and cybersecurity risk analysis to CRA compliance and securing embedded boot chains against quantum risk. If any of these projects align with your 2026 priorities, let's talk.