Atlas ApexAtlasApex

NIS2 · Identity Lens

NIS2

Identity is a NIS2 risk-management measure, an incident-reporting input, and a supply-chain control all at once.

Full name
Network and Information Security Directive 2
Region
European Union
Applies to
Essential and important entities across 18 sectors: energy, transport, banking, healthcare, digital infrastructure, public administration, manufacturing, postal, waste, food, chemicals, research, ICT service management, providers of digital services.

NIS2 (Directive (EU) 2022/2555) replaces the original NIS Directive and significantly expands the scope of EU cybersecurity rules. Member states had to transpose by 17 October 2024. The directive shifts cybersecurity from a technical compliance exercise to a board-level accountability with personal liability for management, harmonised incident reporting, and explicit minimum risk-management measures.

What it asks for

The Identity Lens

The clauses that bite when identity architecture is weak, rewritten in plain English. Authoritative text is linked below.

Access control and authentication (Article 21, §2(i))

Strong authentication for privileged accounts, controlled administrative access, MFA where appropriate to the level of risk, and processes that govern joiner / mover / leaver. NIS2 does not prescribe a specific MFA technology, but expects the choice to be proportionate to the threat model.

Supply chain security (Article 21, §2(d))

Identity is the dominant supply-chain attack vector. NIS2 requires entities to manage the security risks arising from relationships with their suppliers and service providers, which in identity terms means federated access, scoped tokens, third-party MFA enforcement, contractor lifecycle, and the ability to revoke supplier access at speed.

Incident handling (Article 21, §2(b) and Article 23)

Identity-related incidents (credential compromise, privileged-account abuse, federated trust failure) fall squarely inside the 24-hour early-warning, 72-hour notification, and 1-month final-report cadence. The identity team needs a forensic audit trail that can answer who-did-what-when fast enough to meet that timeline.

Risk-management measures (Article 21)

Identity controls have to be part of an all-hazards risk-management policy, not a parallel programme. Posture management, segregation of duties, access reviews, and continuous evaluation are all in scope as basic cyber hygiene.

Where teams miss it

Common Misses

Patterns we see again and again — usually because the identity programme runs in parallel to the compliance programme rather than inside it.

Treating MFA rollout as the identity requirement, while leaving non-human identities (service accounts, API keys, agents) outside the programme.

Documenting an identity policy that the directory cannot actually enforce — joiner/mover/leaver on paper, manual provisioning in practice.

No clear identity contribution to the 24-hour / 72-hour incident timeline. The audit trail is theoretical.

Supply-chain identity controls limited to vendor questionnaires. Federated trust, contractor offboarding, and token lifetimes go ungoverned.

What works

Where Design Pays Off

Patterns we have seen survive supervisory review, audit, and the next change.

Identity treated as one of the named NIS2 risk-management measures, with a single owner across workforce, customer, machine, and supplier identity.

Operational identity posture management connected to the incident pipeline so reporting deadlines are achievable, not aspirational.

A documented decision register that maps each identity control to a NIS2 article — defensible for the supervisory authority and useful for the architecture team.

Need a NIS2-ready identity baseline?

We start with an assessment that maps your identity controls to NIS2 requirements, then design and operate the gaps.

Book a Conversation