Privileged Access Management Under NIS2: The Four Admin-Account Rules in CIR 11.3 — and Why Just-in-Time Isn’t One of Them

Under NIS2, privileged access management comes down to four binding rules for admin accounts, a review duty and a separate set of rules for the systems admins log in to. They sit in points 11.3 and 11.4 of the Annex to Commission Implementing Regulation (EU) 2024/2690. Point 11.3.2 has no “where appropriate” qualifier, which is rare in that Annex. Just-in-time access, the feature most PAM vendors lead with, isn’t in the regulation at all. It comes from ENISA’s guidance. The only time limits the regulation sets on this kind of access apply to suppliers and other third parties, not to your own admins.

This guide separates the binding text from the good practice, maps where else in the Annex privileged access is regulated, and sets out a build path for organisations that can’t justify a five-figure PAM licence.

Does This Apply to You?

In plain terms: the Directive asks every essential and important entity for “access control policies”. The detailed admin-account rules bind eleven types of digital provider word for word. For everyone else they are the most detailed EU benchmark available, but national law sets the actual rules.

Who you are	What binds your privileged access	Practical effect
DNS provider, TLD registry, cloud, data centre, CDN, managed service provider (MSP), managed security service provider, online marketplace, search engine, social network or trust service provider	Implementing Regulation 2024/2690, Article 1 and Annex point 11 (directly applicable)	Points 11.3 and 11.4 apply verbatim. An auditor can test each letter.
Any other essential or important entity	Article 21(2)(i) and (j) NIS2, as transposed into national law	You need access control policies and, where appropriate, MFA. Your national authority sets the detail. The Annex is a strong reference.
Supplier with admin access to an in-scope customer	Your customer’s contract and their point 6.7.2(h) controls	Expect your remote sessions to be approved one by one and time-boxed.

Article 21(1) of Directive (EU) 2022/2555 makes the measures “appropriate and proportionate”, weighed against your exposure to risk, your size, and the likelihood and severity of incidents. A 40-person MSP and a hyperscaler face the same four rules but can meet them very differently.

Note: national transposition laws and supervisory practice vary by Member State. Confirm the local rules with your competent authority.

What CIR Points 11.3 and 11.4 Actually Require

In plain terms: admins get a second, separate account, use it only for admin work and only from admin systems, carry no more rights than the job needs, prove who they are strongly, and have those rights checked on a schedule you set.

Here is the operative text of the Implementing Regulation’s Annex, with the qualifier that controls how much room you have:

Point	What it requires	Qualifier
11.3.1	Maintain policies for privileged and system administration accounts as part of the access control policy	None, “shall”
11.3.2(a)	Strong identification, authentication “such as multi-factor authentication”, and authorisation procedures for those accounts	None. MFA is the named example.
11.3.2(b)	Specific accounts used for system administration “exclusively”, such as installation, configuration, management or maintenance	None
11.3.2(c)	Individualise and restrict admin privileges “to the highest extent possible”	Built into the wording
11.3.2(d)	Admin accounts are only used to connect to system administration systems	None
11.3.3	Review privileged access rights at planned intervals, modify them after organisational changes, document the results	None. You set the interval.
11.4.2(a)–(c)	Use admin systems only for admin work, separate them logically from other application software, protect access with authentication and encryption	None

Two readings matter in an audit. First, 11.3.2(a) names MFA as an example of strong authentication, not the only option, though anything weaker for domain or cloud admins would be hard to defend. Recital 23 of the same regulation says MFA “should be considered” in particular for privileged and admin accounts. Recitals don’t bind, but they show intent. Our guide to NIS2 MFA requirements covers which methods hold up.

Second, the regulation’s Article 2(2) only lets you skip a requirement marked “where appropriate”, “where applicable” or “to the extent feasible”, and only with documented reasons. Point 11.3.2 carries none of those phrases. If you are one of the eleven provider types, size shapes how you meet it under the proportionality test in Article 2(2), but the text offers no documented opt-out from it.

Privileged Access Rules Outside Points 11.3 and 11.4

In plain terms: a PAM project scoped only to point 11.3 will miss obligations sitting in the logging, network, training and identity sections.

A word search of the official English text finds “privileg” ten times and “administrat” 22 times. Set aside the recitals and unrelated uses such as “administrative fines”, add the clauses on supplier access and shared accounts, and these are the points an auditor can pull into a privileged-access review:

Annex point	What it adds to privileged access	Where it bites
3.2.3(b) and (e)	Logs include creation of users and “extension of the permissions”, plus “all privileged access to systems and applications, and activities performed by administrative accounts”	Introduced by “where appropriate”, so a decision to leave them out must be documented under Article 2(2)
6.7.2(e)	Systems used to administer security policy aren’t used for other purposes	Firewall and EDR consoles
6.7.2(h)	Service providers connect “only after an authorisation request and for a set time period, such as the duration of a maintenance operation”	Vendor and MSP remote access
6.8.2(f) and (g)	A separate network for administration, and admin channels segregated from other traffic	Management VLANs, jump hosts, out-of-band access
10.1.2(b)	Mechanisms so users with administrative or privileged access know and act within their roles and authorities	Admin onboarding, signed acceptance
11.2.2(a), (d), (e), (f)	Least privilege and separation of duties, third-party access limited “in scope and in duration”, a register of rights, logging of rights changes	The privileged-user register
11.5.3	Shared identities only where necessary, explicitly approved and documented	Root, built-in Administrator, break-glass accounts
11.6.2(f)	Separate credentials to access privileged or administrative accounts	No password reuse between a daily account and an admin account

The logging row is the one most often missed: session recordings that never reach your central log store leave 3.2.3 half done. See our NIS2 logging and monitoring guide for retention.

Just-in-Time Access: What’s Binding and What’s ENISA Guidance

In plain terms: the law requires time-limits for suppliers’ access. For your own admins, time-limited access is ENISA advice and a strong way to meet “restrict to the highest extent possible”, but no clause names it.

The phrase “just-in-time” appears zero times in the Implementing Regulation. It appears three times in ENISA’s Technical Implementation Guidance (June 2025): once as a control for shared accounts, once in a zero-trust overview, and once in a footnote on Microsoft 365. Vendor guides that present JIT as an ENISA or NIS2 requirement are reading too much into it.

What ENISA’s guidance on points 11.3.1 and 11.3.2 actually says is close to JIT in substance: “Grant temporary privileged access only for the time necessary to implement approved changes or activities (e.g. for maintenance activities), rather than permanently granting privileged access rights.” It also suggests expiry dates for privileged rights “where appropriate”, and allocating them “on an event-by-event basis”.

The binding time limits point outward, at third parties:

• Point 6.7.2(h) lets service providers connect only after an authorisation request and for a set period: per-session approval for vendor access.
• Point 11.2.2(d) limits third-party access rights “in scope and in duration”.

So a standing VPN account that your ERP vendor can use at any hour is hard to square with either point. Your own sysadmin holding permanent domain admin rights doesn’t breach a time clause, though you’d need to defend it against 11.3.2(c). Time-boxed elevation is the simplest defence.

ENISA’s Microsoft 365 footnote matters here. Where separate admin identities clash with Conditional Access or device-compliance policies, it accepts a single identity with compensating measures such as MFA, just-in-time access, session logging and context-aware controls. The regulation still says “specific accounts”, so record the clash and the compensating controls as a documented risk decision.

Break-Glass, Shared and Service Accounts

In plain terms: accounts more than one person can use are allowed only with a reason, an approval and a paper trail, and they must appear in your risk register.

Point 11.5.3 is the clause that covers emergency (“break-glass”) accounts held by more than one person, built-in root accounts and any credential a team shares. It permits them only “where they are necessary for business or operational reasons” with “an explicit approval process and documentation”, and it requires you to treat them in your risk management framework. ENISA’s guidance lists the controls it expects around them:

• check-out through a tool that logs who used the identity and when, or session recording or proxy auditing where check-out isn’t possible
• credential vaulting with automatic rotation
• time-bound or just-in-time access, MFA and least privilege
• a ban on keeping shared credentials in personal files, email or chat

The UK’s National Cyber Security Centre adds a useful design rule: break-glass access to your most critical systems “should only be used as a last resort”. It also places a PAM tool itself among the candidates for the most critical tier. If the vault goes down, the break-glass account is how you get back in, so test it and log every use.

Service accounts are the usual blind spot. Point 11.5.2(a) requires unique identities for network and information systems, not just people, and 11.5.4 requires identities you no longer need to be deactivated “without delay”. An integration account with domain admin rights that nobody owns is a finding under both.

Do You Need a PAM Suite? A Build Path by Size

In plain terms: no. ENISA’s guidance says to “consider” a centralised PAM solution, under its tips. The regulation requires outcomes, and smaller organisations can reach them with tools they already own.

Step	Anchor	Effort	Smaller organisation	Larger estate
1. Inventory every privileged and service account, with owner and systems	11.2.2(e), 11.5.2	Medium	Spreadsheet register from AD, cloud consoles and network kit	Automated discovery in the PAM or identity governance tool
2. Split admin and daily accounts, separate credentials	11.3.2(b), 11.6.2(f)	Low	Second account per admin, no mailbox, no browsing	Same, enforced by policy
3. Strong MFA on every admin account, phishing-resistant where you can	11.3.2(a)	Low–Medium	Hardware keys or the identity provider’s built-in MFA	Step-up MFA at elevation
4. Admin-only devices and network path	11.3.2(d), 11.4.2, 6.8.2(f)–(g)	Medium–High	Hardened jump host or dedicated admin laptop	Privileged access workstations, separate management network
5. Time-box elevation and vendor sessions	11.3.2(c), 6.7.2(h), 11.2.2(d)	Medium	Built-in role-activation features of the cloud provider; vendor accounts disabled until a ticket opens them	PAM approval workflows with automatic expiry
6. Vault shared and break-glass credentials	11.5.3	Low–Medium	Business password manager with access logging, sealed break-glass procedure	PAM vault with automatic rotation
7. Send admin activity to central logs	3.2.3(e), 11.4.1	Medium	Native audit logs forwarded to your log platform	Session recording plus SIEM alerting
8. Review privileged rights on a fixed cycle	11.3.3	Low	Documented review; ENISA’s quarterly minimum for identity reviews is a sensible baseline	Certification campaigns in the governance tool

Who owns what:

• CISO or IT security lead: steps 3, 4 and 7, plus the tiering of which systems count as most critical. NCSC’s tier model is a useful starting point.
• IT operations: steps 1, 2, 5 and 6, and the day-to-day approvals.
• Compliance officer: step 8, the exception register under Article 2(2), and evidence retention.
• Management body or SME owner: approving the access control policy and the budget call between steps that use existing tools and a suite. Under Article 34, failing to meet Article 21 can lead to fines with a maximum of at least €10 million or 2% of worldwide turnover for essential entities (€7 million or 1.4% for important ones), subject to national law.

Buy a suite when account numbers or vendor-session volume make manual approvals and spreadsheet reviews unreliable. If you already run Okta, our Okta NIS2 mapping shows where its privileged access product lands against 11.3 and 11.4.

The Evidence an Auditor Will Ask For

In plain terms: policy text, a list, approvals and review records. ENISA’s “examples of evidence” for points 11.3 and 11.4 come down to these:

• A privileged-account section in the access control policy (11.3.1). Our ISO 27001 access control policy template guide shows how ISO control 8.2 maps to it.
• A list of users with privileged access and the systems each can reach
• Approval records for each grant, including vendor sessions under 6.7.2(h)
• A role-based access matrix
• Network documentation showing how admin systems are separated (11.4.2(b))
• Logs of access to admin systems and of admin activity (3.2.3(e))
• Dated review records with the changes made (11.3.3), including a check that each admin’s duties still justify the access
• Approval and risk-register entries for every shared or break-glass account (11.5.3)
• Training records for admins (10.1.2(b))

One check catches more than any other: reconcile the review records against leavers. A privileged account that outlives its owner fails 11.3.3, 11.5.4 and 11.2.2(b) at once. Our employee offboarding checklist covers the revocation side.

Frequently Asked Questions

Is privileged access management mandatory under NIS2?

The controls are; the product category isn’t. For the eleven provider types bound by Implementing Regulation 2024/2690, points 11.3 and 11.4 are binding. ENISA only suggests considering a centralised PAM solution. Other NIS2 entities must meet their national version of Article 21(2)(i).

How often must privileged access be reviewed?

Point 11.3.3 says “at planned intervals” and leaves the interval to you. Write it into your policy and keep to it. ENISA suggests reviewing identities at least quarterly, or annually for micro-sized entities, which many organisations adopt for admin rights too.

Does an MSP’s remote access to our systems count as privileged access?

Usually, yes, and it carries the strictest binding time-limit in the Annex. Point 6.7.2(h) allows service provider connections only after an authorisation request and for a set period. Point 11.2.2(d) limits their rights in scope and duration.

For the wider picture of Article 21(2)(i), see our NIS2 access control and HR security guide.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

How This Guide Was Verified

Every Annex point and recital above was checked against the official English text of Implementing Regulation 2024/2690 on EUR-Lex, which we downloaded and searched directly. That search produced the word counts quoted here, including the absence of “just-in-time”, “PAM”, “vault” and “break-glass” from the regulation. ENISA’s guidance was read in its full June 2025 PDF. Where a step rests on guidance or practitioner judgement rather than binding text, the article says so.

Sources

1. Commission Implementing Regulation (EU) 2024/2690, Articles 1 and 2, Recital 23, and Annex points 3.2.3, 6.7.2, 6.8.2, 10.1.2, 11.2–11.6 — EUR-Lex
2. Directive (EU) 2022/2555 (NIS2), Article 21(1) and 21(2)(i)–(j)
3. Directive (EU) 2022/2555 (NIS2), Article 34(4)–(5)
4. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, June 2025 (points 11.3, 11.4, 11.5.3, 11.5.4)
5. National Cyber Security Centre (UK), Secure system administration: Risk manage administration using tiers