Cybersecurity Act 2, Cyber Resilience Act and AI Act: why December 2027 is a single deadline

A client wrote to us in August asking whether the Cyber Resilience Act applied to them, given that their product is a cloud management platform rather than a connected device. The answer took a forty minute phone call, because the question itself was the wrong one. That platform embeds a conversational assistant supplied by a third party, it ships under the company's own brand, and it serves a recruitment process. Three separate pieces of legislation touch it, and two of them come due nine days apart.

Between September 11, 2026 and December 2027 the European framework on digital product security and artificial intelligence closes in on itself. Companies that build, integrate or purchase software with AI components face obligations that appear to belong to separate worlds and that in fact share documentation, evidence and accountability. This article sets out what was proposed on January 20, 2026, what becomes applicable now, who genuinely falls within scope, and which decisions are worth taking before signing the next supplier contract. At the end you will find a glossary of every acronym and technical term used, because in this field the barrier to entry is almost always a vocabulary problem.

September 11, December 2, December 11

The first deadline has already arrived. From September 11, 2026 Article 14 of the Cyber Resilience Act becomes applicable, and manufacturers of products with digital elements placed on the European market must report actively exploited vulnerabilities and severe incidents within very tight windows.

The second falls on December 2, 2027, when the AI Act obligations for Annex III high-risk systems apply, following the calendar rewritten by Regulation (EU) 2026/1744, published in the Official Journal on July 24, 2026 and in force from the third day after publication.

The third comes on December 11, 2027, with the full application of the Cyber Resilience Act and of the essential cybersecurity requirements in its Annex I.

Nine days separate the two full deadlines. For a company that develops or integrates software with artificial intelligence components aimed at the European market, this means one preparation window and one budget, even where internal governance currently treats the two subjects as separate tracks with two owners who never speak to each other.

What happened on January 20, 2026

That day the European Commission presented a cybersecurity package made up of two connected legislative proposals. The first replaces the 2019 Cybersecurity Act with a new Cybersecurity Act 2, the second amends the NIS2 Directive in targeted fashion and aligns it with the first.

The reference text for the first proposal is COM(2026) 11, covering the European Union Agency for Cybersecurity, the European cybersecurity certification framework and ICT supply chain security, and repealing Regulation (EU) 2019/881. The second text is COM(2026) 13, a proposed directive on simplification measures and alignment with the Cybersecurity Act.

The Commission describes the main proposal through four building blocks: a horizontal framework for ICT supply chain security that also addresses strategic dependency and foreign interference risks, a simplified and strengthened European certification framework, simplification measures connected to the implementation of NIS2, and a reinforced mandate for the agency.

On the agency's role the proposal goes well beyond fine tuning. ENISA would be empowered to issue early alerts on threats and incidents, to manage EU level threat and incident repositories, to operate a unified incident notification platform, to support organisations in responding to and recovering from ransomware attacks, and to contribute to the development of certification schemes. This is the shift from a coordination body to Europe's operational cybersecurity centre, with everything that implies for expectations around response speed.

The part that changes procurement

The supply chain block deserves attention from anyone who buys technology, not only from those who build it, and this is precisely why the subject belongs inside artificial intelligence governance.

The proposal moves outside cybersecurity as traditionally understood in EU law. It would have significant consequences for eighteen critical sectors and their ICT suppliers, with broad implications for international trade and for relationships with trading partners. This is the first time the Union has used a binding instrument to impose trade restrictions grounded in geopolitical and national security concerns, with effects on the technology supply chains of critical sectors.

The mechanism works as follows. The Commission would be empowered to designate third countries as raising cybersecurity concerns and to classify suppliers controlled by those countries as high-risk. Such a designation would trigger automatic exclusion from EU funding, standardisation and public procurement, and could impose phase-out obligations requiring entities across all critical sectors to remove equipment that was acquired entirely lawfully. The Commission would be able to specify the phase-out periods for each type of component: for mobile networks, by way of example, those periods shall not exceed thirty-six months from publication of the high-risk supplier list, under Article 110(3) of the proposal.

On penalties the proposed structure is tiered, with a ceiling of 1 per cent of total worldwide annual turnover for certain disclosure-related violations, 2 per cent for other instances of non-compliance, and 7 per cent for the most serious infringements.

One clarification is missing from most commentary and is worth holding firmly in board discussions. Cybersecurity Act 2 is a proposal under negotiation, not law in force. The text is moving through the ordinary legislative procedure, with negotiations in Parliament and Council expected throughout 2026, and once adopted it will apply directly in every Member State, while for the supply chain rules it will be the Commission's implementing acts that set sector specific transition periods.

The path has already met resistance. In its Progress Report of May 22, 2026 the Council of the European Union flagged concerns about the proposed framework and asked for greater clarity on the methodology and procedures for identifying high-risk suppliers, as well as on the scope and likely impact of the measures. Anyone planning today should therefore treat this part as a directional signal rather than an imminent obligation, while keeping in mind that purchasing decisions taken over the next eighteen months will produce their effects inside that framework.

The obligation that starts on September 11

Unlike the January package, the Cyber Resilience Act is already law in force. The regulation entered into force on December 10, 2024 and follows a staggered application calendar. A first section has been operational since June 11, 2026, namely Chapter IV with Articles 35 to 51, governing the authorities and bodies responsible for conformity control. The second section arrives now.

The reporting cascade is the part that changes daily work for engineering teams. For an actively exploited vulnerability the manufacturer must send an early warning within twenty-four hours of becoming aware of it, followed by a full notification within seventy-two hours containing the available information on the vulnerability and on corrective measures, and by a final report within fourteen days of a corrective or mitigating measure becoming available. For a severe incident affecting product security the opening sequence is identical, while the final report is due within one month of the seventy-two hour notification.

The channel is single and centralised. Communications pass through the Single Reporting Platform operated by ENISA, with one submission from the manufacturer addressed to the CSIRT designated as coordinator and, save in exceptional circumstances, made simultaneously available to the European agency. In Italy the competent national CSIRT operates within the National Cybersecurity Agency.

The reporting obligation also applies to products made available on the market before December 11, 2027, and this provision widens the scope of a great many product portfolios. The installed base is not excluded, so the notification process must also cover versions the company considered to be in maintenance or even at end of commercial life.

On July 27, 2026 the Commission published implementing guidance annexed to Communication C(2026) 5252, a non-binding document organised in nine sections with practical examples and use cases, clarifying scope of application, treatment of free and open source software, the definition of substantial modification and the reporting obligations. The guidance devotes explicit attention to micro and small enterprises, suggesting simplified self-assessment routes without reducing the substance of the obligations, because anyone selling a connected product on the European market has to comply regardless of company size.

It is worth recalling how broad the objective scope is, because the word product leads people astray. The regulation applies to a very wide range of internet connected devices and software, including routers, modems, smart home products, connected toys, watches and other wearables, operating systems, firewalls, VPNs, browsers and antivirus software. Commercially distributed software falls within scope with no associated hardware at all, and a language model packaged inside a software product placed on the European market falls within scope together with the product containing it.

Who is actually in scope

The first question companies ask is almost always about scope, and the answer depends on how the product reaches the market far more than on how much code was written in-house.

The first profile is the company that places a product on the market under its own brand, which makes it the manufacturer for the purposes of the regulation. It needs a working detection and notification process from September 2026, a software bill of materials, an assessment of the distance from the essential requirements in Annex I and, by December 2027, completed technical documentation and conformity assessment. Accountability does not transfer upstream by contract, however much the contract is the instrument through which necessary information is obtained in time.

The second profile covers companies that integrate third party components. A company embedding a model, a library or an external service inside its own product and placing it on the market takes on manufacturer responsibility for that product. The critical contractual point becomes upstream notification, because if the component supplier discovers an actively exploited vulnerability and informs the customer five days later, the twenty-four hour window burned out long ago. Accelerated notification clauses in software supply contracts therefore move from legal refinement to operational requirement.

The third profile is the company that buys and uses, formally outside manufacturer obligations and substantially exposed on three different fronts. As a deployer under the AI Act, where it uses high-risk systems. As a NIS2 entity, where it operates in a sector within the directive's scope. As a purchaser, in the event that one of its suppliers were designated high-risk under the future Cybersecurity Act 2 framework. This third profile covers the majority of European mid-market companies and is today the one that perceives itself as least involved.

Where artificial intelligence enters

So far the discussion belongs to product security. The next step turns the subject into a matter of artificial intelligence governance, and it runs through a bridging provision that almost nobody is using.

Article 12 of the Cyber Resilience Act provides that, without prejudice to the accuracy and robustness requirements in Article 15 of the AI Act, products with digital elements falling within the scope of the regulation and classified as high-risk AI systems under Article 6 of the AI Act shall be deemed to comply with the cybersecurity requirements of Article 15 of the AI Act where they fulfil the essential requirements set out in Part I of Annex I, where the processes put in place by the manufacturer comply with the essential requirements in Part II of Annex I, and where the achievement of the required level of protection is demonstrated in the declaration of conformity issued under the regulation itself.

The same provision also simplifies matters on the bodies side, because notified bodies competent to control the conformity of high-risk systems under the AI Act are also competent to control the conformity of those same systems with the requirements of Annex I to the Cyber Resilience Act, provided their compliance with the requirements of Article 39 has been assessed within the notification procedure under the AI Act.

A second bridge runs through the certification framework. Article 42 of the AI Act provides that an artificial intelligence system which has obtained a relevant cybersecurity certification under the Cybersecurity Act may be presumed to comply with certain cybersecurity requirements of the AI Act, which opens a route to reusing evidence already produced.

The operational meaning of these two provisions is straightforward and widely underused. Evidence produced for the cyber regime counts as evidence for the artificial intelligence regime, provided the documentation perimeter is designed with that goal from the outset. Building two separate dossiers means paying twice for the same work, obtaining the same result twice, and additionally risking technical statements that diverge between one file and the other, with everything that follows when an auditor arrives.

Article 15 of the AI Act, read in full

The text is technical but worth quoting, because it defines the playing field for anyone building systems intended for high-risk uses.

High-risk systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness and cybersecurity, and perform consistently in those respects throughout their lifecycle. They shall also be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities.

The vulnerabilities contemplated are specific to artificial intelligence, and this is the point at which the subject departs from traditional information security. Technical solutions shall include, where appropriate, measures to prevent, detect, respond to, resolve and control attacks attempting to manipulate the training data set, the pre-trained components used in training, inputs designed to cause the model to make a mistake, alongside confidentiality attacks and model flaws. In technical shorthand this covers data poisoning, model poisoning, adversarial examples and model evasion, and these are categories that traditional corporate security teams almost never own.

For teams working on agent architectures the perimeter widens further. A system that plans, invokes external tools and takes actions brings inside the compliance boundary the authentication between agents, the permissions attached to each tool call, and the logging that allows anyone to reconstruct after the fact what happened and on what basis. In a multi-agent architecture every component performing a high-risk function in the chain is within scope, not only the one producing the final decision.

The AI Act calendar after the Digital Omnibus

The deferral of summer 2026 moved the deadlines without cancelling the obligations, and the distinction is anything but formal.

Regulation (EU) 2026/1744 deferred the application of the high-risk provisions. Standalone systems falling under Annex III must meet the requirements from December 2, 2027, while high-risk systems embedded in products already subject to the Union harmonisation legislation listed in Annex I, Section A, have until August 2, 2028. Everything the deferral does not touch remains fully applicable from August 2, 2026, including the Article 5 prohibitions and the Article 50 transparency obligations.

The deferral should be read for what it is. The dates are fixed and are not conditional on the availability of harmonised standards, because the conditional mechanism initially proposed by the Commission was dropped during negotiations. Anyone who had planned compliance around August 2, 2026 therefore has additional time rather than an open-ended suspension.

There is also a change of counterpart that almost always goes unnoticed and is worth checking inside corporate groups. A deployer belonging to the same undertaking as the provider comes under the exclusive supervision of the AI Office from August 2, 2026. For a group that develops internally and distributes to its own subsidiaries the competent authority changes, and with it the counterparts, the timelines and the form of documentation to be kept ready.

The supply chain as an artificial intelligence risk

In our AI Rating model the risk dimension covers compliance, ethics, bias, security and privacy. The 2026 package introduces a variable we have so far weighted lightly, namely supplier sustainability over time.

Almost no European company trains models, they buy them, and the due diligence questions asked today about a supplier concern accuracy, cost per token, latency and data residency. The questions the proposed framework makes relevant are of a different nature: who controls the supplier at corporate level, from which jurisdiction, with which upstream infrastructure dependencies, and what would happen to the service if that supplier ended up on a high-risk list with a phase-out obligation running to a defined number of months.

For a company that has just built a core process on a third party conversational assistant this becomes a question of operational continuity before it becomes one of formal compliance. The cost of exiting an artificial intelligence dependency grows with adoption time, and it grows faster than procurement plans tend to assume, because prompts, integrations, historical data and working habits accumulate on top of the contract.

Three indicators therefore enter the risk assessment naturally, with no need to change the four dimension structure of the model: demonstrated ability to notify within twenty-four hours, existence and maintenance of a software bill of materials, and mapping of exposure to suppliers that could be designated.

NIS2 and the rest of the picture

The proposed amendment to the NIS2 Directive works on simplification rather than expansion, which makes it less visible than it deserves.

The targeted amendments proposed on January 20, 2026 aim to increase legal clarity, simplifying compliance with EU rules and risk management requirements for companies operating in the Union, with a benefit the Commission estimates across 28,700 companies, including 6,200 micro and small enterprises. The package promises clearer scope boundaries, simplified jurisdictional rules, more effective cross-border supervisory tools and a unified approach to collecting data on ransomware attacks, while encouraging the use of European certification schemes as a fast route to demonstrating compliance.

On timing it is best not to be optimistic. Adoption is expected in late 2026 or, more realistically, in 2027, after which Member States will have twelve months to transpose, and only then will the Commission set out the detailed technical and sector specific requirements.

The subjective scope widens at specific points, because the proposal extends the digital infrastructure sector to include providers of European Digital Identity Wallets and European Business Wallets, alongside operators of submarine data transmission infrastructure. A new intermediate size category also appears, that of small mid-caps, designated as important rather than essential entities and therefore subject to a lighter supervisory and penalty regime.

One element passed almost unnoticed and deserves a permanent place in the multi-year plan of anyone running infrastructure. The new Article 7(2)(k) would require every Member State to adopt, within its national cybersecurity strategy, policies for the transition to post-quantum cryptography, aligned with timelines and requirements already set out in EU legal acts and policy documents. This is the moment quantum risk stops being a conference topic and becomes a budget line.

Impacts, area by area

On product and engineering the software bill of materials stops being good practice and becomes expected documentation. Substantial modifications to a product already on the market reopen conformity assessment, and the July guidance devotes space precisely to defining when a modification should be considered substantial. The release cycle therefore has to be designed around the support window declared to users.

For procurement and legal, existing software contracts need rereading on at least two points: the supplier's obligation to notify within timeframes compatible with twenty-four hours, and the right to obtain the bill of materials for supplied components. Neither is standard in contracts signed before 2025, and realistic renegotiation happens at renewal.

On security and operations you need an identified and genuinely reachable point of contact, a triage procedure that distinguishes an actively exploited vulnerability from a merely known one, and registration on the reporting platform. Twenty-four hours does not allow the process to be built while the incident is unfolding, all the more so if the event lands on a Friday evening or during a company shutdown.

For the board and the risk committee, exposure has to be represented on a single map with a single deadline. Taking two separate roadmaps to the board, one for cyber and one for artificial intelligence, produces two uncoordinated budget decisions on a problem that requires one.

On the financial side, compliance cost should be estimated net of overlaps. The presumptions of conformity in Article 12 of the Cyber Resilience Act and Article 42 of the AI Act represent, in practical terms, a concrete saving, provided documentation is set up once and with both regimes in mind.

The operational sequence

The first move concerns the notification process and its deadline has already passed. It requires a named owner, an internal assessment flow for reports, and access to the European platform. It is the one obligation whose date went by while you were reading.

The second move, to be closed by the end of 2026, is the inventory. It requires two lists that almost no company holds in current form: products with digital elements placed on the market, including those predating full application, and artificial intelligence systems in use or in development, each with supplier, jurisdiction of corporate control and criticality of the process served.

The third move, which fits in the first quarter of 2027, is the joint gap assessment. A single analysis covering the essential requirements of Annex I to the Cyber Resilience Act and the requirements of Chapter III of the AI Act, with explicit mapping of the evidence reusable across both regimes. Two separate exercises cost more and produce documentary contradictions that are hard to explain.

The fourth move occupies 2027 and concerns conformity proper: product classification, choice of the applicable procedure, involvement of a notified body where required, technical documentation and declaration of conformity.

Running alongside all of this is the contractual review, with the right clauses from first signature on new suppliers and progressive renegotiation on existing ones.

Three recurring mistakes

The first is looking only at 2027. The September 2026 deadline does not require product conformity but a working process, and companies that skip it reach 2027 without the organisational precondition everything else rests on.

The second is separating information security from artificial intelligence governance. These are two regulatory directions with an explicit legal bridge, and treating them as independent projects means producing the same evidence twice while giving up the presumptions of conformity the legislator created precisely to avoid that.

The third is delegating to the supplier. Accountability for placing a product on the market under your own brand does not shift upstream by contract, and the contract serves to obtain information in useful time rather than to transfer the obligation.

Glossary of terms used

ACN, National Cybersecurity Agency. The Italian authority competent for cybersecurity. It hosts CSIRT Italia, the recipient of Cyber Resilience Act notifications for Italian entities.

AI Act. Regulation (EU) 2024/1689 on artificial intelligence. It classifies systems by risk level and imposes differentiated obligations on providers and deployers.

AI Office. The European AI Office, a Commission body with supervisory and coordination tasks over the application of the AI Act, particularly for general purpose models.

Annex I to the Cyber Resilience Act. The list of essential cybersecurity requirements, split into Part I on product requirements and Part II on the manufacturer's vulnerability handling processes.

Annex III to the AI Act. The list of use cases that qualify a system as high-risk, including recruitment, worker management, access to essential services, biometrics and education.

Annexes III and IV to the Cyber Resilience Act. Lists of products defined as important and critical, subject to stricter conformity assessment procedures than the ordinary regime.

COM followed by year and number. The identifier of a European Commission document. COM(2026) 11 is the Cybersecurity Act 2 proposal, COM(2026) 13 the proposed NIS2 amendment.

CER. Directive (EU) 2022/2557 on the resilience of critical entities, complementary to NIS2 on the physical security side.

CRA, Cyber Resilience Act. Regulation (EU) 2024/2847 on cybersecurity requirements for products with digital elements.

CSA, Cybersecurity Act. Regulation (EU) 2019/881, establishing the ENISA mandate and the European certification framework. Cybersecurity Act 2 is the proposal intended to replace it.

CSIRT. The national computer security incident response team, designated to receive and handle reports of incidents and vulnerabilities.

Data poisoning. Deliberate manipulation of training data in order to alter a model's behaviour. It is among the vulnerabilities cited in Article 15 of the AI Act.

Declaration of conformity. The document by which a manufacturer attests under its own responsibility that a product meets the applicable requirements. It is where the bridge between the Cyber Resilience Act and the AI Act becomes concrete.

Deployer. In AI Act language, the party using an artificial intelligence system under its own authority in a professional capacity. Distinct from the provider, which develops and places on the market.

Digital Omnibus. The European digital law simplification package. On the artificial intelligence side it produced Regulation (EU) 2026/1744, which amended the AI Act calendar.

DORA. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector.

ECCF. The European Cybersecurity Certification Framework established by the Cybersecurity Act, currently based on voluntary participation.

ENISA. The European Union Agency for Cybersecurity. It operates the single reporting platform and the European vulnerability database.

Implementing act and delegated act. Instruments through which the Commission specifies the technical detail of a regulation after adoption. Many operational aspects of Cybersecurity Act 2 are deferred to these acts.

ISO/IEC 42001. The international standard for artificial intelligence management systems, certifiable by accredited bodies. Useful as a documentation structure, though distinct from statutory obligations.

Manufacturer. The party placing a product on the European market under its own name or brand and assuming commercial responsibility for it. It does not necessarily coincide with whoever wrote the code.

NIS2. Directive (EU) 2022/2555 on the security of network and information systems. It imposes risk management measures and reporting obligations on essential and important entities in designated sectors.

Notified body. A third party authorised by a Member State to carry out conformity assessments. Chapter IV of the Cyber Resilience Act governs their notification and has applied since June 11, 2026.

Ordinary legislative procedure. The process through which the European Parliament and Council jointly adopt an act proposed by the Commission. It includes the informal negotiation phase known as trilogue.

PQC, post-quantum cryptography. Cryptographic algorithms designed to withstand attacks carried out with quantum computers. The proposed NIS2 amendment names them expressly.

Presumption of conformity. The mechanism by which meeting a requirement in one regulatory regime causes the corresponding requirement in another regime to be considered satisfied. It is the core of Article 12 of the Cyber Resilience Act.

Product with digital elements. The Cyber Resilience Act category covering hardware and software with a direct or indirect connection to devices or networks.

SBOM, software bill of materials. A structured list of the software components in a product, including third party and open source dependencies.

Small mid-cap. An intermediate size category between SME and large enterprise, introduced in the proposed NIS2 amendment with a lighter regime.

SRP, Single Reporting Platform. The single platform operated by ENISA to receive the reports required by the Cyber Resilience Act, with automatic forwarding to the CSIRTs concerned.

Actively exploited vulnerability. A security flaw for which there is evidence of ongoing exploitation by a malicious actor. It is the condition that triggers the twenty-four hour alert obligation.

The decision point

The December 2027 convergence makes visible something that has been true for a while. Artificial intelligence governance in a company runs through the technology supply chain at least as much as it runs through models, and an organisation that does not know which systems it uses, who supplies them and from which jurisdiction holds none of the minimum inputs needed to estimate its exposure on either side.

Measurement precedes decision. Before opening a compliance programme it is worth knowing where the organisation actually stands: which systems are in use, which documentation already exists, which evidence is reusable across the two regimes, which suppliers represent a critical dependency and what exiting them would cost.

For a structured assessment of maturity and regulatory exposure write to hello@zerofive.ai or book a conversation at calendly.com/fabiolalli/zerofive.

Sources. European Commission, proposals COM(2026) 11 and COM(2026) 13 of January 20, 2026, and Communication C(2026) 5252 of July 27, 2026. Legislative texts cited: Cyber Resilience Act, Regulation (EU) 2024/2847; AI Act, Regulation (EU) 2024/1689; Digital Omnibus on artificial intelligence, Regulation (EU) 2026/1744 published in the Official Journal on July 24, 2026. Council of the European Union, Progress Report of May 22, 2026. Italian National Cybersecurity Agency, September 2026 communication.