control
single sign-on and directory
The one place where identities live and where the decision to let someone in is made. It makes joiners, leavers and MFA enforceable in one spot, and it becomes the system you cannot afford to lose.
- what it protects
- every sign-in to every connected application, from one place
- who owns it
- head of IT
- start with
- list the applications that still keep their own passwords and connect the most important first
what it is
A directory is the list of identities: every person, their groups and the rights that follow. Single sign-on is the service that decides, once, whether someone may enter, and passes that decision to the applications connected to it. Together they are the one place where joiners are created, leavers are switched off and the second factor is enforced.
That is the gain. One disabled account stops working across every connected application, and one setting covers everyone. The cost is concentration. If the service is down, so is everything behind it, and an attacker who takes it holds the keys to all of it.
So treat it as the most protected system you run. Limit who administers it, keep a tested break-glass route in, back up its configuration and test recovery. No rule names the product. They ask for the results: one person per identity, strong sign-in, a log of changes and continuity.
basis NIS2 Art. 21(2)(i), 21(2)(j), 21(2)(c); IR 2024/2690 Annex 11.5.2(b) as a reference. What the control has to do is practice.
where an identity comes from and where it is trusted
- joiner, mover and leaver events
- identities and groups
- the sign-in decision
- sign-in and change logs
basis working practice. No legal text sets this.
an example
Picture a company of 120 people that keeps accounts in its mail system, its finance tool and two business apps, each with its own password.
A leaver is disabled in the mail system and stays enabled in three applications. The second factor covers mail and nothing else. The one emergency account was set up years ago, and nobody knows whether its password still works.
Every person exists once in the directory, fed from the HR system, and the main applications trust one sign-in service that enforces the second factor. Disabling an account stops it everywhere. The emergency account is tested on a date, and its use sounds an alarm.
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. | Hold every employee identity in one directory, so a leaver is disabled once and everywhere that trusts it. |
| NIS2 | NIS2 Art. 21(2)(j) | Multi-factor or continuous authentication, where appropriate. | Enforce the second factor at the sign-in service, so each connected application inherits it. |
| NIS2 | NIS2 Art. 21(2)(c) | Business continuity, such as backup management and disaster recovery, and crisis management. | Plan for the identity service being down: backups, a second administrator path and a tested way in. |
| IR 2024/2690 | IR 2024/2690 Annex 11.5.2(b) | Listed digital providers: link the identity of users to a single person. | Make sure every account maps to one named person, matched to the HR list. |
| IR 2024/2690 | IR 2024/2690 Annex 11.2.2(f) | Listed digital providers: log the management of access rights. | Record who changed which rights and keep the log for the period you decide. |
| DORA | DORA Art. 9(4)(d) | Policies and protocols for strong authentication. | Set the sign-in rules once, in the directory, and show they are enforced. |
| GDPR | GDPR Art. 32(1)(b) | Ongoing confidentiality of processing systems, sized to risk. | Protect the directory as the system that guards access to everything holding personal data. |
basis NIS2 Art. 21(2)(i), 21(2)(j), 21(2)(c); IR 2024/2690 Annex 11.5.2(b), 11.2.2(f) as a reference; DORA Art. 9(4)(d); GDPR Art. 32(1)(b). What the control has to do is practice.
what to look for when you choose
- Which of your applications can connect to it, and which still keep their own passwords?
- Does it enforce the second factor and the sign-in conditions you set, such as device, location or risk, for every connected application?
- Can you disable one account and have every connected application stop accepting it, and how fast?
- Is it fed from the HR system, or does someone create accounts by hand?
- How is the service made resilient, and can you reach your own admin console if it fails?
- Is there a break-glass account kept outside normal sign-in, with its use alarmed and tested?
- Can you export the user list, group memberships and the log of changes?
- Can you leave: is the data exportable in a standard form?
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 the applications that keep their own passwords, connect the most important to the sign-in service and match the user list to HR's.
- solid
Feed the directory from the HR system, enforce the second factor and sign-in conditions centrally, retire any second list of accounts and keep a copy of the configuration.
- strong
Limit who administers the directory, alarm and test the break-glass account on a schedule, test recovery of the directory once a year and check that the data can be exported in a standard form.
basis working practice. No legal text sets this.
where it goes wrong
the single point of failure with no plan
If the sign-in service is down, everything behind it is down. Write down how you get in, test it, and keep a copy of the configuration.
the break-glass account nobody tested
An emergency account with a lost password or an expired factor fails on the day you need it. Test it on a schedule and alarm every use.
two directories that disagree
A second source of accounts, left from a merger or a pilot, keeps leavers enabled. Find the second list and retire it.
applications left outside
A system with its own local passwords sits outside every rule you enforce centrally. List them and decide on each.
basis working practice. No legal text sets this.
the proof it leaves
| what you can show | who owns it | refresh |
|---|---|---|
| list of applications connected to the sign-in service and those that are not | head of IT | quarterly |
| user export matched to the HR list | head of IT | quarterly |
| enforcement settings for the second factor and sign-in conditions | head of IT | quarterly |
| break-glass procedure with the date of the last test | head of IT | yearly |
| recovery test of the directory | head of IT | yearly |
basis practice. The rhythms are your choice.
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
List the applications that still keep their own passwords and decide which to connect first.