IR 2024/2690 11.3 privileged accounts: NIS2 requirements

What NIS2 privileged account requirements ask for in plain terms

Under point 11.3 of the Annex to Implementing Regulation (EU) 2024/2690, an entity must have written policies for managing privileged and system administration accounts, and those policies sit inside the access control policy rather than beside it. An assessor or customer asking how these accounts are controlled is really asking three things: who holds admin rights, how those rights are proven to be the right people with the right rights, and how the organization knows the list stays correct over time. Point 11.3.2 expects the policy to require strong identification and authentication, including multi-factor authentication, dedicated accounts used only for administration, individualized and restricted admin privileges, and admin accounts that connect only to administration systems. Point 11.3.3 adds that access rights of these accounts be reviewed at planned intervals, adjusted when the organization changes, and the review results documented. The policy owner should confirm the review interval and the trigger events in their own environment, since the regulation requires planned intervals without fixing a number.

The risk behind these duties is well understood. Shared administrator credentials, accounts with more rights than the job needs, and admin accounts used for email and web browsing are the easiest route for an attacker to move from a single compromised user to control of the wider system. Once an attacker holds a privileged session, logs and access reviews are the only way to show what happened, which is why point 3.2.3(e) asks for logging of privileged access and administrative activity where appropriate.

In practice, this area is hard for three reasons. First, the inventory of privileged accounts is usually incomplete, because admin rights accumulate through group nesting, service roles and forgotten project grants. Second, legacy shared admin credentials, such as a root password held in a password manager by several engineers, are difficult to retire without breaking scheduled jobs. Third, vendor and support accounts often sit outside internal identity management, with standing access that nobody reviews. Start by producing a list of privileged users and the systems they reach, since that list is the first piece of evidence an assessor will ask for.

Which privileged and administration accounts fall under point 11.3

Point 11.3 applies to every account that can change security-relevant configuration, reach administration systems or act with elevated rights, not only the accounts named in an IT org chart. The cards below walk through the account types and scoping decisions that determine how much of the estate the policy must cover, and they tie each choice back to the asset inventory and the entity's risk assessment.

Human administrators and power users

Named staff who hold domain admin, root, database owner or cloud owner rights form the core of the scope, and every one of them needs a dedicated administration account separate from the daily work account. The harder question is application power users, such as a finance system super user who can change approval thresholds. Decide that by asking whether the role can alter access, logging or security settings. If it can, treat it as privileged. Confirm the decision in writing with the risk assessment rather than leaving it to each team.

Service and break-glass accounts

Service accounts that run backups, deployments or directory synchronization often hold standing elevated rights and rarely have an owner who reviews them. Break-glass accounts exist for emergencies and are easy to forget until the day they are needed. Both belong in scope. Record each one with its owner, the systems it reaches, how its credential is stored and who may use it, and check that interactive logon is blocked where a workload does not need it.

Vendor and supplier access

Remote support accounts held by managed service providers, software vendors and contractors are privileged access even when the entity does not employ the person. Their sessions usually cross the perimeter and may bypass internal approval steps. Scope them by listing the supplier identity, the systems it can administer, the window in which access is granted and the approval that opened it. Ask each supplier how it protects its own administration accounts, because that protection now sits inside your access control policy.

Administration consoles across layers

Point 11.3 reaches every layer where administrative rights exist: cloud control planes, directory services, hypervisors, network devices and application administration interfaces. Each layer can grant control over the layers beneath it, so a single cloud tenant owner can outweigh many server accounts. Map each console to the accounts that reach it, and note which consoles accept only admin-dedicated sessions. Point 11.4 then governs the systems behind these consoles, so the same inventory feeds both points.

Scope follows the asset inventory

The scope is only as complete as the list of systems it is drawn from. Start from the asset inventory required under point 12.4, identify which assets carry administrative functions, and attach the accounts that reach them. Assets that are retired, cloned or spun up by automation are the usual gaps. Confirm the inventory is current before you size the privileged account population, because an undercounted inventory produces an undercounted policy.

Scope follows the risk assessment

The risk assessment decides how strictly each privileged population is handled. A directory administrator supporting a critical service warrants tighter review, shorter approval windows and stronger logging than an administrator of a non-production test cluster. Document the criteria that move an account into a higher tier, such as reach across tenants or access to security logs. Revisit the tiering when the risk assessment changes, since the review intervals under point 11.3 depend on it.

How an assessor tests privileged account controls

This table compares each test step an assessor is likely to run against point 11.3, what they sample, the evidence they request and the findings that usually come up. Read it as a sequence: the first row tests the policy design, and the rest test whether the policy operates for real accounts. Confirm with your competent authority or the ENISA June 2025 guidance how each step is applied in your Member State.

Test step	What the assessor samples	Evidence requested	Common findings
Policy existence and design	The access control policy and its section on privileged and administration accounts	Approved policy with version history, owner and review date, showing the four required elements	Policy exists but omits admin-only connection paths or individualized privileges
Privileged user inventory	A sample of admin accounts compared against the list of privileged users and the systems each can reach	Current list of privileged users with systems, roles and approval references	Accounts in directory groups that never appear on the list, or shared admin logins
MFA enforcement for admin logins	A sample of admin login events and the enrolled second factors on those accounts	Authentication configuration, MFA enrollment records and login logs showing a second factor was checked	Admin accounts exempted from MFA, or recovery codes that bypass the second factor without approval
Separation of admin and daily-use accounts	Pairs of admin and standard accounts for the same person, and whether the admin account is used for email or browsing	Account naming and ownership records, and logs showing admin accounts used only for administrative tasks	Administrators using one account for both routine work and system changes
Admin-only connection paths	Routes used to reach administration systems, including remote access and jump hosts	Network or access diagrams, and access rules that restrict admin accounts to administration systems	Admin credentials accepted on general application servers or workstations
Review records	Periodic access reviews and a sample of changes made after reorganizations, role changes or leavers	Dated review records with reviewer, decisions (keep, change or revoke) and documented revocations	Reviews performed but not dated, or no record showing changes after organizational events
Privileged activity logs	Log entries for a sample of privileged sessions and administrative actions, and whether logs are protected	Audit trails of privileged access and admin activity, with retention settings and access controls on the logs	Logs disabled for some admin tools, or logs stored where administrators can edit them

How to implement privileged account controls in sequence

This sequence takes an organization from an unknown set of privileged access to a documented, enforced and periodically reviewed model that meets the point 11.3 expectations. Each step produces a record that an assessor or supervisor can test. The organization owns the decisions and sign-offs, while an implementation partner can prepare the systems and collect the evidence.

Inventory privileged accounts and administration systems
Identify every account with elevated rights, including named administrators, service accounts with administrative scope, break-glass accounts and vendor accounts, along with the systems each one can reach. Pull the data from directories, cloud consoles, hypervisors, network devices and applications, then reconcile it with HR and contractor records. The output is a list of privileged users and the systems they can access, and the owner of each system signs it off. The step is done when the list has no unexplained accounts.
Write the privileged account policy
Draft the policy as part of the access control policy, covering who may hold privileged rights, how they are approved, how strong authentication applies and how admin accounts are separated from daily accounts. Define the approval workflow and the criteria for granting and revoking elevated rights. The chief information security officer or equivalent role approves the policy, and management records its approval. The step is done when every requirement in point 11.3.2 has a named owner and a control described in the policy.
Separate administrative identities from daily accounts
Create dedicated admin accounts that are used only for administration, and remove administrative rights from everyday user accounts. Assign privileges individually and at the minimum level each role needs, so that no shared or generic administrator account remains without a named owner. The identity team confirms the change in the directory and the approval records for each granted right are stored. The step is done when the account inventory shows one identity per administrator and no everyday account holds admin rights.
Enforce strong authentication with a second factor
Require strong identification and multi-factor authentication for every privileged login, whether to the directory, the admin systems or the applications. Choose second factors the policy allows, such as TOTP apps, hardware tokens or passkeys, and document the enrollment process and the recovery method. Test the login path with a sample of administrators and record the results. The security team signs off, and the step is done when no privileged account can log in with a password alone.
Route admin sessions through admin-only systems with logging
Configure administration systems so they are used only for administration, are logically separated from other application software, and require authentication and encryption. Admin accounts should connect only to these systems, and their privileged activity should be written to audit logs that are protected from alteration. Confirm the logging scope with the monitoring team, including all privileged access and the activities of administrative accounts. The step is done when a test admin login from a standard workstation to a production system is blocked or logged as the policy requires.
Set the review cycle and document the outcomes
Set a review interval for privileged access rights, agree who performs each review and what counts as a finding, and schedule reviews after organizational changes such as reorganizations, departures or role transfers. Each review should keep, change or revoke access, and every decision should be recorded with the reviewer's name and date. The output is the access review and revocation record, which feeds back into the inventory. The step is done when the first review cycle is complete and its results are filed with the policy evidence.

Which evidence passes a privileged account review

ENISA's June 2025 guidance names a short set of artifacts that show who holds privileged access, why they hold it, and whether it was checked and removed when it should be. Each artifact needs a refresh routine between audits, because an assessor will test whether the record matches the live system on the day of review, not only whether the record exists.

Privileged user and system register

Keep a list of every privileged user and the systems, applications and administration consoles each one can reach. Build it from the directory and the systems themselves, not from a spreadsheet typed once. Export the privileged group membership on a fixed schedule, store each export with its date, and compare it with the previous export so that unexplained additions show up between audits. Check that service and shared accounts are on the list, since they are often missed.

Approval records for each grant

Every grant of privileged rights needs a record showing who requested it, who approved it, the business reason, the scope and the start date. Approval should come from someone other than the requester and, where practical, from someone other than the administrator who applies the change. Keep the approval in the ticketing or identity workflow system with a link to the account that was created, so an assessor can trace a live admin account back to a signed-off request.

Access review sign-offs

Periodic reviews of privileged rights should be run as recorded campaigns, not as ad hoc checks. Midpoint's access certification model, for example, has designated reviewers decide within a set timeframe whether to keep, change or revoke each access item. Retain each sign-off with the reviewer's name, the date, the decision and the reason for any change. Confirm that the review interval is written in your policy and that you can show the previous cycle's results, since the regulation requires documented review results.

Revocation and change records

Reviews only prove control if removed access stays removed. Record each revocation with the date it was actioned, the person who actioned it and the ticket that triggered it, including leavers, role changes and reviews that ended in removal. Re-run the privileged group export after each revocation to confirm the account is gone from the group. Organizational changes, such as a reorganization or an outsourced administrator leaving, should trigger an out-of-cycle review, and that trigger should be logged too.

Audit trails of privileged activity

Assessors expect logs of privileged access and of actions taken by administrative accounts, where appropriate. Confirm that these logs are written to a location the administrators cannot edit and that they cover administrative consoles as well as the application layer. In Nextcloud, for instance, the admin_audit app writes extra event information to audit.log, or to a path set with logfile_audit, so confirm the path is set and the file is shipped off the host. Sample a few admin actions and trace each back to a named account and an approved grant.

Keeping privileged access reviews current between audits

Periodic reviews of privileged access fail in predictable ways, and point 11.3.3 expects the entity to prevent those failures, not just to hold a review once a year. Access accumulates when an administrator moves between teams and keeps the admin rights from the previous role. Leavers keep privileged accounts because nobody connects the HR offboarding record to the directory. Reviewers approve whatever list lands in their inbox because they cannot tell what each entitlement is for. The first decision for the entity is therefore the review interval itself, which must come from its own risk assessment. Confirm the expected frequency and the level of evidence with ENISA's June 2025 guidance and with the national competent authority, since neither the Regulation nor this page sets a fixed number.

A review campaign addresses these failures when every privileged role has a named accountable reviewer and a fixed decision window. In midPoint, access certification campaigns route each access item, such as a role assignment to an administrative group, to a designated reviewer who must keep, change or revoke it within the set timeframe. The campaign record then shows who decided what and when, which is the documented result that 11.3.3 asks for. Segregation of duties checks belong in the same campaign: a reviewer should not be the only approver of an account that can also change its own privileges, and conflicting admin roles should be flagged before the decision is recorded. Illustrative example: a platform engineer who moved to the security team keeps database administration rights, and the campaign flags the conflict for revocation rather than leaving it to a manual check.

Which self-hosted open-source tools support privileged account evidence

Point 11.3 is tested by looking at who holds privileged access, how they authenticate, and whether their rights are reviewed and logged. The four tools below each produce one part of that evidence inside the client's own environment, so each card names the control it supports and the record it can produce.

authentik for second-factor checks

authentik is an identity provider released under the MIT license. Its authenticator validation stage checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. For point 11.3.2, check which factors are permitted for administrator flows, whether SMS and email codes are excluded, and how recovery codes are issued and stored. Test the flow with a real administrator account before you rely on the login logs as evidence.

FreeIPA for token enrollment

FreeIPA is licensed under GPL-3.0-or-later and supports two-factor authentication with HOTP (RFC 4226) and TOTP (RFC 6238) tokens. Software tokens can be enrolled by QR code, and hardware tokens such as YubiKeys are supported. Its RADIUS proxy for OTP checks can help during migration from an older server. Enrollment records and per-account token assignments give an assessor a list of who holds strong authentication for privileged accounts, which must match the access review records.

midPoint for access reviews

midPoint is licensed under EUPL-1.2 or later and runs access certification campaigns. Designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. Point 11.3.3 requires planned reviews, adjustments after organizational changes and documented results, so a campaign record showing each reviewer decision and each revocation is the core evidence. Confirm that the campaign scope covers all privileged roles and that completed campaigns are exported and retained.

Nextcloud admin audit logging

Nextcloud is licensed under AGPL-3.0-only. Its admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. Point 3.2.3(e) expects logs of privileged access and of activities performed by administrative accounts, so confirm that the app is enabled, that administrative actions appear in the log, and that the file is protected and forwarded to central storage. Test by performing a known admin action and checking that it appears with the account name.

What meeting privileged account controls costs

This table compares the main cost components of meeting point 11.3 for privileged and administration accounts, showing who is paid for each, whether it is one-time or recurring, what drives it up and how to keep it down. Use it to structure a quote request, because most of the effort scales with the number of admin accounts, systems and vendors in scope.

Cost component	One-time or recurring	What drives it	How to reduce it
Identity and access tooling	One-time setup, then recurring hosting and support	The named open-source tools (authentik, FreeIPA, midPoint) carry no license fee, but hosting, infrastructure and vendor or partner support do	Reuse existing directory and MFA infrastructure where it meets the requirements, and confirm support terms before selecting a platform
Engineering time to separate admin identities and route admin access	One-time, with occasional change work	Number of admin accounts, admin systems and applications that must be routed through admin-only connections	Start with the most sensitive systems, and standardize one dedicated admin account pattern for reuse
Inventory and policy drafting	One-time, then periodic updates	Count of privileged roles, systems and third parties, and how much of the access model is undocumented today	Build the list of privileged users and their systems from existing directory exports before drafting policy text
Recurring access review effort	Recurring at the review interval	Number of privileged users, role assignments and the review frequency the organization sets for itself	Use certification campaigns with named reviewers, so reviews are scheduled, tracked and recorded in one place
Evidence upkeep and log retention	Recurring	Volume of privileged activity logged, retention period chosen by the organization and the effort to sample logs on request	Centralize admin audit logs, protect them from alteration and define retention in the policy
External testing of admin paths	Recurring or per engagement	Scope of admin interfaces, remote access paths and third-party connections included in testing	Limit the first test to agreed admin paths and retest only after material changes
Auditor or assessor sampling	Recurring at each assessment cycle	Number of accounts, reviews and log samples the assessor selects, and whether records are complete on request	Keep approval, review and revocation records in a consistent format so sampling does not require manual reconstruction

Who owns privileged account controls, who builds them and who checks them

Your organization owns the privileged account policy under the access control policy required by point 11.3. Your team decides who may hold an administration account, approves each privileged grant, runs the access reviews and signs off the outcome. These decisions carry accountability under Article 20 and cannot be delegated to an outside party, so they should stay in-house even when a partner handles the technical work.

Policy ownership: Maintain the written policy covering strong authentication, dedicated admin accounts, individualized privileges and admin-only connections.
Grant approval: Record who requested each privileged right, who approved it, the business reason and the systems covered.
Access reviews: Set the review interval, run the reviews at that interval and act on the results, including revocations and changes after reorganizations.
Documented decisions: Keep the review records and the sign-off by a named accountable manager.
Operational ownership: Assign a named person to receive alerts from privileged activity logs and to act on them.

Before engaging anyone, confirm that each of these roles has a named internal owner who can explain the decisions to a supervisor.

Questions buyers ask about privileged account requirements

How long does it take to put privileged account controls in place?

The duration depends mainly on how many administration accounts exist, how many systems they reach, and how far current practice is from dedicated, individually assigned admin accounts. No fixed timeline applies across organizations, so ask any partner for a duration tied to a written scope that names the systems, account counts and review cycles covered. Discovery usually takes the longest, because shared administrator logins and standing admin rights tend to surface only when every system is listed. Ask for the phases, the client tasks in each phase, and the point at which an independent review can begin.

Can our own team implement point 11.3 without outside help?

Yes, an in-house team can do the work if it has identity and access management skills, network skills to confine admin connections to administration systems, and time set aside for recurring access reviews. The policy, the account model and the review cycle are internal decisions either way. Teams often struggle less with the technology than with the ongoing discipline: removing standing privileges, documenting approvals and completing reviews on schedule. An outside partner is most useful when those skills or hours are missing, or when a supervisor will examine the evidence soon.

What does our organization need to provide for a privileged access project?

The organization needs to supply four things before work starts:

An asset inventory listing the systems, applications and directories that hold or grant administrative rights
Named owners for each system and for each privileged role
Access to the existing administration systems, identity sources and logs
A sign-off authority, usually a senior manager, who approves the access policy and the review results

Without a named approver, the access rights that the review process produces have no accountable decision-maker, and point 11.3.3 cannot be met in practice.

Can a consultant or implementation partner issue a NIS2 privileged access certificate?

No. NIS2 creates no certificate of compliance, and an implementation partner cannot issue audit reports, attestations or certifications. Compliance is overseen by national competent authorities through inspections, security audits, information requests and fines. Where an independent assessment is requested, an independent auditor or certification body issues the report. A partner prepares the systems, the account model, the review records and the evidence, while the organization remains responsible for its controls.

How does point 11.3 differ from point 11.4?

Point 11.3 governs the people and accounts: who may hold privileged or administration accounts, how those accounts are authenticated, how privileges are individualized and restricted, and how access rights are reviewed. Point 11.4 governs the administration systems themselves: they must be used only for administration, logically separated from other application software, and protected by authentication and encryption. In practice, 11.3 asks whether the right people hold the right admin rights, while 11.4 asks whether the tools used to exercise those rights are isolated and protected. Both points are usually tested together, so the account policy and the admin system design should be documented side by side.

Do open-source tools satisfy the privileged account requirement by themselves?

No. Open-source tools can enforce parts of the requirement and produce evidence, but they cannot make an organization compliant on their own. Authentication platforms can require multi-factor checks, directory services can hold individual admin roles, certification tools can record review decisions, and logging tools can capture admin activity. The organization still has to write the access control policy, decide who approves privileged access, run the reviews at planned intervals, and document the results. A supervisor will ask for those decisions and records, which no tool can generate without the organization's input.

What drives the cost of privileged access work up?

Cost follows the size and complexity of the privileged estate. The main drivers are the number of administration accounts and shared logins, the number of systems and directories involved, the number of legacy applications that cannot use modern authentication, the number of approvers and review cycles, and whether the organization must integrate with existing identity providers or a RADIUS server during migration. One-time costs cover discovery, design, configuration and initial access clean-up. Recurring costs cover review cycles, account lifecycle work and log review. Ask any quote to separate the one-time and recurring items and to state which party performs each task.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so privileged account controls and their evidence are set up where the accounts actually live. We scope the work in writing first, then build and document the controls that IR 2024/2690 11.3 Privileged accounts and system administration accounts asks for, and prepare the evidence for your independent assessor.

How we scope

We inventory which privileged and administration accounts exist across your directories, cloud accounts and self-hosted platforms before any change.
The written scope names the administration systems, the authentication methods and the review cycle that will be covered by the work.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.

How we build

We configure strong authentication, including second factors, for privileged accounts on the identity platforms in your environment.
We set up dedicated admin accounts, restricted individual privileges and admin-only connections, then test that they behave as the written policy describes.
We enable audit logging for privileged activity and confirm that logs are retained where your policy says they should be.

How we hand over

You receive the policy text, the privileged user list with the systems each user can reach, and the configuration records behind them.
We document approval records, access review cycles and revocation records in a form your assessor can sample and trace.
Your team owns the controls and the policy decisions; we prepare the evidence, and only an independent auditor or certification body issues reports or certificates.

How we support

We walk your control owners through the evidence set so they can answer assessor questions about privileged access with confidence.
Ongoing support, upgrades and continuous security testing of the identity and admin stack are available as retainers.
Before any external assessment, confirm with your assessor which evidence formats and sampling periods they expect for the access review records.

IR 2024/2690 11.3 Privileged accounts and system administration accounts