What Does NIS2 Actually Require for Hospital Staff Identity?

June 18, 2026 ·Mairi Kutberg ·

nis2hospital-staff-identityhealthcare-cybersecurityessential-entityidentity-proofingarticle-21implementing-regulation-2024-2690icao-9303eidas

Yes — Annex I of Directive (EU) 2022/2555 lists healthcare as an essential entity sector. Commission Implementing Regulation (EU) 2024/2690 sets the technical requirements. Hospital staff identity proofing is implicit in Article 21(2)(i) access control and explicit in the Implementing Regulation's identity management language. The audit-defensible answer is upstream chip-anchored proofing.

What Does NIS2 Actually Require for Hospital Staff Identity?

Yes — Annex I of Directive (EU) 2022/2555 lists healthcare as an essential entity sector. Commission Implementing Regulation (EU) 2024/2690 (effective 17 October 2024) sets the technical requirements. Hospital staff identity proofing is implicit in Article 21(2)(i) access control measures and explicit in the Implementing Regulation's identity management language. The audit-defensible answer is upstream chip-anchored proofing.

I sit in compliance audits with hospital CISOs and IT leads roughly every quarter, and the NIS2 question that has dominated 2026 — what does NIS2 actually require us to do for staff identity? — has a more specific answer than the typical vendor pitch suggests. The answer sits in three different EU legal instruments and one ENISA guidance document, and the gap between what the documents require and what most hospitals currently ship is where the first audit cycle's findings are landing. The fastest way I've found to walk through it is by answering the four questions that come up on the call, in order. The rest of this post is those four questions and the answers I give.

Are hospitals "essential entities" under NIS2?

Yes — every public and private hospital that crosses the size threshold, plus EU reference labs, medical device manufacturers, in-vitro diagnostic manufacturers, basic pharmaceutical producers, and R&D firms in the medicinal field.

Annex I of Directive (EU) 2022/2555 names healthcare as one of the eleven essential-entity sectors. The Directive distinguishes essential entities (subject to proactive ex-ante oversight — regular audits, on-site inspections, security scans, even in the absence of an incident) from important entities (subject to reactive ex-post enforcement after an incident). Both categories must implement the same ten cybersecurity risk-management measures under Article 21(2); the difference is the supervisory posture.

The size threshold matters more for healthcare than for many other sectors because the legal definition catches more entities than the colloquial "hospital" boundary. A specialist diagnostic lab providing services to twenty regional hospitals is essential; a regional pharmacy chain operating across three Member States is essential; a CRO running clinical trials on behalf of pharma majors is essential. The compliance question lands on a wider population than the procurement budget usually anticipates.

What I'd push back on at the start of any compliance audit conversation is the framing that NIS2 is "mostly about IT". For hospitals, the larger procurement implication is staff identity — the people accessing the patient record, signing the prescription, authenticating to the laboratory information system. That is what the auditor will actually ask about first, and it is where the largest gap between current state and required state typically sits.

What identity-proofing language sits in the Implementing Regulation 2024/2690?

More than the Directive itself, and more than most vendor decks acknowledge.

Commission Implementing Regulation (EU) 2024/2690, effective from 17 October 2024, fleshes out the ten Article 21(2) measures into operational requirements. The measures most directly relevant to staff identity are (i) policies on access control and asset management, and to a lesser extent (j) multi-factor authentication. The Implementing Regulation's Annex spells out what "access control" means at the technical level: a documented identity-management process at staff onboarding, with verification of the identity claimed against an authoritative document or registry, retained as auditable evidence.

This is where the language gets specific and most vendor pitches get vague. The Implementing Regulation does not name biometric passport NFC chip reads as the only acceptable identity-proofing method. It does require an identity-proofing process whose outputs are retained in a form a third-party auditor can inspect months later. Document-based onboarding with manager sign-off is technically a process — but it produces evidence the auditor can reasonably contest, particularly given the parallel patient-safety obligations under the European Health Data Space (Regulation (EU) 2025/327) that compound on the same hospital systems.

ENISA's NIS2 Technical Implementation Guidance walks through what good looks like for each of the ten Article 21(2) measures. The identity-management section emphasises verifiability — the audit must be able to confirm not just that a process was run, but that the process produced evidence consistent with the standard of assurance the institution claims. The honest reading of this paragraph in the ENISA guidance is that chip-anchored or document-plus-liveness verification produces evidence at substantial assurance (NIST SP 800-63A IAL2); manager-attested document scans typically produce evidence below that.

Why does the typical hospital staff onboarding fail an NIS2 audit?

Because the evidence chain breaks at the moment of verification.

In the audits I've sat in on across 2025 and early 2026, the recurring finding is not that the hospital has no identity-proofing process. It is that the process produces evidence the auditor cannot independently verify. A regional hospital in Belgium presented its onboarding flow at last quarter's audit cycle: a candidate provides a photocopied national ID, an HR officer reviews and signs an attestation, the document is stored on a network drive. The process is documented. The evidence is retained. The audit finding came in three parts: (1) the photocopy is not verifiable against the issuing authority's records; (2) the HR officer's attestation depends on subjective assessment of the photograph; (3) the storage location is accessible to staff outside the chain of custody. None of these are unusual in 2026 hospital onboarding. All three are increasingly difficult to defend at audit.

What I see in the pattern across the audits is that the hospital teams who do well on identity-proofing are the ones who treated the Belgium 18 April 2026 NIS2 audit deadline as a technical deadline, not a documentation deadline. They didn't only write new policies — they replaced the proofing primitive. The ones who treated it as a documentation deadline are the ones receiving audit findings now and revisiting the proofing layer under time pressure.

The compliance question that catches hospitals isn't whether they have MFA on the staff workstation. It's whether the first moment of identification — the moment the institution assigns an identity that everything downstream depends on — produces evidence the auditor can independently verify against the issuing authority. MFA is what comes after. Identity proofing is what comes first.

How do you build an NIS2-defensible hospital staff identity stack?

Move the proofing primitive upstream, anchor it on something the auditor can verify independently, and retain the evidence as an AdES record.

The mechanism is the same shape as the answer in the EHDS patient-identity post but applied to staff. At onboarding, the candidate scans the NFC chip of their biometric passport (ICAO Doc 9303) with the hospital's onboarding application — what we ship as the Identity Verification product. For staff whose document is pre-NFC or who present a non-ICAO national ID, document authenticity verification plus biometric face match (FaceTec liveness) runs through the same flow and produces an equivalent record at substantial assurance. Both routes cover every applicant: NFC for the 179 ICAO 9303 countries and document-plus-face-match for every remaining country. The output is a record signed by an issuing state (chip route) or attested by a certified liveness vendor (fallback route), retained as an Advanced Electronic Signature (AdES) under eIDAS Article 26 — our Signatures product at the implementation level.

What this changes for the audit is structural. When the auditor asks how staff identity is verified, the answer becomes a binary cryptographic check rather than a narrative reconstruction. The chip's signature either verifies against the ICAO trust list or it doesn't; the liveness check either passes or it doesn't; the AdES record either authenticates against the institution's signing key or it doesn't. The HR officer's subjective assessment exits the chain. The auditor's job becomes faster and the institution's defensibility becomes binary.

The thing the auditor will actually ask first, in my experience, is not "do you have MFA" but "show me the evidence chain from the moment this clinician was first identified at your institution to the moment they accessed this patient's record". That chain has to hold under inspection. The Belgian hospital I described above failed because the chain ran through a photocopy and an attestation. The hospitals that pass are the ones whose chain runs through a state-signed chip read or a certified-vendor liveness attestation, both retained as AdES records.

What I'd put on the audit-defensible list this quarter, for any hospital-side compliance lead working toward NIS2 conformity:

Replace document scans with chip-anchored proofing for new staff onboarding in the next audit cycle window. Backfill for existing staff is hard; the new-hires baseline is achievable.
Retain the proofing record as an AdES artefact under eIDAS Article 26. The MFA tooling layered on top references this record at every subsequent authentication, rather than asserting identity independently.
Treat the identity-proofing primitive as separate procurement from MFA / SSO / IAM. These solve different problems; bundling them through a single vendor obscures the assurance chain the auditor needs to trace.
Document the chain end-to-end before the next audit cycle. The audit asks for evidence, not for narrative.

The architecture isn't novel. What's new in 2026 is that the NIS2 audit cycle now makes it expensive to skip it.

Hospital staff identity-proofing maturity model — four ascending levels from paper-based onboarding (audit-failing) to document scan plus MFA (audit-fragile), then crossing the NIS2 Article 21(2)(i) audit-defensible threshold to chip-anchored proof (audit-defensible) and chip plus AdES plus cross-border-portable (audit-strong).

Sources

Primary — NIS2 and implementing instruments

Primary — adjacent regulatory framing

Primary — identity-proofing standards

About the author

Mairi Kutberg is co-founder of IdentiGate. She focuses on identity-proofing operations under eIDAS, NIS2, AMLR, the AI Act, the EHDS, and adjacent regulatory frameworks, and on the institutional reality of running cross-border identity verification at scale.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.