AI Act, DORA and CRA: What Changed in 2026, What Comes in 2027
Europe’s digital rulebook has changed again in 2026, but the result is not one new compliance date. The AI Act has an enacted amendment and revised high-risk deadlines. The Digital Operational Resilience Act (DORA) is already an operating requirement for the financial sector, with fresh reporting guidance and a continuing supervisory programme. The Cyber Resilience Act has switched on manufacturer reporting more than a year before its main product requirements.
For organisations planning 2027, the immediate task is to separate those developments by legal status, responsible party and trigger. A software supplier, a bank buying that software and a team deploying an AI system can participate in the same service while carrying different obligations. Their evidence can overlap. Their reporting clocks and accountability still need individual owners.
The dates now shaping the work
The Commission’s current AI timetable incorporates the July amendment. Read it alongside the CRA’s staged application and DORA’s existing duties, rather than carrying forward a programme built around the original AI dates.
| Date | What it means |
|---|---|
| 17 January 2025 | DORA became applicable. Financial entities in scope already need operational resilience arrangements. |
| 27 July 2026 | The AI Omnibus entered into force, amending the AI Act and changing parts of its implementation. |
| 2 August 2026 | The AI Act’s transparency rules began applying, subject to the relevant provisions and transitions. |
| 11 September 2026 | CRA Article 14 manufacturer reporting began for actively exploited vulnerabilities and severe product-security incidents. |
| 2 December 2026 | New AI prohibitions apply. Certain providers of synthetic-content systems already marketed before 2 August must meet the Article 50(2) transition deadline. |
| 2 August 2027 | The legacy-model deadline arrives for providers of general-purpose AI (GPAI) models marketed before 2 August 2025 to comply. Member States must also have at least one national AI sandbox operational, which may be established jointly. |
| 2 December 2027 | The postponed Chapter III requirements for Annex III high-risk AI systems apply. |
| 11 December 2027 | The CRA’s main requirements apply. The separate obligations for open-source software stewards also begin. |
| 2 August 2028 | The postponed Chapter III requirements apply to Article 6(1) high-risk AI systems associated with Annex I regulated products. |
These are different milestones. The 2027 AI dates do not suspend duties that already apply, and the CRA’s later product date does not postpone its live reporting requirement.
The AI Act amendment is now law
The AI Omnibus has moved beyond negotiation. Regulation (EU) 2026/1744 was published in the Official Journal on 24 July and entered into force three days later. That distinction matters when organisations assess announcements about simplification: some changes are enacted, while other parts of the broader digital package remain proposals.
The most visible change is the split high-risk timetable. Annex III covers specified uses in areas such as employment, education, essential services and law enforcement. Article 6(1) concerns AI that is a safety component of, or itself constitutes, a regulated product and meets the relevant conformity-assessment condition. An organisation should classify the intended use and its role before choosing a deadline. The presence of AI in a product or a security-sensitive business does not settle that classification by itself.
The later high-risk dates concern Chapter III Sections 1 to 3, with Article 6(5) excepted. They should be tracked against the particular provision, rather than treated as a suspension of every high-risk-related obligation.
There are also transition rules for systems already marketed or put into service. The amended Article 111 ties the general treatment of existing high-risk systems to significant design changes after the relevant Chapter III application date. High-risk systems intended for public authorities have a separate compliance backstop of 2 August 2030. A project needs an evidence trail for the actual system, its market history and subsequent changes, rather than a blanket claim that an existing deployment is exempt.
Transparency still needs attention in 2026
Article 50 has its own duties and exceptions. These include informing people when they interact with certain AI systems, technical marking of synthetic outputs by relevant providers, and disclosure duties for specified uses such as deepfakes. Those are different responsibilities. A deployer should not assume that its supplier’s technical output marking fulfils every disclosure it may owe to people.
The amendment gives providers of synthetic audio, image, video or text systems placed on the market before 2 August 2026 until 2 December 2026 to comply with Article 50(2). This transition should not be presented as a general delay of all transparency obligations. Check the system’s release history, the actor responsible and the particular paragraph that applies.
The new prohibitions on specified non-consensual intimate material and child sexual abuse material also apply from 2 December 2026. The law distinguishes providers’ intended or foreseeably reproducible capabilities and safeguards from a deployer’s prohibited use. Procurement and abuse-response reviews should use the actual amended wording rather than equating every image-generation feature with the same legal classification.
AI literacy was simplified, not removed
The replacement Article 4 still requires providers and deployers to take measures supporting the AI literacy of staff and other people operating systems on their behalf. The measures must reflect their knowledge, experience, training and operating context, including the people affected by the systems. The amendment clarifies that an organisation does not have to guarantee a particular literacy level for every individual.
That leaves a practical management task: identify who approves, operates and supervises each use, and provide support suited to those responsibilities. A generic awareness presentation can be part of that work, but a team handling consequential decisions needs to understand its system’s limits, escalation routes and human oversight arrangements.
A new standard offers a specific route, not a universal certificate
On 19 October, the Commission announced the first harmonised AI Act standard reference in the Official Journal: EN 18286:2026. Its reference is established by Implementing Decision (EU) 2026/2274. It addresses the Article 17 quality management system requirements covered by the standard and gives a presumption of conformity for those requirements.
Its significance is narrower and more useful than a generic claim of being “AI Act certified”. Providers can organise quality management around the AI system lifecycle and integrate that work with an existing management system. They still need to address other applicable requirements, and should distinguish an international management-system certificate from a harmonised standard’s specific legal effect.
DORA has moved into operational feedback
DORA already applies to the financial entities within its scope. The current question is whether governance, ICT risk management, incident reporting, testing and third-party arrangements work in ordinary operations and during disruption. The financial entity remains responsible for its compliance when it uses an ICT supplier.
The ESAs’ first annual incident overview, published on 3 June 2026, provides useful context. It covered 3,383 reported major incidents, around a third with cross-border effects. System failures and external events were the leading drivers; about 10% were related to cybersecurity. This is a major-incident reporting dataset, and its scope matters when interpreting those figures.
Resilience programmes therefore need to connect security monitoring with service dependencies, supplier communication and recovery. A cyber incident response plan alone will not provide every operational fact needed when a shared service fails.
September’s instructions focus on reporting quality
The ESAs issued operational reporting instructions on 16 September. They expressly describe themselves as staff guidance on a best-efforts basis, rather than legal interpretation or an official ESA stance. The binding reporting rules remain in the legislation and technical standards.
The practical points are concrete. Incident identifiers should remain consistent through the reporting lifecycle. Corrections should update the latest report while retaining its other current information. Monetary fields need consistent units and currency, and estimated durations must be distinguishable from actual measurements. These are useful controls for the team producing reports and for the systems supplying its data.
Under Delegated Regulation (EU) 2025/301, the initial notification is due as early as possible, within four hours of major-incident classification and normally no later than 24 hours after awareness. If classification as major occurs later than that 24-hour period, notification is due within four hours of classification. The intermediate report is due within 72 hours of the initial notification, and the final report within a month of the intermediate report or its latest update.
The rules also address delays and weekend or bank-holiday deadlines. The next-working-day flexibility for initial notifications and intermediate reports is unavailable to credit institutions, central counterparties, trading venues and financial entities identified as essential or important under NIS2. Authorities can restrict it for certain other significant or systemic entities after notifying them directly. An operational runbook should record those exact conditions and the competent authority’s arrangements instead of treating either a four-hour or a next-working-day rule as universal.
2027 continues the supervision, rather than starting DORA again
The ESAs’ 2027 priorities, published on 13 October, include continuing oversight of critical ICT third-party providers and assessing technological developments including AI. Critical-provider designation is a specific supervisory status. A supplier does not acquire it merely because a customer regards its service as important.
As BlackTree’s review of DORA as an operating model explains, ownership and evidence need to survive beyond the initial compliance project. Financial entities should keep their registers of ICT contractual arrangements current and follow their competent authority’s submission instructions. A reporting deadline addressed to authorities is not automatically the deadline for every firm to submit its register. For 2027 planning, the useful deliverable is a maintained view of contracts, subcontracting, concentration and service dependencies, with the evidence to support oversight and exit decisions.
AI-related cyber risk is part of the supervisory work
A 31 July ESA statement connects the two regimes. It asks financial entities to consider how more capable AI models can shorten vulnerability discovery and exploitation cycles, while improving defensive capabilities too. Its prevention, detection and risk-management examples sit within the existing framework. The annex expressly creates no additional requirements and is not a comprehensive compliance checklist.
The statement also describes targeted engagement with relevant critical ICT providers and the incorporation of AI-related risks into oversight planning for 2027. Teams should therefore be able to explain their actual exposure, dependency assessments and proportionate response. Buying an AI security tool does not, by itself, supply that explanation or demonstrate resilience.
CRA reporting is already live
The CRA’s manufacturer reporting duties started on 11 September 2026. They concern actively exploited vulnerabilities contained in covered products and severe incidents affecting their security. A vulnerability listing, a proof of concept and reliable evidence of malicious exploitation are different things. Teams need a process to assess the relevant trigger and preserve the awareness timestamp.
For an actively exploited vulnerability, Article 14 requires an early warning without undue delay and within 24 hours of awareness, followed by the vulnerability notification within 72 hours unless that information has already been supplied. The final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe product-security incident, the early and subsequent notification windows are also 24 and 72 hours, but the final report is due within one month after submission of that incident notification. This clock runs from the actual submission, rather than automatically starting at the end of the 72-hour window.
Reports go through ENISA’s Single Reporting Platform to the appropriate coordinating CSIRT and ENISA under the Act’s routing rules. The manufacturer also has duties to inform affected users and provide relevant corrective or risk-reduction information. Reporting is part of handling the event, alongside the technical response and customer communication. BlackTree’s coverage of the September platform launch provides the original implementation context; organisations should use current official instructions for their actual submission.
The CRA’s transition provisions make an important exception for this reporting duty: it reaches covered products placed on the market before 11 December 2027. The general treatment of older products and substantial modifications should not be used to postpone Article 14 reporting.
Restricted onward sharing does not postpone the manufacturer’s report
Another 2026 development concerns how sensitive notifications are shared. Delegated Regulation (EU) 2026/881, adopted in December 2025 and published on 20 April 2026, specifies cybersecurity grounds on which the receiving CSIRT may delay onward dissemination. The conditions address sensitive exploit information and the confidentiality of a recipient CSIRT or the reporting platform.
This is a controlled decision about dissemination after receipt. It does not grant manufacturers a general extension of their Article 14 notification deadlines. Incident procedures need to distinguish the initial reporting duty from subsequent information-handling decisions.
Scope depends on the product and the market role
The Act addresses connected hardware and software products, with sector-specific exclusions. Its remote-processing definition covers software designed and developed by the manufacturer, or under its responsibility, whose absence would prevent the product from performing a function. A cloud element therefore needs to be assessed in its actual product arrangement; describing something as a service is not sufficient analysis.
Manufacturers, importers, distributors and open-source software stewards have different roles. A zero price does not by itself settle the commercial context or responsibilities. The Commission’s open-source explanation distinguishes commercial supply from software its manufacturer does not monetise, and contributors from those responsible for the product. An individual contributor or public repository should not automatically be treated as a commercial product manufacturer. The Commission’s 27 July implementation guidance addresses scope, substantial modification, support periods and reporting, while remaining non-binding.
Open-source software stewards have a separate framework whose obligations begin on 11 December 2027. Their reporting responsibility depends on involvement in product development and, for relevant severe incidents, on the development infrastructure they provide. That date should not be confused with the manufacturer duty already operating this year.
The 2027 work reaches across the product lifecycle
From 11 December 2027, the CRA’s main requirements cover risk assessment, secure product development, vulnerability handling, documentation and conformity assessment. Manufacturers need to understand the components they integrate and maintain a machine-readable software bill of materials covering at least top-level dependencies. That documentation requirement should not be converted into an unsupported claim that every SBOM must be published to everyone.
Support planning is also a product decision. The period must reflect expected use and is normally at least five years; where expected use is shorter, it corresponds to that period. Security updates issued during support must remain available for at least ten years after issue or the remainder of the support period, whichever is longer. Those are related but distinct commitments: availability of an issued update is not the same as an obligation to develop every product indefinitely.
Standards can support conformity assessment, but a development programme is not the same as a published harmonised reference covering a particular requirement. Procurement teams should ask suppliers which evidence applies to the product and release they are buying, which support commitment is offered, and how vulnerabilities and substantial changes will be handled.
One service can create several responsibilities
Consider a bank using an AI system to assess the creditworthiness of natural persons, running it through a contracted ICT service and protecting the environment with a purchased network appliance. The intended AI use needs classification under the AI Act. The bank’s ICT service and supplier arrangements sit within its DORA programme. The appliance manufacturer has to assess its CRA product obligations.
If the appliance contains an actively exploited vulnerability and a disruption affects the bank, the manufacturer’s CRA notification and the bank’s DORA classification and reporting decisions have different triggers. The bank also needs to assess consequences for the AI-supported service and any other applicable duties, including data protection. One party’s completed notification does not establish that every other party’s responsibility has been discharged.
A shared incident record can still make the response much better. Capture affected products and services, versions, supplier contacts, awareness and classification times, recovery state, decisions and supporting evidence. Then retain the separate legal assessment and submission history for each responsible organisation and reporting route.
Keep the proposed reporting reforms separate
The broader Digital Omnibus remains a different file from the enacted AI amendment. On 21 October, the Council agreed its negotiating position on changes involving data protection, privacy and cyber reporting. Its mandate proposes national entry points and an EU information point. Negotiations with Parliament still have to produce an agreed legislative outcome.
Organisations can follow that work when designing adaptable reporting processes. They should continue to use the currently applicable channels, thresholds and deadlines. The Council’s position is not an enacted replacement for DORA reporting or the CRA platform already in operation.
What to finish before the next deadlines
Start with a joined-up inventory whose entries identify the service, product or AI system, its owner, supplier and legal role. Add the evidence for scope and classification, the applicable transition and the exact duty being tracked. That gives procurement, engineering, security, risk and legal teams a common set of facts to work from.
For the remaining 2026 AI milestones, review synthetic-content systems and relevant prohibited-use controls. For DORA, exercise the reporting process with realistic classification, incomplete supplier information and recovery updates. For CRA, ensure product-security teams can identify affected released products, assess exploitation evidence, use the reporting route and communicate mitigations to users.
Use 2027 preparation time for the work that cannot be completed by changing a policy document: lifecycle controls, support commitments, component evidence, quality management, supplier arrangements and tested operational handoffs. Keep the December AI and CRA milestones separate in that plan, alongside the August GPAI and sandbox dates and the later product-related AI timetable.
The useful outcome is a team that knows which obligation it owns, which event starts its clock, what evidence it needs and who can submit an accurate report. That is how the three regimes can share operational discipline while retaining their different purposes.
