Compliance & Privacy · 2026-10-12
NIS2 Identity Assurance: What Essential Entities Must Evidence in 2027
By J. W. Bouckaert
Two sentences and one word of latitude
Directive (EU) 2022/2555 had to be transposed by 17 October 2024 and its measures applied from the following day. For identity, the directive itself says little. Article 21(2) lists ten cybersecurity risk-management measures that every essential and important entity must take under an all-hazards approach, and two of them are ours: point (i), "human resources security, access control policies and asset management", and point (j), "the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate".
The last two words carry a lot. Article 21(1) frames every measure as "appropriate and proportionate" and says that in assessing proportionality "due account shall be taken of the degree of the entity's exposure to risks, the entity's size and the likelihood of occurrence of incidents and their severity". Nothing in the directive names phishing-resistant authentication; the word phishing appears once, in a recital about cyber hygiene. Nothing names the eIDAS assurance levels. An entity looking for a checklist in the directive will not find one.
It will find one in two other places, and the rest of this post is about them. The Commission's Implementing Regulation (EU) 2024/2690 of 17 October 2024 specifies the Article 21(2) measures for one group of entities, and ENISA's technical guidance on that regulation, published 26 June 2025, says how the specification is met and what evidence shows it. Together they are the closest thing NIS2 has to a statement of what "where appropriate" means for authentication, and a supervisor in any Member State will have read both.
Essential or important, and the supervision that follows
Article 3 sorts entities by sector and size. Essential entities are the Annex I types (energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure, business-to-business ICT service management, public administration and space) that exceed the ceiling for a medium-sized enterprise, plus qualified trust service providers, top-level domain registries and DNS providers regardless of size, plus entities designated critical under the CER directive. Everything else in Annex I and II that meets the size threshold is important.
The label decides how you are supervised. Article 32 gives the authorities powers over essential entities that include "on-site inspections and off-site supervision, including random checks conducted by trained professionals", "regular and targeted security audits carried out by an independent body or a competent authority", ad hoc audits after a significant incident, and "requests for evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor and the respective underlying evidence". Important entities, under Article 33, are supervised ex post, "when provided with evidence, indication or information" of non-compliance. The fines differ too: a maximum of at least EUR 10 000 000 or 2 percent of worldwide turnover for essential entities, EUR 7 000 000 or 1.4 percent for important ones. Article 32(5)(b) lets an authority temporarily bar an essential entity's chief executive or legal representative from managerial functions; Article 32(6), which Article 33(5) extends to important entities, makes it possible to hold such natural persons liable for breaches of their duties. Article 20(1) is the clause that puts this on the board's agenda: management bodies must approve the risk-management measures, oversee their implementation, and "can be held liable for infringements by the entities of that Article".
The word "evidence" in Article 32(2)(g) is the one that matters for this post. An essential entity is not asked whether it has multi-factor authentication. It is asked to produce the audit result and the underlying evidence that shows it does, and the request can arrive as a regular audit rather than after an incident.
The implementing regulation: eleven requirements for access control
Implementing Regulation 2024/2690 applies directly to DNS service providers, TLD registries, cloud, data centre and content delivery providers, managed and managed security service providers, online marketplaces, search engines, social networks and trust service providers. Its Annex specifies the Article 21(2) measures in thirteen sections, and section 11, titled Access control, is where identity lives. For the entities it binds, these are the law; for everyone else they are the most detailed public statement of what the Commission thinks the directive requires, and the national authorities who transposed the directive for banks, hospitals and utilities are reading them too.
| Annex 2024/2690 | The requirement, as written | What shows it |
|---|---|---|
| 11.1 Access control policy | Policies "ensure that access is only granted to users that have been adequately authenticated" | The policy, with its approval date and the authentication strength it requires per asset class |
| 11.2 Management of access rights | Rights assigned and revoked on "need-to-know, least privilege and separation of duties" | The joiner, mover and leaver records; the last rights review with its date |
| 11.3 Privileged accounts | "Strong identification, authentication such as multi-factor authentication, and authorisation procedures for privileged accounts and system administration accounts" | The privileged account inventory and the authentication method enforced on each |
| 11.4 Administration systems | Access to system administration systems protected "through authentication and encryption" | Configuration of the administrative access path and its authentication |
| 11.5 Identification | "The full life cycle of identities"; unique identities, each linked "to a single person"; shared identities only under "an explicit approval process and documentation"; regular review, deactivation "without delay" | The identity register, the shared-account approvals, the deactivation log against the leaver list |
| 11.6 Authentication | Strength "appropriate to the classification of the asset"; credential change on suspicion of compromise; lockout after failed attempts; inactive session termination; separate credentials for privileged access; the most advanced authentication methods feasible (11.6.3) | The authentication policy per asset class, the lockout and session settings, and the review record 11.6.4 requires "at planned intervals" |
| 11.7 Multi-factor authentication | Users "authenticated by multiple authentication factors or continuous authentication mechanisms ... where appropriate, in accordance with the classification of the asset to be accessed"; strength appropriate to classification | The asset classification, the mapping from class to factor strength, and the logs showing the factors were used |
Two features of the text decide how it is read. Every authentication requirement is indexed to the classification of the asset being accessed, so the asset inventory in section 12 is the input to the identity evidence rather than a separate exercise: an entity that cannot say which class a system is in cannot show that its authentication strength was appropriate. And the phrase "where appropriate" survives from the directive into 11.7.1, but attached to the classification, which turns it from a latitude into a decision the entity must be able to justify per asset.
ENISA ranks the factors
The regulation does not say which factors are strong. ENISA's guidance does, in the section on requirement 11.6.2. "The use of phishing-resistant MFA is recommended", followed by a list ordered from strongest to weakest. The strong tier is phishing-resistant: "no shared secrets, not vulnerable to attacker-in-the-middle", with a "protected cryptographic private key" registered either "to a domain, in accordance with Fast Identity Online (FIDO) and W3C WebAuthn standards" or to a trust provider under PKI and X.509. Below it: "'Medium' MFA, for example: push notification, number matching or application based." Below that: "'Last resort' MFA, for example: text message or email OTP." Its list of MFA options for 11.7.1 describes text-message OTP as "simple but less secure due to risks such as SIM swapping". It sets a floor for passwords of eight characters where MFA is used and fourteen where it is not, tells entities to "enforce MFA on internet-facing systems, such as email, remote desktop and VPNs", and defines continuous authentication as a mechanism that "dynamically assesses developing risk factors such as location, device status and behavioural patterns throughout the session".
The guidance also says what evidence looks like, requirement by requirement. For 11.7.1 it names two artefacts: "Logs showing MFA being used to access network and information systems" and an access control policy "outlining how different MFA methods are assigned, including whether phishing-resistant MFA is used". ENISA's legal notice is that the document represents its views and is for information; it is not binding on anyone. It is also the document a national auditor asked to judge whether an entity's authentication methods meet requirement 11.6.3 will open first, because there is no other.
Twenty-three laws, four referrals
The directive is transposed by national law, and by 2027 that is where the obligations actually sit. The Commission sent letters of formal notice to 23 Member States on 28 November 2024, reasoned opinions to 19 on 7 May 2025, and on 8 July 2026 decided to refer Ireland, Spain, France and the Netherlands to the Court of Justice for failing to notify transposing measures, asking for a lump sum and daily penalties. The Netherlands' Cyberbeveiligingswet then entered into force on 15 August 2026, after the referral decision. France's bill passed the Senate in March 2025 and is scheduled before the National Assembly on 7 October 2026. Ireland's national cyber security centre states plainly that the deadline "has not been met". Spain's government approved a draft in January 2025.
Where laws exist, their calendars differ. Belgium's law of 26 April 2024 and Italy's Legislative Decree 138/2024 applied from October 2024. Germany's took effect on 6 December 2025. Poland's law of 23 January 2026 gives entities six months to register, twelve to meet the substantive obligations and twenty-four for a first audit. Austria's NISG 2026 brings its substantive provisions into force on 1 October 2026 with registration due within three months. An entity operating in several Member States therefore faces the same Article 21 measures under laws that started on different dates, with different registration and audit deadlines, and different supervisors with different habits.
The identity evidence does not change with the law. Every transposition has to implement Article 21(2)(i) and (j), every supervisor will read the implementing regulation and ENISA's guidance as the reference for what those mean, and the artefacts in the table above satisfy all of them. That is the practical reason to build the evidence to the regulation and the guidance rather than to any single national text: the national text tells you when, the EU texts tell you what.
An evidence pack for 2027
Working from the regulation's numbering, an essential entity should be able to produce the following for its identity and access controls without notice, because Article 32 lets the request arrive that way.
- The asset classification (section 12) that every authentication requirement is indexed to, with the class of each system that holds or reaches the entity's critical services.
- The access control policy (11.1), approved by the management body under Article 20(1), stating the authentication strength required per class and, per ENISA's evidence list, "whether phishing-resistant MFA is used" and where.
- The identity register (11.5): every identity, the person it is linked to, the shared identities with their written approvals, and the deactivation log reconciled against leavers.
- The privileged account inventory (11.3 and 11.6.2(f)): every privileged and administrative account, the separate credential it uses, and the factor strength enforced on it.
- Authentication configuration evidence (11.6.2): lockout thresholds, session timeouts, the credential rotation policy and the record of a rotation triggered by a suspected compromise, if one happened.
- Factor logs (11.7.1): the authentication logs showing which factors were used for access to each class of asset, over a period long enough to cover the review interval 11.6.4 requires.
- The review record (11.6.4 and 11.5.4): when the authentication methods and the identity register were last reviewed and what changed.
- Incident linkage (Article 3(1)(e) of the regulation): any "successful, suspectedly malicious and unauthorised access" is a candidate significant incident, so the identity evidence for the account involved has to be retrievable for the report.
The eighth item is where identity assurance and incident reporting meet, and it is worth building for on purpose. A supervisor investigating an incident will ask which factors the compromised account used and whether the policy required more; the answer has to come from the logs in item 6 and the policy in item 2, and the two have to agree.
Carrier state in the pack
ENISA's ranking puts SMS at the bottom for a stated reason, SIM swapping, and the regulation's continuous-authentication option in 11.7.1 asks for a mechanism that reassesses risk during a session. The carrier-signal path is one such mechanism: a check of the SIM's state at the network, fresh at the moment of a privileged action rather than at login, which is evidence about the possession factor that SMS assumes and cannot verify. It does not make an SMS code phishing-resistant, and nothing does; it is a way of noticing, on a channel the attacker does not control, that the possession factor has changed hands. In the evidence pack it shows up twice: as a control in the policy for the asset classes where it is applied, and as a log line beside the factor log when it fires. The PCI DSS post shows the same pairing against a different standard's wording, and the DORA register post has the field-owner discipline that keeps the pack current between audits.
Left open
Three things this post cannot settle. Whether national supervisors will treat ENISA's ranking as the measure of requirement 11.6.3 is a question their first audit cycles will answer, and the Polish and Austrian calendars put those cycles in 2027 and 2028. Whether the Commission will extend the implementing regulation's approach to sectors beyond digital infrastructure is a policy question with no announced answer. And how the four referrals resolve, and whether the Dutch case is withdrawn now that the law is in force, will be decided in Luxembourg. The evidence pack above is built so that none of those answers changes what an entity has to show; only who asks, and when.