Author: Veli-Pekka Vähälummukka, Program Director, Trivore
The NIS2 directive has landed in the Nordics. Not as a single event, but as a rolling wave of national legislation that is reshaping how organisations think about cybersecurity — and, specifically, how they manage identity and access.
If you work in identity, security, or compliance, this matters to you. Not in the abstract, but in terms of what your team needs to deliver in the next twelve months.
This post walks through what NIS2 actually requires from your identity systems, provides a concrete compliance checklist, and highlights the mistakes we see organisations making as they prepare.
Where the Nordics stand on NIS2
The directive is European, but implementation is national. Each Nordic country has transposed NIS2 into its own legislation, on its own timeline:
- Finland enacted the Cybersecurity Act (kyberturvallisuuslaki) in April 2025. It is now in force and enforceable.
- Denmark began enforcement in July 2025, folding NIS2 into its existing critical infrastructure framework.
- Sweden passed its NIS2 law effective 15 January 2026, applying to both essential and important entities.
- Norway, through the EEA Agreement, is bringing roughly 5,000 organisations into scope by July 2026, with the first supervisory audits expected by October 2026.
All four countries chose what regulators call a “minimalistic transposition” staying close to the directive baseline without gold-plating. This means the requirements are largely consistent across borders, which is helpful for organisations operating in multiple Nordic countries.
One aspect that deserves attention: personal liability. Finland’s Cybersecurity Act explicitly places risk management responsibility on senior management. This is not a theoretical concern. It changes the conversation from “the IT department handles compliance” to “the board needs to understand our identity posture.” Sweden and Norway have similar provisions in their implementations.
The directive itself is specific about identity. Article 21(2)(i) requires “access control policies” as part of cybersecurity risk management. Article 21(2)(j) calls for “multi-factor authentication or continuous authentication solutions.” These are not buried in annexes — they are named requirements in the core text.
What NIS2 actually requires from your identity systems
Let us translate the legal language into practical terms. NIS2 touches six areas of identity management directly.
1. Access management policies — documented, enforced, auditable
It is not enough to have access controls in place. The directive expects documented policies that define who gets access to what, under which conditions, and how those policies are enforced. Many organisations have informal practices but lack the documentation an auditor would expect. The gap is usually not in the controls themselves, but in the ability to demonstrate them.
2. Strong authentication — MFA as baseline
Multi-factor authentication is explicitly named in the directive. This goes beyond user-facing applications. Administrative interfaces, API access, and internal systems all fall within scope. Organisations that have rolled out MFA for customer-facing systems but left internal tools on single-factor are only partially compliant.
3. Supply chain security — identity governance extends to contractors and third parties
NIS2 requires organisations to address risks from their supply chain, including ICT service providers. In identity terms, this means contractor and partner access must be governed with the same rigour as employee access. In most organisations, this is where governance breaks down — contractors are provisioned manually, rarely reviewed, and often forgotten at offboarding.
4. Incident handling — who had access to what at time of breach
When a security incident occurs, one of the first questions a regulator will ask is: which identities had access to the affected systems? If you cannot reconstruct the access picture at the time of the incident — not today, but at the moment it happened — you have a gap. This requires point-in-time access records, not just current state.
5. Logging and audit trails — immutable, retrievable, covering full identity lifecycle
Audit trails must cover the complete identity lifecycle: creation, modification, access grants and revocations, authentication events, and deprovisioning. These logs need to be immutable (not editable after the fact) and retained for a period consistent with regulatory expectations. A log that only shows current access is not sufficient.
6. Privileged access management — elevated accounts tracked and reviewed
Accounts with elevated privileges — system administrators, database owners, service accounts with broad permissions — require additional oversight. NIS2 expects these accounts to be inventoried, monitored, and subject to regular review. The common practice of shared admin accounts with static passwords is a direct compliance risk.
The pattern across all six areas is the same: NIS2 does not ask for perfection. It asks for documented, enforced, auditable processes. The gap for most Nordic organisations is not in technology but in governance — the policies, reviews, and evidence that turn tools into controls.
A 10-point identity compliance checklist
These are concrete steps your organisation can take. For each, we note whether it addresses a direct NIS2 requirement or represents a best practice that supports compliance.
1. Map all identity sources.
Before you can govern identity, you need to know where identities live. HR systems, Active Directory, cloud directories, contractor databases, shared spreadsheets — many organisations have identity data scattered across five or more sources. Until you have a complete map, you cannot assess your risk.
NIS2 relevance: foundational for access management policies.
2. Establish a single authoritative identity store.
One system should be the source of truth for identity. This does not mean discarding other systems — it means designating one as authoritative, with other sources feeding into it. Without this, you will always have conflicting data about who has access to what.
NIS2 relevance: required for demonstrable access control.
3. Implement MFA across all systems.
Not just customer-facing applications. Administrative consoles, VPN access, API management portals, internal tools with sensitive data — all need MFA. Prioritise systems based on the sensitivity of the data they protect and the privilege level of their users.
NIS2 relevance: directly required by Article 21(2)(j).
4. Automate joiner-mover-leaver processes.
When someone joins the organisation, changes roles, or leaves, access should be adjusted automatically based on their relationship to the organisation — not based on a ticket that someone remembers to submit. Manual provisioning and deprovisioning is the single largest source of access governance failures.
NIS2 relevance: supports enforceable access policies and incident readiness.
5. Introduce access reviews on a defined cadence.
At minimum, review access rights quarterly. This means a structured process where managers or system owners confirm that the access assigned to people in their area is still appropriate. Certification campaigns should cover both regular and privileged accounts.
NIS2 relevance: directly supports auditable access management.
6. Enforce segregation of duties rules.
Certain combinations of access rights create unacceptable risk — for example, the ability to both create and approve financial transactions. These rules need to be defined, encoded in your identity systems, and enforced automatically. Manual enforcement does not scale and does not satisfy audit requirements.
NIS2 relevance: best practice supporting risk management obligations.
7. Bring non-human identities under governance.
Service accounts, API keys, machine-to-machine tokens, and increasingly AI agents all represent identities that can access your systems. Most organisations govern human identities reasonably well but have limited visibility into non-human identities. These need the same lifecycle management: creation, review, rotation, and deprovisioning.
NIS2 relevance: access control policies must cover all identities accessing network and information systems.
8. Ensure audit trail is immutable and separately stored.
Your identity event log should be tamper-proof and stored independently from the systems it monitors. If an attacker compromises an identity system and can also modify the audit log, the log is worthless. Separate storage, write-once policies, and integrity verification are the minimum.
NIS2 relevance: directly required for incident handling and regulatory reporting.
9. Document and test break-glass procedures.
What happens when your primary identity provider is unavailable? Emergency access procedures need to be documented, stored securely (including offline copies), and tested regularly. A break-glass procedure that has never been tested is a plan, not a capability.
NIS2 relevance: Supports business continuity and requirements for handling incidents.
10. Assign identity governance ownership at management level.
Someone at the management level — not in the IT team, but reporting to or part of senior leadership — needs to own identity governance. This person is accountable for the policies, the reviews, and the compliance posture. Under NIS2, particularly with Finland’s personal liability provisions, this is not optional.
NIS2 relevance: directly required by management accountability provisions.
What most organisations get wrong
In working with organisations preparing for NIS2, four patterns appear repeatedly:
1. Treating NIS2 as a pure IT project.
The directive explicitly requires senior management involvement in risk management. Identity governance is not something you can delegate entirely to the security team and consider handled. Management needs to understand the identity posture, approve the policies, and take ownership of the residual risk. When Finnish authorities come asking questions, they will not accept “IT handles that” as an answer.
2. Focusing on perimeter security while leaving identity governance to manual processes.
Many organisations have invested heavily in firewalls, endpoint protection, and network monitoring. These are important. But if your identity governance still runs on spreadsheets, email requests, and manual approvals, you have a structural weakness. The perimeter model assumes threats come from outside. Identity governance addresses what happens when someone already inside — or someone who should no longer be inside — has more access than they should.
3. Assuming Microsoft Entra ID covers governance
Entra ID is a capable identity provider. It handles authentication, federation, and conditional access well. But it is not an identity governance and administration (IGA) platform. It does not natively support access certification campaigns, segregation of duties enforcement, contract-based lifecycle management, or cross-system provisioning governance. Organisations that equate “we have Entra ID” with “we have identity governance” are conflating authentication with governance. These are different layers with different requirements.
4. Underestimating the non-human identity problem
For every human identity in a typical enterprise, there are multiple non-human identities: service accounts, application identities, API tokens, automated processes, and now AI agents. These identities often have broad privileges and rarely go through the same governance processes as human accounts. NIS2 does not distinguish between human and non-human identities when it requires access control policies. Neither should you.
How to start
If you have not begun preparing, start with an identity maturity assessment. This does not need to be a six-month consulting project. A structured review of your current identity sources, governance processes, access review practices, and audit trail capabilities will reveal where the largest gaps are.
Prioritise based on your regulatory deadline. If you are in Finland, enforcement is already live. If you are in Norway, you have until July 2026 to be in scope, but October 2026 audits will come quickly. Sweden’s January 2026 effective date means that organisations there should already be executing, not planning.
The checklist in this post is a reasonable starting point. Not every item needs to be completed before your regulatory deadline — but every item needs to be on your roadmap, with a timeline and an owner.
If you want to benchmark your organisation’s identity readiness against NIS2 requirements, the Trivore team is happy to walk through an assessment. No pitch — just an honest look at where you stand and what needs attention first.