TL;DR: Teleport reports that nearly 66% of businesses operating in Europe have likely not implemented the controls needed for NIS2 compliance, leaving access control, logging, and incident-handling obligations exposed as enforcement pressure rises. Identity governance is now a regulatory control surface, not a background security task.
At a glance
What this is: This is Teleport's analysis of NIS2 compliance gaps, arguing that many organisations still lack the access control, MFA, logging, and incident-response controls the directive expects.
Why it matters: It matters because NIS2 turns identity controls and auditability into enforcement issues, so IAM, PAM, and NHI teams need evidence, not assumptions, that controls exist and operate consistently.
By the numbers:
- Nearly 66% of businesses operating in Europe have likely not implemented the necessary compliance controls for NIS2.
- For Essential entities, administrative fines may be up to 10 million euros or 2% of annual revenue, whichever is higher.
👉 Read Teleport's analysis of NIS2 compliance gaps and identity controls
Context
NIS2 is a regulatory and operational security problem, not just a deadline problem. The directive expects organisations to prove access control, incident handling, logging, and risk management across systems that support critical services.
For identity teams, the gap is straightforward: if access is not tied to policy, if audit trails are incomplete, or if incident response cannot act on identity events quickly, compliance becomes hard to demonstrate and easier to challenge.
Teleport's article places those governance weaknesses in an enforcement frame, where identity controls, monitoring, and reporting are no longer optional programme improvements but part of regulatory exposure.
Key questions
Q: What breaks when access governance is weak under NIS2?
A: Weak access governance creates both security exposure and compliance failure. If organisations cannot show who approved access, who removed it, and when those decisions happened, they struggle to prove control effectiveness. That gap matters most for contractors, leavers, generic accounts, and sensitive applications where standing access quickly becomes unnecessary trust.
Q: Why do identity controls matter so much for NIS2 compliance?
A: Because NIS2 compliance depends on proving who had access, what they could do, and how quickly you can respond when something goes wrong. Identity controls create the evidence trail for access control, incident handling, and accountability. Without reliable identity telemetry, incident reporting becomes slower, less accurate, and harder to defend.
Q: What are the signs that NIS2 auditability is failing?
A: The clearest signs are fragmented logs, missing session detail, inconsistent access records, and response teams that cannot reconstruct who changed what. If investigators need manual stitching across systems to explain an event, the audit trail is not yet fit for NIS2 scrutiny.
Q: What should organisations do when NIS2 compliance and live incident response conflict?
A: They should design policy enforcement so it can support incident response instead of competing with it. That means access controls, monitoring, and containment actions must be connected enough to act on suspicious identity events before the incident becomes a reporting and governance failure.
Technical breakdown
NIS2 access control obligations are really identity governance obligations
NIS2 does not introduce a new identity model, but it does require organisations to prove that access is controlled, justified, and reviewable. That means MFA, continuous authentication, least privilege, and account governance are not separate hygiene tasks; they are evidence that the organisation can restrict unauthorised access to critical services. For NHI estates, the same logic applies to service accounts, tokens, and privileged automation because enforcement will not distinguish between human and machine access when impact lands on the business. The control question is whether access can be shown to be deliberate and bounded.
Practical implication: Treat NIS2 access-control evidence as an identity governance deliverable, not a security operations afterthought.
Auditability depends on complete session and change logging
A compliant access model is only as strong as the logs that prove it. NIS2 places heavy emphasis on incident reporting and comprehensive records of access and system changes, which means organisations need audit trails that capture who accessed what, when, and what changed during the session. If logs are fragmented across infrastructure, directory services, and cloud control planes, the organisation may still be secure in practice but unable to demonstrate control to regulators. For high-risk access, the absence of session detail is often the difference between defensible monitoring and unusable evidence.
Practical implication: Centralise access and change logging so investigators can reconstruct identity-led activity without gaps.
Policy enforcement and incident intervention must work together
The directive expects organisations to maintain cyber policies and intervene quickly during incidents. In practical terms, that means policy cannot stop at written standards, and incident response cannot wait for manual identity triage. The governance chain has to connect authentication, authorisation, monitoring, and intervention so that risky access can be restricted when suspicious behaviour appears. This is especially relevant where long-lived credentials, standing privilege, or weak access reviews make it hard to tell whether access is still legitimate. Compliance failures often begin long before the incident, in the controls that were never operationalised.
Practical implication: Align policy enforcement with incident response so identity events can trigger containment without manual delay.
Threat narrative
Attacker objective: The objective is to move from ordinary access into high-value systems while preventing the organisation from proving what happened or responding cleanly.
- Entry occurs when access control is weak enough that users or workloads can reach sensitive systems without strong identity assurance or appropriate privilege boundaries.
- Escalation follows when standing privilege, weak MFA, or long-lived credentials let the attacker expand from ordinary access into higher-value systems and administrative actions.
- Impact appears when the organisation cannot produce reliable logs, enforce response actions, or prove compliance after the incident, increasing both operational and regulatory damage.
NHI Mgmt Group analysis
NIS2 turns identity governance into an enforcement issue: The directive does not merely ask organisations to improve security posture, it creates a compliance test for access, logging, and intervention. That shifts IAM and PAM from supporting disciplines to evidence-bearing controls. The practical conclusion is that identity programmes now need audit-ready operating proof, not just policy language.
Auditability is the control that separates compliance intent from compliance reality: If access events, session actions, and configuration changes are not reconstructable, organisations cannot demonstrate the kind of operational discipline NIS2 expects. Logging quality therefore becomes a governance issue, not only a detection issue. Practitioners should treat incomplete telemetry as a compliance defect, not a tooling inconvenience.
Standing privilege is now a regulatory liability as much as a security one: NIS2's access-control expectations expose the weakness of persistent entitlements that remain active outside a verified need. When privilege outlives the task, the organisation inherits both breach exposure and evidentiary weakness. Identity teams should regard privilege persistence as an audit failure condition, not just an architecture choice.
Policy without intervention is hollow: The article's emphasis on incident handling shows that controls only matter if they can be enforced during live events. A written policy that cannot trigger identity-based containment does not satisfy the operational intent of the directive. The implication is that compliance teams must examine whether their response path can actually act on access events in time.
What this signals
Identity evidence has become part of regulatory resilience: NIS2 pushes organisations to prove that access, logging, and intervention are working together, not as isolated controls. For practitioners, the immediate test is whether a suspicious access event can be traced, contained, and reported without relying on manual reconstruction.
Persistent access is harder to defend under NIS2 than under earlier compliance models: When standing privilege and long-lived credentials remain in place, the organisation inherits both breach exposure and an inability to explain access decisions cleanly. That makes privileged identity cleanup a compliance priority as much as a security one.
For practitioners
- Build NIS2 evidence packs around identity controls Map access control, MFA, logging, and incident-handling evidence to the systems that support essential or important services, then assign ownership for each evidence stream.
- Eliminate standing privilege from critical access paths Review privileged accounts, service accounts, and emergency access so that persistent entitlements are replaced with task-scoped access and documented approval flows.
- Verify that audit logs reconstruct sessions end to end Confirm that access requests, session activity, and configuration changes can be tied together across infrastructure, directory, and cloud systems without manual stitching.
- Test whether incident response can act on identity events Run exercises that start with suspicious login, privilege abuse, or credential compromise and confirm containment steps can be executed through your access tooling.
Key takeaways
- NIS2 turns identity control quality into a compliance issue because access, logging, and incident handling now sit inside an enforcement frame.
- The article cites nearly 66% of businesses operating in Europe as likely lacking the necessary compliance controls, which shows the scale of the gap.
- Practitioners should focus on audit-ready identity governance, not just written policy, because evidence is what will stand up under scrutiny.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | NIS2 compliance here depends on provable control of identities and entitlements. |
| DE.CM-01 — Networks and Network Services Monitored | The article stresses monitoring and logging for access and incident reporting. | |
| RS.CO-02 — Incidents Reported | NIS2 emphasises incident handling and reporting obligations after suspicious events. | |
| Recommendation — Enforce PR.AA-05 to keep critical access bounded, reviewed, and evidence-backed. Use DE.CM-01 to ensure identity events and access changes are continuously monitored. Apply RS.CO-02 to formalise reporting paths for identity-related incidents and findings. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article discusses removing static passwords, SSH keys, and long-lived tokens. |
| AU-2 — Audit Events | Comprehensive access and system change logging is central to the article's auditability argument. | |
| Recommendation — Use IA-5 to govern authenticator lifecycle, rotation, and revocation for privileged access. Define AU-2 events to capture access requests, sessions, and configuration changes for evidence. | ||
Key terms
- NIS2 Compliance Evidence: NIS2 compliance evidence is the operational record that proves controls are working, not just written down. It usually includes access logs, incident timestamps, approval history, supplier reviews, and revocation records that show governance was executed consistently across the organisation.
- Auditability: Auditability is the ability to reconstruct who or what acted, what permissions were used, and what data or tools were touched. For AI and NHI governance, it is the minimum evidence needed to investigate incidents, validate controls, and prove that autonomous actions stayed within approved scope.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Identity-Based Authorization: Identity-based authorization grants access based on verified identity attributes instead of network location. For remote devices, that means labels such as customer, region, or lifecycle state can control access even when the underlying transport changes.
What's in the full article
Teleport's full post covers the operational detail this post intentionally leaves for the source:
- How Teleport maps secure infrastructure access features to NIS2 access, monitoring, and reporting expectations
- A breakdown of the directive's penalty exposure for Essential and Important entities
- Operational examples of how identity-based access reduces standing privilege and long-lived credential risk
- Teleport's explanation of how its logging and policy controls support auditability under NIS2
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 17, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org