What the 2026 EU Proposal Actually Says

On 20 January 2026, the European Commission published COM(2026) 13, a proposal to amend the NIS2 Directive alongside a revised Cybersecurity Act (COM(2026) 11). The PQC change is a new point (k) in Article 7(2): Member States must adopt policies, within their national cybersecurity strategies, for the transition to post-quantum cryptography, taking into account the timelines set in applicable EU law and policy.

Two points matter for developers. First, it is still a proposal. It is moving through the ordinary legislative procedure as 2026/0012(COD), and as of early October 2026 neither the European Parliament nor the Council had adopted a position. Second, it addresses Member States, not companies directly. Your existing duty sits in Article 21, which already requires policies and procedures on the use of cryptography and encryption. If the amendment is adopted, Member States would have 12 months to transpose it.

The EU PQC Roadmap: Three Dates to Know

The proposal leans on the Coordinated Implementation Roadmap for the transition to PQC, released in June 2025 by the NIS Cooperation Group in response to Commission Recommendation (EU) 2024/1101. Its milestones:

• 31 December 2026: Member States have implemented the first steps, drawn up initial national roadmaps and started pilots for high- and medium-risk use cases.
• 31 December 2030: high-risk use cases are migrated, and quantum-vulnerable public-key mechanisms are no longer used stand-alone for them.
• 31 December 2035: medium-risk use cases are migrated, and low-risk ones as far as feasible.

The roadmap is a recommendation, not binding law, and the 2026 milestone is addressed to Member States. Even so, the NIS Cooperation Group's April 2026 FAQ says entities in scope of NIS2 should, at a minimum, build a cryptographic inventory and dependency maps, involve their supply chain and run a quantum risk analysis. Expect audit and procurement questions to follow.

A Developer's PQC Checklist for 2026

1. Build a cryptographic inventory. Find every use of RSA, ECDSA, ECDH and Diffie-Hellman across your code, dependencies, certificates, HSMs and firmware, and record it in a standard format such as a CycloneDX CBOM. According to the NIS Cooperation Group, you do not need a finished inventory before you start planning.
2. Prioritise by data lifetime. The roadmap treats data that must stay confidential for 10 years or more, and systems that would take over 8 years to migrate where compromise would have high impact (software-update signing is the example), as high risk.
3. Design for crypto-agility. Put algorithms behind interfaces, avoid hard-coded key sizes and make algorithm choice configurable, so swapping primitives becomes a configuration change rather than a rewrite.
4. Learn the NIST standards. FIPS 203 (ML-KEM) covers key establishment; FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) cover signatures. All three were finalised on 13 August 2024. FN-DSA (FIPS 206) is still a draft, and NIST selected HQC in March 2025 as a backup KEM. ML-KEM-768 and ML-DSA-65 are common starting points for civilian systems.
5. Plan for size and hybrids. Hybrid key exchange, pairing a classical algorithm with ML-KEM, is a widely used bridge. ML-DSA signatures run from roughly 2.4 to 4.6 KB, so test certificate chains, token limits, packet sizes and HSM support early.
6. Question your suppliers. Ask vendors and library maintainers for PQC roadmaps. The Cyber Resilience Act's main obligations apply from 11 December 2027, and the EU roadmap recommends that products with a lifetime beyond 2030 be upgradable to PQC, with post-quantum signatures protecting update mechanisms.
7. Test what you ship. New cryptography brings new bugs: misconfigured hybrids, downgrade paths and side channels. Include PQC changes in your penetration testing and vulnerability assessments, ideally with a CREST-accredited provider.

A practical way to begin: pick one high-value service this quarter, such as your API gateway or code-signing pipeline, map its cryptography and run a pilot with hybrid key exchange in a test environment. A small, well-documented pilot gives you evidence for auditors, realistic performance numbers for architects and a template for every service that follows.

Why This Matters for NIS2 Compliance

NIS2 penalties are substantial: maximum fines of at least €10 million or 2% of worldwide annual turnover for essential entities, and at least €7 million or 1.4% for important entities, whichever is higher. Management bodies can also be held liable for failing to comply. PQC readiness belongs inside your wider NIS2 compliance programme, alongside risk analysis, incident handling and supply chain security, not in a side project. A vendor-neutral cybersecurity consultancy such as VISTA InfoSec can support gap analysis and risk assessment, so developers and compliance teams work from the same plan.

Frequently Asked Questions

Is NIS2 post-quantum cryptography mandatory today?

Not as a standalone obligation on companies. The amendment is only a proposal and targets Member States. However, Article 21 already requires cryptography policies, and Member States are expected to have national PQC roadmaps by the end of 2026.

Which post-quantum algorithms should developers start with?

Start testing ML-KEM for key establishment and ML-DSA for signatures, ideally in a hybrid setup, and keep your code crypto-agile so FN-DSA and HQC can follow once finalised.

Start Now, Not on 31 December

The 31 December 2026 date is a Member State milestone, not a developer deadline, but it is the clearest signal yet that Europe expects organisations to know where their cryptography lives. Start with an inventory, rank your risks and build agility into every release. For an expert second opinion on your cryptographic risk, talk to the VISTA InfoSec team about cybersecurity and compliance support.

References

• EU Coordinated Implementation Roadmap for the Transition to PQC
• Recommendation (EU) 2024/1101
• COM(2026) 13, proposal amending NIS2
• Directive (EU) 2022/2555 (NIS2)
• European Parliament Legislative Observatory, 2026/0012(COD)

What Is EU AI Act Article 50?

Article 50 of Regulation (EU) 2024/1689 sets transparency duties for AI systems that talk to people or create content. It applies whether or not a system is classed as high-risk, so even a simple marketing chatbot is in scope. It contains four core duties, plus a rule on how disclosures must look and when they must appear:

• Article 50(1): providers must design AI systems that interact with people so users are told they are dealing with AI, unless that is obvious from context.

• Article 50(2): providers of systems generating synthetic audio, images, video or text must mark outputs in a machine-readable format so they are detectable as AI-generated or manipulated.

• Article 50(3): deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them.

• Article 50(4): deployers must disclose deepfakes, and AI-generated text published to inform the public on matters of public interest.

• Article 50(5): disclosures must be clear, distinguishable, accessible, and given at the latest at first interaction or exposure.

Was Article 50 Delayed by the Digital Omnibus? Mostly No

This is the question developers keep asking, and the answer matters. The Digital Omnibus on AI, in force since 27 July 2026, postponed high-risk obligations: Annex III systems now follow on 2 December 2027, and AI embedded in regulated products (Annex I) on 2 August 2028. Article 50 was not postponed and has applied since 2 August 2026.

There is one narrow exception. For generative systems already on the EU market before 2 August 2026, the Article 50(2) machine-readable marking duty applies from 2 December 2026. Anything placed on the market from 2 August 2026 must comply from day one. With that date less than two months away, treat the grace period as a countdown, not a reprieve.

Provider or Deployer? Know Your Role

Providers build AI systems or place them on the market; deployers use them under their own authority. Many teams are both. A SaaS company that fine-tunes a model and embeds it in its product is a provider for Articles 50(1) and 50(2), and a deployer for 50(4) when it publishes outputs itself. Map your role per feature, not per company.

The AI Labelling Checklist for Developers

1. Inventory every AI touchpoint. List chatbots, voice agents, image, video, audio and text generators, and any emotion or biometric features. You cannot label what you have not found.

2. Disclose AI interaction by design (50(1)). Show a clear "you are talking to an AI" notice at or before the first message. Skip it only where context makes AI use genuinely obvious, and document why.

3. Apply machine-readable marking (50(2)). Embed watermarks, metadata or equivalent signals into generated audio, image, video and text. Aim for solutions that are effective, interoperable, robust and reliable as far as technically feasible. Assistive editing that does not substantially alter the input is carved out.

4. Make marks detectable. A mark nobody can read is a failed control. Test that your signals survive compression, cropping and format conversion, and that detection works for third parties.

5. Label deepfakes visibly (50(4)). Where your product publishes realistic synthetic media, add a clear visible or audible disclosure. For evidently artistic, creative, satirical or fictional works, disclosure can be lighter so it does not spoil the experience.

6. Flag AI text on public-interest topics. Published AI-generated text that informs the public needs a label, unless a human has reviewed it and a person holds editorial responsibility. Record that review.

7. Notify people exposed to emotion recognition or biometric categorisation (50(3)). Pair the notice with GDPR-compliant processing.

8. Make disclosures timely and accessible (50(5)). Show them at first exposure, in plain language, and in formats everyone can use. Audio-only content needs an audio disclaimer.

9. Log, test and document. Keep evidence of design decisions, marking tests and review workflows. Include your marking and disclosure flows in security testing so they cannot be stripped or spoofed easily.

Your Shortcut: The Code of Practice and Commission Guidelines

Two official resources make life easier. The European Commission published the final Code of Practice on marking and labelling AI-generated content on 10 June 2026. It is voluntary, and the Commission and the AI Board have assessed it as adequate, so signatories can rely on it to demonstrate compliance. On 20 July 2026, the Commission added non-binding guidelines that explain scope, with practical examples for each Article 50 duty. Read both before you finalise your design.

What Happens If You Ignore It?

Breaches of Article 50 can draw administrative fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher; for SMEs and start-ups the lower amount applies. National authorities enforce the rules, and unlabelled synthetic content also puts customer trust at risk in a market that already expects strong data protection.

Turn the Checklist Into Compliance Evidence

A checklist is a start; evidence is what regulators and enterprise buyers ask for. VISTA InfoSec's EU AI Act compliance services can help you scope your obligations and close gaps, and the EU AI Act compliance checklist offers a wider walkthrough. Because AI systems process personal data, align your labelling work with GDPR compliance consulting and the AI and GDPR preparation expert roundup.

Finally, prove your controls hold up. Penetration testing can show whether your marking and disclosure flows can be bypassed, while ISO 27001 consulting gives you a management system to keep them governed. Ready to move? Book a free compliance consultation and turn Article 50 from a risk into a trust signal.

Why CRA incident reporting changes your runbook now

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its main requirements apply from 11 December 2027, but the reporting obligations for manufacturers arrived much earlier: 11 September 2026. That includes products already on the EU market, not just new launches.

Manufacturers of products with digital elements, such as connected devices, software and components, must report two things: actively exploited vulnerabilities and severe incidents that affect the security of their product. Reports go through the ENISA single reporting platform, which routes them to the CSIRT designated as coordinator and to ENISA.

CRA, NIS2, DORA and GDPR deadlines at a glance

The pattern is clear: 24 hours is the new baseline, and DORA is the strictest of all. A fintech that ships its own connected app could face every one of these at once.

What counts as reportable under the CRA?

Two triggers matter. The first is a vulnerability in your product that is being actively exploited, meaning there is reliable evidence that a malicious actor used it without the system owner's permission. The second is a severe incident with an impact on the security of your product. A theoretical flaw found in testing is not reportable on its own; one seen in the wild is.

The CRA reporting clock also starts at awareness, not at confirmation of full root cause. Your team needs authority to file an early warning before the investigation is finished.

6 steps to update your incident response runbook

1. Build one triage decision tree. Ask the same questions once: Is a product vulnerability exploited? Is personal data affected? Is a financial ICT service disrupted? Is an essential or important service impacted? Each "yes" activates a regulation-specific track.

2. Start separate clocks. Log the "awareness" timestamp and run parallel timers for 4 hours (DORA), 24 hours (CRA, NIS2) and 72 hours (CRA, NIS2, GDPR). Document who decides that an incident is "major" or "significant" and how quickly.

3. Assign named roles with deputies. Incident commander, legal and DPO, product security lead and regulatory submitter, each with a backup for weekends and holidays.

4. Pre-write report templates. Keep early-warning, notification and final-report drafts ready for each regime so analysts fill in facts instead of drafting prose under pressure.

5. Prepare platform access. Make sure the right people can use the ENISA single reporting platform and national authority portals before you need them.

6. Test it. Run a tabletop exercise that mixes a CRA vulnerability with a GDPR breach. Measure how long it takes to produce a defensible first report.

Common mistakes to avoid

• Waiting for certainty. Early warnings exist precisely because facts are incomplete.

• Ignoring suppliers. Your open-source components and third-party code can be the source of an exploited vulnerability. Keep an up-to-date software bill of materials (SBOM) and clear vendor notification clauses.

• Inconsistent messaging. Regulators compare notes. Use a single fact sheet as the source for every submission.

• Forgetting users. The CRA expects manufacturers to inform affected users about incidents and the corrective measures available.

Penalties: why this is a board-level issue

The stakes are real. GDPR fines reach up to €20 million or 4% of global annual turnover. NIS2 allows up to €10 million or 2% for essential entities and €7 million or 1.4% for important ones. Breaching CRA essential requirements can cost up to €15 million or 2.5% of worldwide turnover, and failing other CRA obligations, including reporting, up to €10 million or 2%. Supplying incorrect information to authorities carries its own penalty.

Need a runbook that survives a real audit? The specialists at VISTA InfoSec help European organisations map overlapping obligations, from GDPR compliance consulting to NIS2 and DORA readiness, and pressure-test defences with penetration testing and vulnerability assessments. If you build connected products, their cybersecurity compliance services can also help you prepare for CRA conformity.

Frequently asked questions

Does CRA incident reporting replace NIS2 or GDPR reporting?
No. The CRA covers product security, while NIS2 covers entity-level incidents and GDPR covers personal data breaches. One event can trigger all of them, so your incident response plan must run them in parallel.

Is a single EU reporting channel coming?
The European Commission has proposed simplifying incident reporting through a single entry point as part of its digital simplification agenda, but proposals can change. Until a final law applies, keep separate obligations in your runbook and monitor official EU sources.

Final thoughts

CRA incident reporting is not a future problem. It is live, overlaps with NIS2, DORA and GDPR, and rewards organisations that decide fast and document well. Update your triage logic, pre-build your templates and rehearse. Then talk to VISTA InfoSec about turning your runbook into an audit-ready compliance asset.

This article is for general information, not legal advice. Deadlines and national rules can change; confirm current requirements with your legal counsel and official EU and national authority guidance.