What follows is my personal reading of what’s changing in European software over the next 18–24 months, with pointers to the essays I’ve written on each theme. Not legal advice — the perspective of someone who designs software architectures that have to ship and stay alive.
Last revised: 25 August 2026. I update this page when a new deadline drops or I return to a point in an essay.
Thesis in one line
European compliance 2026–2028 cannot be “ticked off” at the end of a project: it must be designed into the architecture on day one, like any other non-functional constraint.
Everything below is the reasoning behind that sentence.
The six regulations, in one breath
- CRA (Cyber Resilience Act) — security obligations for “products with digital elements”: SBOM, vulnerability management, incident reporting, declared support window. Reporting obligations kick in on 11 September 2026: early warning within 24 hours, on an ENISA platform that goes live the very same day, with no test environment, so the dress rehearsal has to happen in-house. And the maturity model ENISA published in July measures the organisation’s maturity: it does not prove a product’s conformity.
- AI Act — staggered obligations for AI systems by risk level: general models, high-risk systems (HR, credit, justice), prohibited systems, GPAI (general purpose AI). The June 2026 Digital Omnibus moved the high-risk obligations to 2 December 2027 (Annex III) and 2 August 2028 (Annex I), with dates now fixed; the rest of the calendar is confirmed.
- PLD (new Product Liability Directive) — extends strict liability to software: the producer is liable for damage from defects regardless of fault.
- NIS2 — cybersecurity for essential and important entities: governance, incident reporting within 24/72h, digital supply chain obligations.
- EAA (European Accessibility Act) — mandatory accessibility for e-commerce, ebooks, online banking, ticketing, telephony and transport services from June 2025.
- DORA (Digital Operational Resilience Act) — operational resilience for the EU financial sector: ICT risk management, resilience testing, oversight of critical third-party providers. In force since January 2025; its reach beyond finance is significant, because it sets de facto standards for operational resilience across the digital supply chain.
Six regulations written in different years by different DGs in different styles. But they converge on a common operational idea: software is no longer “an intellectual work exempt from technical responsibility” — it’s an industrial product with compliance obligations comparable to a fridge.
Italian specificity — ACN. Italy’s National Cybersecurity Agency has published a qualification matrix (QC1–QC4) for cloud services used by public administration that overlaps with NIS2, CRA and GDPR while imposing tighter operational constraints. For anyone selling to Italian public administration it’s a non-optional variable, to be read alongside the EU package — not as an alternative to it.
My essays, grouped by regulation
CRA, architecture, SBOM
AI Act, governance, deployer
Governance and the craft of software in a world of constraints
How I’d use this page
If you’re a CTO or Head of Engineering: my operational suggestion is to treat these deadlines as release engineering — explicit ownership, roadmap milestones, a RACI. Not legal with a code review.
If you’re a product manager: start with the EAA if you have a consumer-facing product, with the CRA if you sell B2B. Those two have the most tangible product implications.
If you’re a European software SME: it’s not catastrophic, but decisions are needed now on three fronts — logging/audit, SBOM, incident procedure. I cover this directly in several of the essays linked above.
If you’re an advisory consultant: the window for readiness assessments is now, not once the first enforcement case hits the news.
Primary sources (required reading)
- Cyber Resilience Act — Regulation (EU) 2024/2847
- AI Act — Regulation (EU) 2024/1689
- Product Liability Directive — Directive (EU) 2024/2853
- NIS2 — Directive (EU) 2022/2555
- European Accessibility Act — Directive (EU) 2019/882
Work with me
My engagement here isn’t to tell you ‘here’s the rule’. It’s to help you translate six European regulations into a set of architectural choices, a roadmap, and internal ownership. Legal counsel remains necessary, but it isn’t the right place to start.
Who it's for
CTOs and Heads of Engineering at EU software vendors and SaaS businesses
Product managers who need to understand what changes in their product before planning the next four quarters
Tech SME founders realising the CRA deadline is too close to keep ignoring
Compliance officers who want requirements translated into a backlog, not a policy PDF
How I work
- Readiness assessment (2–4 weeks)
I take your product, pipeline and supply chain and compare them to the applicable CRA, AI Act, PLD, NIS2, EAA and DORA requirements. Output: a gap map with priorities, estimated effort, and design-in suggestions.
- Compliance roadmap design (3–6 weeks)
From assessment to roadmap. Who does what, with what measurable milestones, synchronised with the EU deadlines. A document a board can approve and a team can execute.
- RFP and vendor second opinion (1–2 weeks)
I read a vendor contract or purchase proposal and tell you whether the chain of responsibility holds up under the new PLD and CRA. Useful before you sign.
Engagement FAQ
- Are you a lawyer?
No. I’m a systems architect who works with legal teams. My output is operational: flow diagrams, RACIs, backlogs. Legal opinion comes from your lawyer.
- Do you work on single regulations (e.g. only the AI Act)?
Yes, but reluctantly. The six regulations interact in subtle ways (e.g. CRA and PLD, or AI Act and NIS2, or NIS2 and DORA). Looking at one in isolation often hides costs that surface on the second.
- How long does a typical engagement last?
Two to six weeks for an assessment or review, two to three months for a full compliance plan.
- Do you do delivery or certification audits?
No to both. Independent advisory works precisely because it has no incentive to sell you delivery work. For certification I point you to accredited bodies.
Email me at [email protected] with a couple of lines of context. I reply within a few business days with a concrete proposal, or a polite no if it's not my scope.
Want to be notified when I update this page?
The EN RSS feed flags every update to main essays. For direct conversation, reach me at [email protected].
Questions & answers
Which European regulations affect software in 2026–2028?
Six: Cyber Resilience Act (CRA), AI Act, Product Liability Directive (PLD), NIS2, European Accessibility Act (EAA), DORA (sectoral, finance). They enter into force at different moments between 2024 and 2028 but their cumulative effect redesigns European software architecture.
Is compliance a legal or an engineering problem?
Both, but the engineering side gets systematically underrated. These regulations are system constraints — feature delivery deadlines (logs, audit, SBOM, accessibility) with a mandatory date. Treating them as red tape to be handled at project end costs 5-10× more than designing them in from the start.
Who is affected by the Cyber Resilience Act?
Any ‘product with digital elements’ sold on the EU market: commercial software, firmware, connected devices, SDKs. Many SaaS products fall under this umbrella. The first wave of obligations (incident reporting) kicks in September 2026, the bulk in December 2027.
My software isn't AI — does the AI Act still apply?
Possibly yes. The AI Act applies to providers of systems that integrate third-party AI (OpenAI, Claude, Gemini APIs) and to ‘deployer’ roles — whoever uses AI to make decisions about people (HR, credit, welfare). Deadlines run from February 2025 through August 2028: after the June 2026 Digital Omnibus, high-risk obligations apply from 2 December 2027 (Annex III) and 2 August 2028 (AI embedded in regulated products); the rest of the calendar is confirmed.
Can I start later, once there are more examples?
No. Design-in compliance requires architectural choices (logging, data retention, SBOM, accessibility) that become very expensive to retrofit. Those who wait ‘to see how others do it’ pay twice.