NIS2 compliance is now a supply chain issue for critical services

At a glance

What this is: NIS2 is an EU cybersecurity directive that broadens compliance obligations to essential organisations and their third-party providers, with a strong focus on risk management, incident reporting, and senior accountability.

Why it matters: It matters to IAM, PAM, and broader security teams because access control, supplier oversight, and identity governance now sit inside a regulated operational resilience model, especially where third parties touch critical services.

By the numbers:

• The directive requires an early warning of a significant incident within 24 hours of becoming aware of it.
• Essential entities can face fines of up to €10 million or 2% of total worldwide annual turnover, whichever is higher.
• Important entities can face maximum fines of €7 million or 1.4% of worldwide annual turnover, whichever is higher.

👉 Read Expel's guide to NIS2 compliance and third-party obligations

Context

NIS2 is a regulatory response to a wider problem in critical infrastructure security: attackers increasingly reach high-value services through third parties, weak access control, and inconsistent incident handling. For identity and access teams, that means the perimeter is no longer just the organisation itself, but every provider that can influence privileged access or operational availability.

The directive is also a governance signal. It moves cybersecurity from a technical concern into senior management accountability, and it forces organisations to prove that access control, reporting, and response processes can operate under time pressure. That makes the identity layer, especially MFA, supplier access, and privileged oversight, part of compliance evidence rather than a background control.

Key questions

Q: What do security teams get wrong about third-party access under NIS2?

A: They often treat vendor access as a connectivity issue instead of a governance issue. NIS2 makes external access part of the regulated attack surface, which means every supplier pathway needs explicit boundaries, ownership, and containment logic. Broad persistent access is not operational convenience; it is unmanaged exposure.

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 do organisations get wrong about NIS2 reporting readiness?

A: They assume alert volume is the main problem, when the real gap is evidence production. A team may detect incidents quickly and still fail if it cannot create a structured timeline, preserve decision points, and package the result in a regulator-ready form within the required windows.

Q: Who is accountable when supplier access contributes to a NIS2 incident?

A: Accountability sits with the organisation that owns the service, because NIS2 expects supplier risk to be governed inside operational resilience processes. In practice, that means business owners, identity teams, and security leadership must share responsibility for access issuance, review, and revocation, especially when third-party credentials touch critical systems.

Technical breakdown

How NIS2 turns supplier access into a regulated control surface

NIS2 broadens the security boundary to include third parties that deliver services to essential and important entities. That matters because supply chain compromise often arrives through legitimate access paths, not overt exploitation. Once a supplier account, support connection, or managed service pathway is trusted, attackers can blend into normal operations unless access is tightly scoped and continuously monitored. In practice, the directive pushes organisations to treat supplier identity governance as part of their core resilience model, not a procurement afterthought.

Practical implication: map every third-party access path, assign ownership, and remove any standing supplier privilege that is not essential.

Why incident reporting becomes an identity and process problem

NIS2 imposes short reporting windows, which means incident detection, triage, and evidence collection must be coordinated quickly. If identity telemetry is incomplete, teams lose time establishing who accessed what, when access was granted, and whether compromised accounts were used laterally. That makes identity logs, privileged session records, and authentication events part of the reporting chain. The control challenge is not only detecting an incident, but proving impact and scope fast enough to meet regulatory deadlines.

Practical implication: retain centralised identity and access logs long enough to support 24-hour notification and 72-hour reporting.

How MFA and access control fit into NIS2 compliance evidence

The article links NIS2 compliance to secure access control, including MFA. That is important because regulators will expect organisations to demonstrate that access to critical systems is not based on reusable, weak, or unmanaged credentials. MFA alone is not the full answer, but it is one of the clearest signals that access is being protected proportionately. In regulated environments, access control must extend from workforce logins to service access, admin pathways, and vendor connections.

Practical implication: verify that MFA coverage extends to privileged, remote, and third-party access, not just employee sign-in.

NHI Mgmt Group analysis

NIS2 makes identity governance a compliance control, not just an IAM programme concern. The directive’s emphasis on access control, incident handling, and supplier oversight means identity teams are now supporting regulatory assurance as much as security posture. That shifts the evaluation standard from "is access managed" to "can access management be evidenced under audit and incident pressure". Practitioners should treat identity governance as part of operational resilience.

Third-party access is the most under-discussed NIS2 risk multiplier. The article correctly highlights that suppliers to essential entities are pulled into scope, which means delegated access, support privileges, and offboarding discipline all become compliance-sensitive. A supplier can create both an availability risk and a reporting problem if its access paths are not tightly governed. Practitioners should inventory every external identity with production reach.

Reporting deadlines expose the quality of identity telemetry. A 24-hour warning window and 72-hour notification requirement are only realistic when authentication, privilege, and session data are easy to correlate. Where logs are fragmented across tools or vendors, teams spend their time reconstructing events instead of handling them. Practitioners should assume that poor identity observability becomes a regulatory weakness, not just an operational inconvenience.

Corporate accountability will force boards to care about privileged access decisions. NIS2’s management liability provisions change the conversation around MFA, access reviews, and supplier oversight because these controls now map to leadership exposure. That tends to accelerate funding for controls that can be measured, attested, and defended. Practitioners should prepare to explain identity risk in terms leadership can sign off on.

What this signals

Supplier identity governance will become a measurable resilience control. NIS2 pushes organisations to prove not just that access exists, but that access is reviewed, limited, and recoverable under incident pressure. Teams that cannot show clean third-party identity lifecycle control will struggle to defend both their security posture and their compliance position.

Reporting readiness will increasingly depend on access telemetry quality. The practical difference between compliance and delay is often whether identity events are centralised, searchable, and retained long enough to reconstruct an incident. That makes identity logging and privileged access evidence a core input to resilience planning, not an auxiliary security task.

For practitioners

• Inventory third-party access paths Document every supplier, MSP, and contractor identity that can reach production or regulated environments, including remote support channels, API access, and break-glass accounts.
• Extend MFA to privileged and third-party access Verify that MFA is enforced for administrative logins, remote access, vendor connections, and any workflow that can change critical infrastructure settings.
• Test incident reporting against identity telemetry Run tabletop exercises that use real identity logs, privileged session records, and authentication events to prove you can assemble a 24-hour and 72-hour report.
• Assign ownership for supplier offboarding Make one team accountable for revoking third-party access at contract end, after service changes, and whenever supplier privileges outlive their business need.

Key takeaways

• NIS2 turns supplier access, incident reporting, and executive accountability into linked compliance issues.
• The strongest evidence of readiness is not policy language but the ability to trace identity activity quickly enough to meet reporting windows.
• Organisations that can govern third-party access lifecycle and privileged telemetry will be better placed to satisfy both regulators and internal risk owners.

Key terms

• NIS2: The European Union's updated cybersecurity directive for essential and important entities. It requires organisations to demonstrate stronger cyber resilience through risk management, incident reporting, supply chain oversight, and access control, with identity governance playing a central role in how those obligations are proven.
• Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.
• Incident Reporting Window: An incident reporting window is the time period within which an organisation must detect, assess, and notify authorities about a security event. Under NIS2, the speed of reporting turns telemetry, ownership, and triage discipline into compliance requirements rather than optional process improvements.
• Identity Telemetry: Identity telemetry is the collection of signals generated by authentication, session, and access events across human and non-human identities. It becomes useful for governance when teams can baseline normal behavior and detect drift in source, privilege, or access frequency.

What's in the full article

Expel's full guide covers the operational detail this post intentionally leaves for the source:

• Sector-by-sector explanation of which organisations fall into essential and important entity categories
• The full incident reporting timeline with 24-hour, 72-hour, and one-month reporting obligations
• Practical compliance preparation steps for companies acting as third-party providers to regulated entities
• Additional detail on how managed detection and response services align to NIS2 readiness

👉 Expel's full guide explains the reporting deadlines, supply chain scope, and compliance preparation steps in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps security and identity practitioners connect lifecycle controls to the operational realities of access, audit, and resilience.