Software engineers and product developers across Europe are facing an unprecedented compliance crisis.
The European Union has introduced five major cybersecurity laws in just five years. Individually, each is straightforward. Together, they've created an unexpected problem: a single system can now fall under multiple regulations simultaneously, with overlapping requirements that multiply costs and effort.
A recent research paper by Daniele Canavese, Afonso Ferreira, Liina Kamm, and Adrian Quesada Rodriguez unpacks this challenge and charts a clear path forward. Their analysis reveals that the problem isn't just complexity. It's that organisations are still treating compliance as an afterthought, a checklist to complete before launch. They propose compliance-by-design as a solution: building regulatory requirements into software development from the very beginning.
Here are the key takeaways from their paper.
A regulatory landscape taking shape
Over the past five years, the EU has been busy constructing what amounts to a new digital rulebook.
It started in 2019 with the Cybersecurity Act (CSA) which established EU-wide cybersecurity certification schemes and empowered the European Union Agency for Cybersecurity (ENISA) to develop common security standards. This created the foundation for what was to come.
In 2021, the Radio Equipment Directive (RED) was updated to address not just traditional radio safety, but also cybersecurity for internet-connected devices (everything from walkie-talkies to smart IoT gadgets).
By January 2023, the Network and Information Security Directive 2 (NIS 2) took effect, strengthening cybersecurity requirements for critical infrastructure operators and essential service providers.
August 2025 saw the Artificial Intelligence Act (AI Act) become effective. It classifies AI systems by risk level and imposes strict requirements on high-risk applications, particularly those affecting human rights, safety, and public trust.
Just months later in December, the Cyber Resilience Act (CRA) came into force, setting mandatory cybersecurity requirements for all products with digital elements sold in the EU.
The compliance challenge: overlapping requirements
The complexity becomes apparent when you look at where these regulations intersect. Three major areas create particularly challenging overlaps.
Risk management
Though risk management is a common requirement, each law takes its own approach:
- NIS 2 focuses on institutional risk management, including business continuity plans, backups, disaster recovery.
- The CRA requires technical safeguards for products themselves: protection of essential functions, resilience against denial-of-service attacks.
- The AI Act demands comprehensive risk management specifically for high-risk AI systems.
- RED addresses spectrum uses and network integrity.
Even when requirements sound similar, the details differ. NIS 2 mentions "cryptography" while CRA specifically requires "encryption". These are subtle but important distinctions.
Notifications
Both NIS 2 and CRA require organisations to notify authorities about incidents and vulnerabilities, but they're coming at it from different angles.
Under NIS 2, institutions must report operational incidents within strict timeframes: 24 hours for early warning, 72 hours for full notification. Under CRA, manufacturers must disclose product vulnerabilities within similar timeframes but focusing on the products themselves rather than operational incidents.
The timelines match, but the perspective and focus differ.
Certification
Perhaps the most complex overlap involves certification.
The CSA provides voluntary certification schemes that other regulations reference. If a product is certified under a CSA scheme, it gains "presumption of conformity" under the CRA. Meanwhile, NIS 2 entities may be required by national authorities to procure only certified products.
Certification approaches also differ across regulations. Some allow self-assessment, others require third-party audits, and the compatibility between different certification schemes remains limited.
What this means in practice
To understand how these overlapping requirements work in the real world, let's look at three different scenarios. Each demonstrates how a single system can trigger multiple regulations at once.
The modern power plant
A modern power plant with AI-powered predictive maintenance systems and wireless sensors sits at the intersection of all five regulations.
As critical infrastructure, it falls under NIS 2's strictest requirements. The AI systems trigger the AI Act's obligations for high-risk systems. Every connected device must meet CRA standards. The wireless sensors invoke RED requirements. And CSA certification becomes valuable for demonstrating supply chain security.
Autonomous delivery drones
Autonomous delivery drones present an even more dynamic challenge. They're regulated as transport infrastructure under NIS 2. Their autonomous navigation systems trigger high-risk AI Act requirements.
The drones themselves are products with digital elements under CRA. Their wireless communication must comply with RED. And again, CSA certification helps streamline the complexity.
But unlike a fixed facility, drones operate across different jurisdictions and environments, adding another dimension to compliance management.
Healthcare AI
An AI-powered clinical decision support system must satisfy NIS 2 requirements because hospitals are essential entities. The AI components trigger full AI Act compliance. The underlying IT infrastructure falls under CRA (unless already covered by medical device regulations). Any wireless connectivity invokes RED.
The stakes are particularly high here, as the systems directly affect patient health and safety.
The cost of complexity
What emerges from these examples is a pattern: the more sophisticated and connected a system becomes, the more regulations it triggers.
A simple standalone product might only need to comply with CRA. Add wireless connectivity, and RED applies. Make it smart with AI, and the AI Act kicks in. Deploy it in critical infrastructure, and NIS 2 requirements layer on top. Use external components, and you need CSA-certified supply chain elements.
For large organisations with dedicated compliance teams, this is manageable, but expensive. For small and medium enterprises, it can be overwhelming.
The research paper found that compliance costs increase not just by adding them up but by multiplying them with system complexity. Worse, there's significant duplication of effort. You might conduct a risk assessment for NIS 2, another for the AI Act, and yet another for CRA, covering similar ground but documenting it differently for each framework.
A different approach: building compliance in
This is where the concept of compliance-by-design comes in. Rather than treating compliance as a checklist to complete before launch, the idea is to weave regulatory requirements into the software development process from the very first design meeting.
The principle is like building accessibility into a website from the start rather than adding it later. When organisations design with compliance in mind from day one, they create systems that are inherently more secure, more transparent, and more trustworthy.
This approach has three key components:
- Lifecycle integration
- Design patterns
- Automation and tooling.
Lifecycle integration maps compliance activities to each development phase. Teams identify applicable laws at the planning stage, conduct impact assessments during requirements analysis, implement security-by-default in the design phase, maintain supply chain security in implementation, and run conformity assessments at testing. Throughout deployment and maintenance, they continuously monitor risks and vulnerabilities.
Design patterns provide reusable solutions to common compliance problems. Products can ship with secure-by-default configurations, with security built in from the start. Risk management processes run continuously throughout the organisation. AI systems log decisions for transparency. Documentation is automatically generated through compliance artefact pipelines. And dual-boundary architectures separate functions governed by different laws to simplify assessment.
Automation and tooling reduce the manual burden. Software bills of materials (SBOMs) can be automatically generated to track components. Threat modelling tools can be adapted to include regulatory risk taxonomies. Compliance dashboards can track conformity across all regulations in real time. And increasingly, AI-powered tools can help process legal requirements and check system configurations against them.
Implications for different stakeholders
The implications vary depending on where you exist in the ecosystem.
For IT suppliers and product manufacturers, early integration of compliance is essential. The complexity of the product directly affects compliance costs. Multi-functional systems trigger obligations across multiple regulations at once, making strategic choices about certification increasingly important.
For deployment organisations responsibility extends beyond simply buying compliant products. Proper configuration, integration, and monitoring matter. Even if individual components are certified, the integrated system may require re-certification based on how it is deployed and in what context.
For policymakers, the fragmented landscape presents both opportunities and challenges. Despite shared principles, each law introduces different terminology, definitions, and timelines. The urgent need is for harmonisation – sector-specific guidance that shows how requirements interact and compatible standards that reduce duplication.
For researchers, compliance-by-design opens new questions. How do we formally model legal obligations in ways that software can understand? How do we build compliance-aware development tools? How do we create continuous certification workflows that integrate with agile methodologies? These are open challenges that combine software engineering, legal informatics, and systems design.
Building a better framework
The research paper concludes with five key recommendations for creating a more integrated approach to compliance.
- Regulatory coherence. Legal compatibility where a single certification can demonstrate conformity with multiple laws would reduce duplication and lower barriers, especially for smaller organisations.
- Unified EU cybersecurity framework. Something similar to the NIST cybersecurity framework in the United States could provide a comprehensive operational structure that helps organisations meet obligations across all regulations.
- Stronger role for ENISA. Clearer authority for the agency to provide harmonised guidance across the EU.
- Simplified pathways for small and medium enterprises. Modular certification approaches where SMEs can certify one module at a time, supported by clear guidelines and financial assistance.
- Global alignment. Coordinated certification schemes could avoid redundant or contradictory requirements, particularly where cybersecurity and AI accountability intersect.
The road ahead
Europe's cybersecurity regulations have created an unprecedented challenge: several laws now govern the same systems, with overlapping requirements that multiply compliance costs and effort. But this complexity also points to a clear solution.
The path forward isn't to navigate each regulation separately. It's to embed compliance into the software development process from the start. As the researchers put it:
"Much like software must now be secure-by-design, the future of trustworthy digital technologies will require them to be compliant-by-design."
This shift requires action at every level. Policymakers need to prioritise regulatory coherence and develop unified frameworks. Industry needs to adopt lifecycle integration, design patterns, and automation tools. And organisations of all sizes need to recognise that compliance-by-design isn't just about meeting legal requirements. It's about building more secure, trustworthy systems that give you a competitive edge in Europe's digital marketplace.
The regulatory landscape will continue to evolve, but the fundamental shift is clear: compliance is no longer an afterthought. It's becoming integral to software engineering itself.
Read the full paper:
- Daniele Canavese, Afonso Ferreira, Liina Kamm, and Adrian Quesada Rodriguez, "Uncovering challenges of cybersecurity cross-regulation in EU legislation", Information and Software Technology, 2026.