NIS2 and the Cyber Resilience Act: What IT Teams in Government Actually Face

The Regulation Is Live. Most Teams Are Not Ready.

When NIS2 transposition deadlines started hitting member states in late 2024, I spoke with several people running IT in public bodies. The pattern was consistent: legal had flagged the directive, someone had written a summary memo, and the actual engineering and delivery teams had not changed a single process. The Cyber Resilience Act was either unknown or treated as a future problem. Both reactions are understandable. Both are expensive.

I want to be direct about what this article is and is not. It is not a legal opinion, and I am not a lawyer. It is a practical read from someone who has shipped production systems under GDPR, built AI platforms with compliance constraints baked in from day one, and watched large organisations confuse policy documentation with actual security posture. NIS2 and the Cyber Resilience Act together represent a real shift in what governments and their suppliers must do, not just say they do.

What NIS2 Actually Changes for Public Sector IT

The original NIS Directive from 2016 covered a narrow set of operators of essential services and digital service providers. NIS2, which member states were required to transpose by October 2024, expands scope significantly. Public administration at national and regional level is now explicitly in scope as an essential entity in most member states. That means the obligations are not optional guidance — they are legal requirements with supervisory teeth.

The core obligations that matter most for IT delivery teams are these:

• Risk management measures. You must have documented, implemented, and tested measures covering incident handling, business continuity, supply chain security, network security, access control, cryptography, and multi-factor authentication. A policy document in a SharePoint folder does not satisfy this.
• Incident reporting. Significant incidents must be reported to the national competent authority within 24 hours of awareness for an early warning, and a full notification within 72 hours. If you do not have monitoring and alerting that can surface a significant incident within hours, you are already non-compliant in practice.
• Supply chain security. This one is underestimated. NIS2 explicitly requires that entities assess the security of their suppliers and service providers. In public sector IT, where procurement chains are long and vendor relationships are often managed by contract officers rather than engineers, this is a real gap. If your ERP vendor, your cloud provider, or your systems integrator has a weak security posture, that is now your problem to document and manage.
• Management accountability. Senior management can be held personally liable for non-compliance. This changes the conversation when you need budget for security tooling or want to push back on a procurement that skips a security review.

One thing I have seen repeatedly in large IT programmes — and I saw it in global transformation work across multiple countries — is that security is treated as a workstream that runs in parallel and signs off at the end. NIS2 makes that model legally untenable for essential entities. Security requirements need to be in the project scope from day one, not a checklist at go-live.

The Cyber Resilience Act: A Different Layer, and a Harder One for Procurement

The Cyber Resilience Act is distinct from NIS2 in an important way: it targets products with digital elements, not just the organisations operating them. It passed into EU law in 2024 and its main obligations for manufacturers apply from 2027, with some provisions earlier. If you are a public sector organisation that procures software — which is all of you — this matters because it shifts what you should be demanding from suppliers.

The CRA requires that products with digital elements are designed with security by default, that vulnerabilities are actively managed and disclosed, and that security updates are provided throughout the product's support lifetime. For commodity software this will largely be handled by vendors. But in government IT, a significant share of systems are custom-built, heavily modified COTS, or maintained by small suppliers who have never run a formal vulnerability disclosure programme.

Here is where I see the practical problem. Public sector procurement cycles are slow. A contract signed today for a system going live in 2026 may have been scoped in 2023. The CRA's requirements were not in that scope. When the system needs to be maintained and patched through 2030, who is responsible for the security update obligations? If the supplier is a small integrator and the contract did not address this, the answer is unclear and the risk lands with the public body.

The takeaway for anyone involved in IT procurement in government right now: CRA compliance obligations need to be in tender specifications and contract terms. Not as a checkbox, but with clear responsibilities for vulnerability management, update timelines, and end-of-support policies. This is not hypothetical future work. The systems you are procuring today will be in scope when the CRA obligations apply.

Where Public Sector Teams Are Most Exposed Right Now

From what I have seen in large programmes and from building my own production systems, the gaps tend to cluster in a few specific places.

Monitoring and detection

The 24-hour early warning requirement under NIS2 is only achievable if you have centralised logging, alerting, and someone who looks at the alerts. Many public bodies have perimeter security but limited internal visibility. A breach that starts inside — through a compromised credential, a phishing attack on a staff account, a vulnerable internal system — may not surface for days. That is not a technology problem in isolation; it is a governance and resourcing problem.

Third-party and open source components

Building CVChatly, I track every dependency, every library version, every API we call. I do this partly for cost control, partly for GDPR, and partly because a vulnerability in a transitive dependency is still my problem. In large government systems, especially older ones, the software bill of materials is often unknown. The CRA will require manufacturers to maintain an SBOM. Public bodies running custom systems should start treating this as their responsibility now, not when the regulation applies.

Legacy systems and patching cycles

This is the hardest one. Government IT runs on systems that cannot be patched on a rolling basis because downtime windows are constrained, because the vendor no longer supports the version, or because patching breaks something else. NIS2's risk management requirements do not exempt you from this because the system is old. Compensating controls, network segmentation, and accelerated migration plans are the realistic responses. None of them are cheap or fast.

Supply chain visibility

I have run programmes where the primary integrator used four sub-contractors, two of which were unknown to the client until an audit. NIS2's supply chain security requirements mean you need to know who is in your chain and what their security posture looks like. This requires contract clauses, security questionnaires, and periodic reviews. Most public sector vendor management does not operate at this level of detail today.

What to Actually Do This Quarter

I am not going to end with a list of 20 recommendations. Here is what I would prioritise if I were leading IT delivery in a public body right now.

1. Map your scope honestly. Are you an essential entity under NIS2 as transposed in your member state? Do not assume the answer. Check the national implementing legislation. If you are in scope and have not started, you are already late.
2. Close the gap between policy and practice on incident detection. The 24/72-hour reporting clock starts when you become aware. Invest in making sure you become aware quickly. Centralised logging and a defined incident classification process are the minimum.
3. Add CRA requirements to your next procurement. If you are specifying a system today, include vulnerability management obligations, SBOM delivery, and update commitments in the contract. It is much harder to add these after signature.
4. Brief senior management on personal liability. NIS2's management accountability provisions are a lever. Use them to get security onto the agenda at the level where budget decisions are made.
5. Start your software inventory. You cannot manage what you cannot see. A basic inventory of systems, versions, and support status is the foundation for everything else.

Neither NIS2 nor the Cyber Resilience Act is the end of the story. The EU's regulatory stack for digital and AI is still being built out. But these two are live and binding now. The teams that treat them as a compliance exercise to be documented will find themselves in a difficult position when the first significant incident happens and the supervisory authority asks what measures were actually in place. The teams that treat them as an engineering and governance challenge — and start closing real gaps — will be in a much stronger position. That is the work worth doing.