NIS2 Privileged Access: CIR 11.3 and 11.4 Requirements Explained

What NIS2 and CIR 2024/2690 require for privileged and admin accounts — separate identities, JIT elevation, vaulting, PAWs, session logging, and audit evidence.

← Back to hub · Prev: Authentication & MFA · Next: Mapping & audit-readiness →

Legal basis: NIS2 Art. 21(2)(i) and (j) · CIR (EU) 2024/2690 Annex 11.3 (privileged accounts and system-administration accounts), 11.4 (administration systems). Reinforced by logging requirements in 3.2 ("all privileged access … and activities performed by administrative accounts").

TL;DR (🔧 Engineering / 📋 GRC): Privileged accounts are the prize attackers want and the access NIS2 scrutinises most. Requirements: separate, dedicated admin identities (no daily-driver accounts with admin rights), least privilege + just-in-time elevation (no standing admin where avoidable), phishing-resistant MFA, vaulted credentials, full session logging/monitoring, and hardened, dedicated administration systems (11.4). Recital 23 singles out privileged and system-admin accounts for MFA.

1. Why privileged access gets its own treatment

The CIR carves privileged and system-administration accounts out as a distinct control (11.3) and adds a control for the systems used to administer the environment (11.4). The logging clause (3.2) separately mandates capturing all privileged access and all activity by administrative accounts. Read together, NIS2 expects privileged access to be minimised, strongly authenticated, tightly governed, and fully observable — because compromise of one admin account typically equals compromise of the estate.

2. Privileged & system-admin accounts (CIR 11.3) 🔧

Separate identities for privileged work

Administrators must use dedicated privileged accounts that are distinct from their normal user accounts. Email, browsing, and document work never happen from an account that holds admin rights. This contains phishing blast radius and keeps privileged activity cleanly attributable.

Least privilege & just-in-time (JIT)

• Eliminate standing privilege wherever possible. Instead of permanent admin membership, grant elevation on request, for a defined task, for a limited time, with approval — then auto-expire.
• Scope privileges narrowly (role/resource-specific admin, not global) and apply segregation of duties to privileged functions (02).
• This directly serves the least-privilege expectation in 11.2 and the access-control policy in 11.1.

Strong authentication for privileged access

Phishing-resistant MFA (FIDO2/passkeys, certificate-based/smart-card) for every privileged sign-in — recital 23 names privileged and system-admin accounts specifically. No SMS OTP, no MFA-bypass groups. (See 04 — Auth & MFA.)

Credential vaulting & secrets

• Privileged credentials and shared/emergency secrets held in a vault with check-out, automatic rotation, and access logging.
• Service/non-human privileged identities use managed secrets or workload identity, rotated, never embedded in code or config.

Unique attribution & no shared admin

No shared "root"/"administrator" logins for routine work. Where a built-in shared account is unavoidable, vault it and use break-glass procedures (below). Unique identity (11.5) makes the 3.2 logging meaningful.

Break-glass / emergency access

• A small number of emergency access accounts, vaulted, excluded from changes that could lock you out (e.g., conditional-access misconfig), protected with the strongest factors.
• Every use alerts and is reviewed; credentials rotated after use. Document and test the procedure.

Lifecycle & review

• Privileged grants are time-bound and reviewed frequently (quarterly or continuous via JIT) — see the cadence table in 03.
• On role change/exit, privileged access is revoked immediately and known shared secrets rotated.

3. Administration systems (CIR 11.4) 🔧

CIR 11.4 governs the systems and tooling used to administer the environment — the management plane — which must be protected to a higher standard than general endpoints because they are high-value targets.

• Dedicated, hardened admin workstations for privileged tasks — Privileged Access Workstations (PAWs) / Secure Admin Workstations — separated from general productivity use and internet browsing.
• Restrict and broker administrative access paths: admin interfaces reachable only from trusted, managed devices and networks (jump hosts/bastions, just-in-time network access), not exposed to the general user network or the internet.
• Harden and patch management tooling and infrastructure (configuration management, CIR 6.3; patching, 6.6) and segment the management plane (6.8).
• Tiered administration model: separate administration of high-value assets (e.g., identity infrastructure / domain controllers) from lower tiers so a compromised workstation can't pivot upward.

4. Logging & monitoring of privileged activity (CIR 3.2) 🔧 📋

The CIR explicitly requires logging of authentication-related events, all privileged access to systems and applications, and activities performed by administrative accounts. For privileged access this means:

• Full session capture/monitoring for sensitive administration (command logging or session recording where proportionate).
• Privileged logs shipped to tamper-resistant, centrally retained storage (admins shouldn't be able to erase their own tracks).
• Alerting on anomalous privileged behaviour, break-glass use, and new privilege grants.
• Retention aligned to your logging/incident policy and useful for incident investigation (CIR 3).

5. Implementation notes (vendor-neutral) 🔧

Examples, not endorsements.

Design rules:

1. Zero standing privilege as the target state; JIT + approval as the mechanism.
2. Admins never administer from their email/browse device — PAW or brokered session only.
3. All privileged auth is phishing-resistant MFA, no exceptions.
4. Privileged logs are immutable and centrally retained, with alerting on break-glass.

6. Evidence an auditor will ask for 📋

• Inventory of privileged/admin accounts (human and non-human) with owners and justification.
• Evidence of separate admin identities (admin accounts distinct from daily accounts).
• JIT/PIM configuration showing time-bound elevation and approvals; report of standing vs. just-in-time privilege.
• Phishing-resistant MFA enforced on all privileged sign-ins.
• Vault usage evidence: credential check-out, rotation, no embedded secrets.
• Break-glass procedure, account list, and recent use/review records.
• PAW / administration-system standards and proof admin paths are brokered/restricted (11.4).
• Privileged session logs with evidence of integrity, retention, and monitoring (3.2).
• Recent privileged-access review results.

Common gaps that become findings

• Permanent (standing) admin rights instead of JIT; large, stale admin groups.
• Admins using one account for email and administration.
• Privileged accounts on weak/no MFA, or in an MFA-bypass group.
• Shared root/administrator credentials used routinely, with no vault and no attribution.
• Admin interfaces reachable from ordinary workstations or the internet (no PAW/bastion).
• Privileged activity not logged, or logs writable by the admins themselves.
• No break-glass procedure — or one that is untested and unmonitored.

Sources

• NIS2 Art. 21 — risk-management measures (points (i), (j))
• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex (Annex §11.3, §11.4, §3.2; recital 23)

FAQ

What does NIS2 require for privileged accounts? CIR 11.3 requires dedicated admin identities separate from daily-driver accounts, elimination of standing privilege in favour of just-in-time elevation, phishing-resistant MFA for all privileged sign-ins, vaulted credentials with automatic rotation, and break-glass procedures for emergency access. Every privilege grant must be time-bound, approved, and logged. CIR 3.2 separately mandates tamper-resistant logging of all privileged access and admin activity.

Does NIS2 require just-in-time privileged access? The regulation requires least privilege (CIR 11.2) and separation of privileged accounts (CIR 11.3). While JIT is not named explicitly, eliminating standing privilege is the stated expectation — granting elevation on request, for a defined task, for a limited time, with approval, then auto-expiring. JIT via a PAM tool or PIM is the standard mechanism for meeting this expectation and demonstrating it.

What are Privileged Access Workstations under NIS2? CIR 11.4 governs administration systems — the workstations and tooling used for privileged administration. It requires dedicated, hardened admin workstations (PAWs) separated from general productivity and internet use, admin interfaces accessible only from trusted managed devices and networks (jump hosts, bastions), and a tiered administration model that prevents lateral movement from lower-tier compromises. Exposing admin interfaces to ordinary workstations or the public internet is a finding.

Does NIS2 require credential vaulting? CIR 11.3 requires secure credential management for privileged accounts, and the CIR's authentication clauses (11.6) require secure storage and revocation. A PAM vault with check-out, automatic rotation, and access logging is the standard implementation. Shared root credentials in plaintext, embedded passwords in code or config, and non-rotating service account passwords are explicitly the gaps auditors look for.

What privileged access logs must be retained for NIS2? CIR 3.2 requires logging of all authentication-related events, all privileged access to systems and applications, and all activities by administrative accounts. Logs must be shipped to tamper-resistant storage (admins must not be able to modify or delete their own audit trail), centrally retained, and available for incident investigation. Alerting on anomalous privileged behaviour, break-glass use, and new privilege grants is also expected.

How KINT helps: KINT automates the joiner, mover, and leaver access lifecycle across your SaaS apps and produces signed, timestamped access-review evidence mapped to SOC 2 CC6 — the kind of evidence NIS2 Article 21 expects you to be able to show. It is early-stage and self-serve, and runs without an identity provider. See how KINT handles the lifecycle or book a 15-minute walkthrough.