control
privileged access
Control of the accounts that can change systems, read everything or switch protections off. The rules ask for strong sign-in, separate admin accounts and regular review of who holds the rights.
- what it protects
- the few accounts that can change systems, read everything or switch protections off
- who owns it
- head of IT
- start with
- export the list of administrator roles and name an owner for each
what it is
Privileged access means the accounts that can change systems, read everything or switch protections off: domain and server administrators, cloud console owners, database administrators and anyone who runs the identity provider. They are few, and an attacker who takes one does not need a second.
The rules ask three plain things of them. Sign in strongly, use a separate account for administration, and review at planned intervals who holds the rights. NIS2 and DORA state the principle; the implementing regulation for listed digital providers spells out the steps, and it is a fair reference for everyone else.
Start with the list. Count the administrator roles across the identity provider and your five most important systems, give each name an owner and a reason, and remove the rest. Tools that vault passwords, grant rights for a limited time or record sessions all sit in this area. Whether you need one depends on how long the list is after that clean-up.
basis NIS2 Art. 21(2)(i); IR 2024/2690 Annex 11.3.2, 11.3.3 as a reference. The tool categories are practice.
how an administrator role is used and taken back
- 1everyday accountmail and browsing, with no administrator rights
- 2ask for the rolefor a task and a time window, with a named approver
- 3strong sign-ina separate admin account behind a second factor
- 4act and recordthe session or the change log shows what was done
- 5rights endtaken back when the task ends or the window closes
the list of role holders is exported and reviewed on a set rhythm
basis working practice. No legal text sets this.
an example
Picture a company of 200 people with administrator accounts spread across the identity provider, the servers and the cloud console.
Administrators read mail and browse with the same account that holds their rights. One database password is shared by several people. A contractor from a past project still has a role, and nobody can say why.
Each administrator has a separate admin account that is used for administration only, behind a second factor. The list of role holders has an owner and a reason beside every name. Rights are given for a task and taken back when it ends, and the shared password sits in a vault with each use recorded.
An illustration. It is not a real case.
what it has to do for each rule
| rule | where | what the text asks | what the control has to do |
|---|---|---|---|
| NIS2 | NIS2 Art. 21(2)(i) | Human resources security, access control policies and asset management. | Keep a list of every account with administrator rights, with a named owner for each, and approve the policy that governs them. |
| IR 2024/2690 | IR 2024/2690 Annex 11.3.2(a) | Listed digital providers: strong authentication such as MFA for privileged accounts. | Enforce a second factor on every administrator role and be able to report who is registered. |
| IR 2024/2690 | IR 2024/2690 Annex 11.3.2(b) | Listed digital providers: accounts used for system administration only. | Give each administrator a separate admin account that is not used for mail or browsing. |
| IR 2024/2690 | IR 2024/2690 Annex 11.3.3 | Listed digital providers: review privileged rights at planned intervals and document the result. | Choose an interval, review the admin list against it and keep the signed record. |
| DORA | DORA Art. 9(4)(c) | Limit physical and logical access to what approved functions need. | Grant the narrowest role that does the job and remove rights when the task ends. |
| GDPR | GDPR Art. 32(1)(b) | Ongoing confidentiality of processing systems, sized to risk. | Treat administrators of systems that hold personal data as the highest-risk accounts. |
basis NIS2 Art. 21(2)(i); IR 2024/2690 Annex 11.3.2(a), 11.3.2(b), 11.3.3 as a reference; DORA Art. 9(4)(c); GDPR Art. 32(1)(b). What the control has to do is practice.
what to look for when you choose
- Can it keep a separate admin account for each person and show which everyday account it belongs to?
- Can rights be given for a task and a time window, then taken back on their own?
- Does it force a second factor, ideally one that cannot be tricked by a fake page, before an admin role is used?
- Where shared or built-in admin accounts cannot be avoided, can the password be held in a vault and changed after each use?
- Does it record what an administrator did during a session, and who can read that record?
- Can you pull one report of every admin role holder across your main systems?
- Does it cover cloud consoles and the identity provider itself, or only servers?
- What is the documented way in when the tool is down?
basis working practice. No legal text sets this.
three levels, from first step to strong
Each level adds something visible. Stop where the risk you accepted allows.
- start
List every administrator role in the identity provider and your five most important systems. Give each name an owner and a reason, and remove the rest.
- solid
Give each administrator a separate admin account with a second factor, review the list on a set rhythm and keep the signed result.
- strong
Grant rights for a task and a time window, hold unavoidable shared passwords in a vault, record administrator sessions and test the way in when the tooling is down.
basis working practice. No legal text sets this.
where it goes wrong
admin rights on the everyday account
An administrator who reads mail and browses with the same account hands a phishing message the keys. Keep the two apart.
the list nobody can explain
Rights added for a project and never removed pile up. If you cannot say why a name is on the list, it should not be.
shared admin passwords
A password several people know cannot show who did what. Where one is unavoidable, hold it in a vault and record each use.
built-in and service accounts forgotten
A review of people misses the accounts that belong to no one, such as service accounts and vendor access. They keep their rights for years unless someone owns them.
basis working practice. No legal text sets this.
the proof it leaves
| what you can show | who owns it | refresh |
|---|---|---|
| dated export of administrator role holders across main systems | head of IT | quarterly |
| admin list compared with everyday accounts, showing the two are separate | head of IT | quarterly |
| second factor registration report for admin roles | head of IT | quarterly |
| signed review of privileged rights with removals | head of IT | quarterly (your choice) |
| sample of the log of changes to admin roles | head of IT | yearly |
basis practice. The rhythms are your choice; the implementing regulation says planned intervals.
check it yourself
- Directive (EU) 2022/2555 (NIS2) (EUR-Lex)
- Commission Implementing Regulation (EU) 2024/2690 (EUR-Lex)
- Regulation (EU) 2022/2554 (DORA) (EUR-Lex)
- Regulation (EU) 2016/679 (GDPR) (EUR-Lex)
your next step
Export the list of administrator roles today and mark every name you cannot explain.