What is least privilege?
Least privilege, also called the principle of least privilege (PoLP) or minimum privilege, limits every permission to what a task actually requires. Germany's Federal Office for Information Security (BSI) makes it a basic requirement. Under ORP.4.A2 in module ORP.4 Identity and Access Management (Edition 2023, in German), user IDs and permissions may be granted only on actual need and where the task requires them.
A compromised account therefore reaches exactly as far as the rights granted to it beforehand. How rights are granted, reviewed and withdrawn is set out in the access control concept.
Least privilege and need-to-know answer two different questions
ORP.4.A2 names both principles side by side, but they limit different things:
| Principle | Limits | Example |
|---|---|---|
| Need-to-know | which information someone may know | Sales sees the customer data for its own region. |
| Least privilege | what someone may do with it | Sales may read that data but not export or delete it. |
Only together do they make a workable access model. Implement need-to-know alone and you get users with full modification rights over a small slice of data. The counterpart is explained in the glossary entry on the need-to-know principle.
Where is least privilege anchored?
The BSI Act (BSIG), DORA, IT-Grundschutz and ISO/IEC 27001 all anchor the principle in substance, each in its own words.
| Framework | Provision | What it says |
|---|---|---|
| BSIG (German NIS2 transposition) | § 30(2), second sentence, no. 9 BSIG | concepts for personnel security, access control and the management of ICT systems, products and processes |
| DORA | Article 9(4)(c) of Regulation (EU) 2022/2554 | policies that “limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only”, with sound administration of access rights |
| DORA, regulatory technical standards | Article 21(a) of Delegated Regulation (EU) 2024/1774 | assignment of access rights “based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access” |
| BSI IT-Grundschutz | ORP.4.A2 (basic requirement) | permissions granted on actual need; rights no longer needed removed when personnel change |
| ISO/IEC 27001:2022 | Annex A 5.15 to 5.18 and 8.2, according to the BSI mapping table for ORP.4 | rules for access, granting and withdrawing rights, administrative privileges |
ORP.4.A2 and Article 21(a) of Delegated Regulation (EU) 2024/1774 name the principle explicitly; Article 9 DORA adds the sound administration of access rights, meaning the process rather than the state alone. The BSIG requires a concept for access control and leaves its content to the entity.
Privilege creep: rights grow faster than they are withdrawn
Privilege creep is the growing stock of rights on an account when rights are granted faster than they are withdrawn. Four mechanisms drive it:
- Rights granted for a project remain after it ends.
- Rights are extended during incidents to help quickly and are not taken back afterwards.
- Roles are copied from a colleague as a template, special rights included.
- Standard installations can arrive with far-reaching defaults and predefined user IDs; ORP.4.A23 requires predefined IDs to be changed.
ORP.4.A2 sets the counter-process: when personnel change, user IDs and permissions that are no longer needed must be removed.
How do you implement least privilege step by step?
Withdrawing local administrator rights and capping global administrators shrink the reach of a compromised account with few changes.
| Area | Target state | First step |
|---|---|---|
| Workstation | no local administrator rights in the everyday account | record, time-limit and justify the exceptions |
| Business applications | roles derived from tasks, read and write rights separated | derive roles from tasks with the business functions rather than carrying them forward |
| Administration | separate administration accounts, rights per system rather than global | count and cap the global administrators |
| Services and interfaces | one technical account per service, minimal scope, a named owner | inventory what exists, break up shared accounts |
| Emergency access | requested and documented, time-limited, reviewed afterwards | define the procedure before it is needed |
Recutting business roles is the actual project work.
Time-limited rights instead of standing rights
Least privilege also applies to time: rights are granted on demand, for a defined period and after approval, and expire automatically. For administrative work this reduces the number of permanently privileged accounts without leaving administrators unable to act. It needs an approval procedure fast enough to use; otherwise workarounds appear. Technically, privileged access management implements it.
Plan for three limits:
- Availability. Rights that are too tight, with no working exception procedure, lead to credentials being shared.
- Effort. Fine-grained rights have to be maintained; the protection requirements of the data set the level of detail, not what is technically possible.
- Legacy systems. Where an application knows only a few privilege levels, upstream controls limit access: network segmentation, session logging, dual control.
How do auditors test least privilege?
Three samples show whether the principle holds:
- the number of accounts with far-reaching administrative rights and their justification,
- one person's rights compared with the tasks in their job description,
- when a particular entitlement was last used.
The third sample can only be answered with evaluated logs. ORP.4.A3 sets the yardstick for the second: it requires a check of whether the granted rights still match the security requirements and the users' current tasks.
How Rizzqo makes the principle checkable per system
In Rizzqo, ISO/IEC 27002 is held as a requirement catalogue, and the access control requirement appears on every asset whose category it concerns. The system's owner answers it there with a reason and evidence and finalises it with a name and timestamp.
A system inherits the confidentiality rating of the primary assets it supports, across several levels of support. The administrator of an intermediate system therefore sees that a process with a high confidentiality requirement depends on their entitlement decisions. They judge whether the rights are appropriate against that yardstick.