Privileged Access Standard
Specifies requirements for privileged accounts, authentication strength, session controls, elevation and logging.
Available soon
- Format
- Word
- Size
- 77 KB
- Length
- 28 pages
- Version
- 2.0
- Updated
What's inside
- Purpose
- Scope
- Roles and responsibilities
- Principles
- Requirements
- Administrative tiers
- Accounts and credentials
- Phishing-resistant sign-in
- Just-in-time access and approval
- Session review cadence
- Emergency access
- Service accounts
- Leavers, movers and resets
- Suppliers
- Built-in controls
- Control review
- Measures and reporting
- Exceptions
- Records to keep
- Worked example: the first two weeks
- Related documents
- Adapting this template
- Framework references
- Definitions
What changed
- 2.0
Rewritten to the depth of the other CISO Times packs: principles come before the rules, and every rule now names its evidence and the control test that checks it; the tiers come with what an account may do on each, the account types with worked rotation dates, sign-in with the rollout as it stood, approval with the durations used, and emergency access with a worked use; service accounts, leavers, suppliers, the control review, the measures and exceptions are explained; and a worked example of the first two weeks is added.
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This standard sets how [[Organisation Name]] controls privileged access: the rights that let an account change a system's configuration, security, users or permissions, read or change data beyond one person's job, or turn off a control. It says which accounts may hold those rights, how people sign in to them, for how long the rights are active, who approves them, where every use is recorded and who looks at the record.
Privileged accounts are what an attacker looks for first, because one of them is worth more than every ordinary account together. The rules below make a privileged credential hard to steal, short-lived when it is in use, and useless on the systems where it is most likely to be captured. They are written for an organisation without a privileged access management platform: every control can be built with tools it already has.
The Privileged Access Request, Elevation & Revocation Procedure runs the rules day to day. The Privileged & Service Account Inventory lists every privileged account; the Administrative Tier Model & Separation Matrix sets the tiers; the Break-Glass Account Control Checklist, the Privileged Access Control Review Workbook and the Privileged Session Review Record check them; and the Privileged Access Metrics Dashboard reports the measures. The general rules for joiners, movers and leavers are the Access Control Policy's (Joiner-Mover-Leaver & Access Provisioning pack); this standard adds their privileged side.
Guidance — delete before approval
This is a Standard-tier document in the Security Policy Management pack's hierarchy: approved by the Head of Information Security (the document owner is consulted), and reviewed at least every 12 months. It sits under the Access Control Policy, which defers privileged access to it.
Keep the rule IDs PA-01 to PA-18. Every P14 document, workbook and Guidance answer cites them.
Scope
This standard applies to every account that holds privileged access, standing or when elevated, on any system the organisation runs or has run for it: the six types in "Accounts and credentials", from named administrator accounts to break-glass accounts. It covers on-premises and cloud systems, the administrator roles inside business applications, and every supplier whose staff administer our systems. Privileged access means rights that let an account change a system's configuration, security settings, users or permissions, read or change data beyond one person's job, or turn off a control. Administrator rights are privileged access; so are an application's administrator roles.
Not covered here: the general joiner, mover and leaver process and the general service desk reset rule (Access Control Policy, Joiner-Mover-Leaver & Access Provisioning pack); the periodic review of access (Access Review Methodology, User Access Review pack), which this standard relies on for privileged access every 3 months; and the exception process (Security Exception & Waiver Standard, Security Exception, Waiver & Segregation of Duties pack).
Guidance — delete before approval
List every system in scope by tier in the tier model before approving the standard. A system without a tier has no separation rule, and that is where tier breaches happen.
Roles and responsibilities
Role | Responsibilities under this standard |
|---|---|
Head of IT [[e.g. Head of IT]] | Owns the standard and the inventory, approves Tier 0 elevation, and is the default owner of break-glass accounts. |
Head of Information Security [[e.g. Head of Information Security or CISO]] | Approves the standard, approves the Head of IT's own elevation, reviews every break-glass use and receives the metrics. |
Session reviewer [[e.g. Information Security Manager]] | Reviews privileged sessions and runs the control review. Holds no administrator rights in the tier reviewed. |
IT Operations Manager [[e.g. IT Operations Manager]] | Runs day-to-day administration, approves Tier 2 rights and owns service accounts that no business owner claims. |
System owner [[the manager accountable for the system]] | Approves Tier 1 elevation on their system and reviews its privileged access every quarter (P07). |
Administrator [[each person who holds an administrator account]] | Requests elevation, uses it only for the task approved, and signs in only from an administration device of the tier. |
Service desk [[internal service desk, or the managed IT provider's]] | Resets passwords and second factors, with the stricter checks of PA-17 for any privileged account. |
Supplier engineer [[the supplier's named engineer]] | Uses a named account for the agreed window only, under the supplier contract's access clause (P06 CL-09). |
A Critical exception to this standard is approved by the board or its equivalent: the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management (PA-18).
Duties kept apart
The conflicts of the P02 Segregation of Duties Conflict Matrix that touch privileged access, and how this standard keeps each apart:
Conflict | The two duties | Rating | How this standard applies it |
|---|---|---|---|
SOD-IT-01 | Create or change user accounts and permissions; and approve access requests | High | The person who approves an elevation or a new administrator account is never the person who receives it, and never the one who grants it by hand (PA-07). |
SOD-IT-02 | Create or change user accounts and permissions; and review access rights (periodic access review) | High | Privileged access is reviewed by the system owner and information security, never by the administrators who hold it (PA-16). |
SOD-IT-03 | Administer a system with privileged access; and review a system's audit logs | High | Privileged activity logs go to a store administrators cannot change, and sessions are reviewed by someone with no administrator rights in that tier (PA-08, PA-09). |
SOD-SO-01 | Grant privileged access; and review access rights (periodic access review) | High | Whoever can grant privileged access does not review it; elevation expires by itself (PA-06, PA-16). |
SOD-SO-04 | Investigate security incidents; and administer a system with privileged access | Medium | When an incident involves an administrator's own systems, their activity is preserved and reviewed by someone else before they investigate (PA-09). |
SOD-FI-03 | Administer the finance system's users and roles; and post transactions in the finance system | High | An application administrator role in the finance system is not held by anyone who posts transactions in it (PA-07). |
Guidance — delete before approval
In a small IT team the Head of IT may be the only Tier 0 administrator. Their own elevations are then approved by the Head of Information Security (AP-1), and their sessions reviewed by someone with no Tier 0 rights. Where nobody qualifies, use an outside reviewer and record the arrangement as an exception.
Principles
The requirements put these principles into practice. Where a case is not covered by a requirement, decide it by the principle.
Principle | Carried by |
|---|---|
Separate the power from the person's everyday work. Administration happens from a separate account, on a separate device, never from the account that reads email. | PA-02, PA-03, PA-04 |
Hold power only while using it. Rights in the tiers that matter most are switched on for one task and switch off by themselves. | PA-06 |
Nobody grants power to themselves, and nobody checks their own use of it. | PA-07, PA-09, PA-16 |
Keep the most powerful credentials where a phished password cannot reach them: behind a key bound to the real site, in a vault, or sealed in a safe. | PA-05, PA-10, PA-12 |
Never let a credential from a higher tier touch a lower-tier system, where it could be captured. | PA-13 |
Know every privileged account, who owns it and when its credential last changed. An account nobody owns is the one an attacker uses. | PA-01, PA-11 |
Write everything down where the administrators cannot change it, and look at it. | PA-08, PA-09 |
Requirements
The requirements keep the rule IDs PA-01 to PA-18 that every document in the Privileged Access Management pack cites. Values in [[brackets]] are the pack's defaults; set your own before approval. Each requirement names the evidence an auditor looks at, and the test in the Privileged Access Control Review Workbook that checks it.
Inventory and ownership
PA-01 Every privileged account, human and non-human, must be in the inventory with a named owner, its tier, its purpose, where its credential is kept and when it was last changed. An account found that is not in the inventory is disabled unless an owner claims it within [[5]] working days. For a service account, assign an interim owner within that window to control its use while dependencies are checked under PA-11; the 30-day limit is not permission to leave it uncontrolled.
Evidence: The inventory, with owner, tier, purpose, credential location and last change for every account; the export of privileged accounts from each system, matched to it. Control test CT-01.
Separate accounts and devices
PA-02 Administration must be done only from a separate administrator account, named for one person and one tier. Administrator accounts are never shared, except the built-in and break-glass accounts held in the vault.
Evidence: For each administrator, a named administrator account per tier; shared administrator accounts limited to the built-in and break-glass accounts in the vault. Control test CT-02.
PA-03 A daily account must hold no administrator rights anywhere, including local administrator rights on the person's own device. Support uses the local administrator password solution instead.
Evidence: A report of every local and directory administrator group showing no daily account; the local administrator password solution's access log for support. Control test CT-03.
PA-04 An administrator account must have no mailbox and must never be used for email or web browsing. It signs in only from an administration device of its tier.
Evidence: Administrator accounts with no mailbox or office licence; sign-in logs showing administrator sign-ins only from administration devices.
Sign-in
PA-05 Every privileged sign-in must use a phishing-resistant method: a security key, a passkey on a managed device, or a certificate. Where a system can use neither the organisation's single sign-on nor such a method, it uses the strongest method it offers, recorded in the inventory with the date it will move.
Evidence: The sign-in policy for administrator accounts, and the methods used in the last 30 days of administrator sign-ins; each recorded exception with its date to move. Control test CT-04.
Just-in-time rights and approval
PA-06 Privileged rights in Tier 0 and Tier 1 must be just-in-time: eligible, activated for one task and ended after no more than [[4]] hours in Tier 0 and [[8]] hours in Tier 1. Standing rights are allowed only for break-glass and service accounts, Tier 2 support on separate Tier 2 accounts, read-only monitoring, and application roles the application cannot assign for a time, each recorded in the inventory.
Evidence: Eligible assignments in Tier 0 and Tier 1 with their maximum durations; the elevations of the last 30 days with start and end; standing rights each recorded in the inventory. Control test CT-05.
PA-07 Every elevation and every new privileged account must be approved as the approvals table sets, by someone other than the person who will use it. The segregation-of-duties conflicts of the P02 matrix apply.
Evidence: For a sample of elevations and new privileged accounts, the approval by someone other than the user, given before the start. Control test CT-06.
Logging and review
PA-08 Every privileged sign-in, elevation, change to a privileged group or role, and vault opening must be logged to a store administrators cannot change or delete, and kept for at least [[12]] months.
Evidence: Privileged events arriving in the central log store; the store's access rights, showing administrators cannot change or delete; the retention setting. Control test CT-07.
PA-09 Privileged activity must be reviewed at the cadence the session review table sets, by someone with no administrator rights in that tier. Anything unexplained is followed up and recorded.
Evidence: The session review records, each on time, by a reviewer without rights in the tier, with every anomaly followed up. Control test CT-08.
Shared, service and emergency accounts
PA-10 Shared, service and break-glass credentials must be kept in the vault or managed by the platform, and changed as the rotation table sets, after every use where it says so, and at once on suspicion of compromise.
Evidence: The vault's list of shared, service and break-glass credentials with their last change; the vault's access log. Control test CT-09.
PA-11 Every service account must have a named owner, do one job with the least rights it needs, and be denied interactive logon. A service account with no owner found within [[30]] days is disabled, and deleted [[90]] days after that if nothing breaks.
Evidence: For each service account, its owner, its rights and the policy denying interactive logon; any unowned account found, with the date it was disabled. Control test CT-10.
PA-12 There must be [[2]] break-glass accounts for each cloud identity tenant and [[1]] for each on-premises directory, sealed in the safe, alerting on every sign-in and tested every [[3]] months. They are used only when the normal route is unavailable, and every use is declared, reviewed and followed by a credential change within [[1]] working day.
Evidence: The break-glass checklist for each account: count, seal, alert, test date, and the record of every use with its review and credential change. Control test CT-11.
Tiers
PA-13 Every system must have a tier, and administrator accounts must follow the separation rules. An administrator account used outside its tier, or for email or browsing, is treated as a possible exposure of its credential.
Evidence: The tier of every system; the policies denying higher-tier sign-in on lower-tier systems; sign-in logs showing no account outside its tier. Control test CT-12.
People and suppliers
PA-14 Privileged access must be removed on the day a person leaves or moves, or at once for an urgent departure. Shared, service and break-glass credentials the person could read are changed within [[1]] working day.
Evidence: For each leaver and mover with privileged access, the time it was removed; for each shared credential they could read, the date it was changed.
PA-15 A supplier's staff must use named accounts, enabled only for the agreed window and logged; shared supplier accounts are not allowed. Where a supplier administers a system on its own platform, the contract clauses of P06 cover it (TP-07, CL-09).
Evidence: Named supplier accounts; their enabled windows against the approved windows; the supplier contract's access clause. Control test CT-13.
PA-17 A privileged account's password or second factor must never be reset on a call alone: identity is confirmed face to face or on video against the HR record, with a call back to the number held there, and a second administrator approves.
Evidence: For each privileged reset, the ticket with the face-to-face or video check, the call back and the second administrator's approval.
Assurance and exceptions
PA-16 Privileged access must be reviewed every [[3]] months by the system owner and information security (P07 AR-02, AR-06), and the controls of this standard tested system by system at least once a year, and every [[6]] months for Tier 0.
Evidence: The access review results for privileged access every quarter; the control review workbook for each system, every year and every six months for Tier 0.
PA-18 Any departure from this standard must be a P02 exception, scored and approved by the approver its band sets (EX-05); a Critical exception is approved by the board or its equivalent. The headline measures are reported monthly to the security and IT leadership team.
Evidence: Each departure recorded as an exception with its score, approver and expiry; the monthly report of the headline measures.
What this standard rules out
Shortcuts administrators take under pressure: reading email or browsing the web while signed in as an administrator (PA-04); giving a user local administrator rights "just to install one thing" (PA-03); keeping Domain Admins or Global Administrator membership permanently "for emergencies" (PA-06, PA-12); approving your own elevation, or granting by hand an elevation you approved (PA-07); using a text message code or a push approval for an administrator account (PA-05); signing in to a file server or a PC with a Tier 0 account (PA-13); sharing a supplier's single login between its engineers (PA-15); leaving a service account's password unchanged because "something might break" (PA-10, PA-11); using the break-glass account because the normal route is slow (PA-12); resetting an administrator's second factor on a phone call (PA-17).
Guidance — delete before approval
The numbers in brackets are drafting defaults: the claim window of [[5]] working days, the [[30]] days before an unowned service account is disabled and the [[90]] days before it is deleted, the [[12]] months of log retention and the elevation maximums. Shorten them where your systems allow; do not lengthen the elevation maximums.
Administrative tiers
Every system has a tier, and every administrator account belongs to one tier and follows the separation rules below (PA-13). An account used outside its tier is treated as a possible exposure of its credential, and handled as the procedure's tier breach steps set.
Three tiers, each a group of systems giving the same level of control over the organisation:
Tier | What it covers | Why it matters | Rights and review |
|---|---|---|---|
Tier 0 Identity and control plane | The systems that control every other system: the directory and the cloud identity tenant, the identity provider and certificate services, the backup system and its console, the endpoint protection and device management consoles, the password vault, and whatever hosts any of these. | Whoever controls Tier 0 controls everything. One stolen Tier 0 credential is a compromise of the whole estate. | Just-in-time only; longest elevation [[4]] hours. Session review: weekly, every event |
Tier 1 Servers, applications and cloud workloads | Servers and the business applications on them, databases, network and security devices, cloud subscriptions and their workloads, and the administrator roles inside business applications. | Where the organisation's data and services live. | Just-in-time only; longest elevation [[8]] hours. Session review: monthly, a sample and every event without a ticket |
Tier 2 End-user devices and user support | Office PCs and laptops, mobile devices and printers, and the service desk's rights over ordinary user accounts (password resets and unlocks). | Where phishing lands and malware runs first. | Standing allowed, on a separate Tier 2 account; longest elevation [[8]] hours. Session review: quarterly, a sample |
Tier separation
Administrator accounts follow these separation rules:
Rule | Requirement |
|---|---|
SR-1 | An administrator account belongs to one tier and administers only that tier. A person who works in two tiers holds one account for each. |
SR-2 | An account of a higher tier never signs in to a system of a lower tier, not even to look something up: its credential could be captured there. |
SR-3 | A lower-tier account holds no control over a higher tier: no membership of its groups, no rights on its systems, and no control of the devices its administrators work from. |
SR-4 | Administrator accounts sign in only from an administration device of their own tier, never from a device used for email or web browsing. |
SR-5 | A service account takes the tier of the most important system it can change, and runs only on systems of that tier. |
SR-6 | A daily account holds no administrator rights in any tier. |
What an account may do on each tier
The separation rules, drawn as a matrix. A row is the account; a column is the system it would touch.
Account | On a Tier 0 system | On a Tier 1 system | On a Tier 2 system |
|---|---|---|---|
Tier 0 administrator account | Administer | Never sign in | Never sign in |
Tier 1 administrator account | No rights | Administer | Never sign in |
Tier 2 administrator account | No rights | No rights | Administer |
Daily account | Use, no administration | Use, no administration | Use, no administration |
"Never sign in" protects the higher-tier credential: a server or PC can be compromised, and a credential typed into it can be captured. "No rights" protects the higher tier: an account that can change a Tier 0 system is itself Tier 0.
EXAMPLE: the distributor's systems, by tier.
System | Tier | Owner | Suppliers with access |
|---|---|---|---|
PS-01 Directory and its administrator groups | Tier 0 | Head of IT | SUP-001, SUP-006 |
PS-02 Cloud identity tenant (email and office, P06 SUP-005) | Tier 0 | Head of IT | SUP-005 |
PS-03 Backup service console (P06 SUP-011) | Tier 0 | Head of IT | SUP-011 |
PS-04 Endpoint protection and device management consoles | Tier 0 | Head of IT | SUP-006 |
PS-05 ERP (hosted, P06 SUP-004; P07 SYS-01) | Tier 1 | Chief Financial Officer | SUP-004 |
PS-06 Warehouse management system servers (P07 SYS-02) | Tier 1 | Head of Logistics | SUP-010 |
PS-07 Online ordering admin console (P07 SYS-04) | Tier 1 | Chief Operating Officer | None |
PS-08 File and application servers, and the firewalls | Tier 1 | Head of IT | SUP-001 |
PS-09 Office PCs and laptops | Tier 2 | Head of IT | SUP-001 |
Accounts and credentials
Account types
The inventory holds six types of privileged account. Each type has its own owner, credential and rules for use.
Type | Who uses it and who owns it | Credential | Sign-in and standing rights |
|---|---|---|---|
AT-01 Named administrator account | One member of staff, for one tier. Owner: The person | The person's own long, unique password, with a phishing-resistant second factor | Interactive: Yes, from an administration device only. Standing: Tier 2 only |
AT-02 Supplier administrator account | One named engineer of a supplier, for one tier. Owner: The system owner, with the supplier accountable for its engineer | As a named administrator account; enabled only for the agreed window | Interactive: Yes, from the agreed route only. Standing: Tier 2 only, or read-only monitoring |
AT-03 Application administrator role | A member of staff who administers a business application. Owner: The system owner | Single sign-on with a phishing-resistant factor where the application allows; otherwise the strongest method it offers, recorded | Interactive: Yes. Standing: Where the application cannot assign roles for a time, recorded |
AT-04 Service account | Software: a service, a scheduled task or an integration. Owner: A named person, never a team or a supplier | Managed by the platform where it can be; otherwise in the vault | Interactive: No: denied by policy. Standing: Yes, the least it needs to run |
AT-05 Shared or built-in administrator account | Whoever opens it from the vault, one person at a time. Owner: A named person | In the vault, or managed by the local administrator password solution; changed after use | Interactive: Yes, recorded by the vault. Standing: Yes, as the system requires; used only by opening the vault |
AT-06 Break-glass account | Any authorised administrator, only when the normal route is unavailable. Owner: The Head of IT | Sealed in the safe and not tied to the normal sign-in route (PA-12) | Interactive: Yes, in an emergency only. Standing: Yes, by design |
Credential rotation
Shared, service and break-glass credentials are kept in the vault or managed by the platform (PA-10). Each is changed as this table sets, at once on suspicion of compromise, and within [[1]] working day of anyone who could read it leaving or moving (PA-14).
Row | Credential | Applies to | When it is changed |
|---|---|---|---|
RT-1 | Named administrator's password | Named administrator account | At least every [[12]] months; sign-in always also needs the phishing-resistant factor |
RT-2 | Supplier administrator's password | Supplier administrator account | At least every [[12]] months, as a named administrator account |
RT-3 | Service account managed by the platform | Service account | Automatically, at least every [[30]] days |
RT-4 | Service account not managed by the platform | Service account | At least every [[12]] months, in a planned change window |
RT-5 | Built-in administrator managed by the local administrator password solution | Shared or built-in administrator account | Automatically, at least every [[30]] days, and after every use |
RT-6 | Shared administrator account in the vault | Shared or built-in administrator account | At least every [[3]] months, and after every use |
RT-7 | Break-glass account | Break-glass account | After every use or test that opens the seal, and at least every [[12]] months |
EXAMPLE: at 30 Sep 2026, 7 of the 8 shared, service and break-glass credentials were within their rotation period. For instance, svc-backup was last changed on 2 Mar 2026 and is next due on 2 Mar 2027; bg-emergency was last changed on 14 Sep 2026 and is next due on 14 Sep 2027. svc-wms-db's password had not changed since 14 Mar 2019: it was in the supplier's support notes and not in the vault, and nobody owned the account (PF-01). (EXAMPLE)
Phishing-resistant sign-in
Every privileged sign-in uses a method a fake sign-in page cannot capture and replay (PA-05). A system that can use neither single sign-on nor such a method uses the strongest it offers, recorded in the inventory with the date it will move.
Methods accepted for privileged access:
- A security key (FIDO2), registered to the person
- A passkey held on a managed device, unlocked by the person (for example Windows Hello for Business)
- A certificate on a smart card or on a managed device
Not accepted as phishing-resistant, for any privileged account:
- A code sent by text message or voice call
- A one-time code from an app or a hardware token
- A push approval in an app, with or without number matching
- A link or code sent by email
Each person with a security key holds [[2]], registered at enrolment, so a lost key is replaced by the spare and never by a weaker method. A certificate or key must need the person's own activation, such as a PIN or fingerprint; a device certificate alone does not prove who is at the keyboard.
Rollout order
Roll out in this order: privileged accounts first, then the routes attackers phish, then everyone.
Stage | Accounts | Method | Why this order |
|---|---|---|---|
1 | Tier 0 administrators, break-glass accounts and supplier administrators with Tier 0 rights | Security keys, [[2]] per person | The accounts whose loss is a whole-estate compromise. |
2 | Every other administrator account and application administrator role | Security keys or passkeys on managed devices | The rest of PA-05. |
3 | Everyone, for remote access and email | Passkeys or security keys; an authenticator app with number matching only as a stop-gap while keys are issued | The routes phishing uses to take over accounts. |
4 | Everyone, everywhere | The same methods for every sign-in | No weaker route left for an attacker to choose. |
Rollout checks
Before each stage starts, check:
Check | What to verify |
|---|---|
MC-A Protocol support | List the systems and protocols that cannot use the new method (older mail protocols, basic authentication, network devices). Block them, put them behind a gateway that can, or record them as exceptions (PA-18). |
MC-B Enrolment | Issue keys in person, or register them from an existing strong factor. Never enrol a privileged account's key from a text message code. |
MC-C Recovery | Register a spare key at enrolment. A lost key is replaced by the spare and reset under PA-17, never by falling back to a weaker method. |
MC-D Break-glass | Where a break-glass account must be left out of a sign-in policy so that a fault in that policy cannot lock everyone out, the gap is covered by the seal, the two-person safe, the alert on every sign-in, the test and the reset after use. It is never covered by leaving the account without a second factor when the platform lets a sealed security key be used. |
EXAMPLE: at 30 Sep 2026, 6 of the 8 named and supplier administrator accounts used a security key. Tier 0 moved to security keys on 21 Sep 2026 (stage 1). The two Tier 2 accounts, adm-dmorgan and adm-lchen, still use an authenticator app with number matching: the inventory records it under PA-05 as the strongest method set up for Tier 2 until rollout stage 2 issues their keys, with the move to security keys by 2 Nov 2026, in stage 2. Staff still sign in with text message codes, the gap the readiness assessment recorded; the authenticator app with number matching is their stop-gap in stage 3, and never an accepted method for an administrator: an administrator account still on it is a PA-05 record with a move date, not a choice. (EXAMPLE)
Just-in-time access and approval
Rights in Tier 0 and Tier 1 are eligible, not active: they are switched on for one approved task and end by themselves after the tier's maximum (PA-06). Standing rights are kept only for the cases PA-06 lists, each recorded in the inventory. Every elevation and every new privileged account is approved by someone other than the person who will use it (PA-07).
Who approves privileged access
Nobody approves their own access. The longest elevation is the tier's maximum, whatever the approval says.
Ref | Request | Approver | Longest window |
|---|---|---|---|
AP-1 | Tier 0 elevation | Head of IT; the Head of Information Security when the requester is the Head of IT or the Head of IT is unavailable | [[4]] hours |
AP-2 | Tier 1 elevation | The system owner, or the Head of IT | [[8]] hours |
AP-3 | Tier 2 administrator account | IT Operations Manager | Not a time window |
AP-4 | New Tier 0 administrator account, or any standing right in Tier 0 | Head of IT and Head of Information Security, both | Not a time window |
AP-5 | New Tier 1 administrator account or application administrator role | The system owner and the Head of IT | Not a time window |
AP-6 | Supplier access window | The system owner sets the window; the Head of IT as well for Tier 0. The Tier 0 maximum still applies | [[8]] hours; Tier 0 [[4]] hours |
AP-7 | Emergency elevation out of hours | Any approver on the [[on-call approver list]], by phone, never the requester; the approval is recorded on the ticket within [[1]] working day | [[4]] hours |
AP-8 | An exception to this standard | The P02 approver for the exception's band (EX-05): for a Critical exception, the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management | Not a time window |
An out-of-hours emergency approval by phone (AP-7) is recorded on the ticket within [[1]] working day. Break-glass is different: it is for when the normal route itself is unavailable, and it has its own rule (PA-12).
EXAMPLE: in the week 21 Sep 2026 to 27 Sep 2026, the first after Tier 0 moved to just-in-time, there were 7 Tier 0 elevations, the longest 3.5 hours (E-03), all within the Tier 0 maximum and each approved by someone other than the account's holder. The Head of IT's own elevations (E-02, E-06) were approved by the Head of Information Security. E-07 was the out-of-hours emergency, approved by phone and recorded the next working day. (EXAMPLE)
At 30 Sep 2026, 2 of 5 administrator accounts with change rights in Tier 0 or Tier 1 held no standing rights there. adm-pshah, ext-msp-aturner and ext-msp-bowen still hold standing Tier 1 rights, which move to just-in-time on 19 Oct 2026. For adm-pshah that is an approved transition, not an exception, while the plan holds. The supplier accounts ext-msp-aturner and ext-msp-bowen also stay enabled between windows, which no transition covers, so they hold P02 exception EX-2026-030 until the same date (see Exceptions). (EXAMPLE)
Session review cadence
Every privileged sign-in, elevation, change to a privileged group or role, and vault opening is logged where administrators cannot change or delete it, for at least [[12]] months (PA-08). Someone with no administrator rights in the tier reviews the activity at the cadence below, and follows up anything unexplained (PA-09).
Who reviews what, how often, and by when after the period ends:
Scope | How often | Due | What is looked at |
|---|---|---|---|
Tier 0 | Weekly | [[2]] working days | Every privileged event: elevations, group and role changes, sign-ins by Tier 0 accounts, vault openings and changes to logging |
Tier 1 | Monthly | [[5]] working days | Every event without a matching ticket, and a sample of [[20]] elevations |
Tier 2 | Quarterly | [[10]] working days | A sample of [[20]] uses of local administrator passwords and service desk resets |
Supplier sessions | Monthly | [[5]] working days | Every supplier session, against the approved windows, with the remote support tool's recording where one exists |
Break-glass use | Every use | [[1]] working day | Every action the account took, against the declared reason |
Every review answers the same seven questions, recorded in the Privileged Session Review Record: SQ-1 does every elevation match an approved ticket, within its time and scope (PA-07); SQ-2 was any privileged right granted or used outside an elevation (PA-06); SQ-3 did any administrator account sign in outside its tier, or to email or the web (PA-13); SQ-4 was any break-glass account used, and was the use declared (PA-12); SQ-5 did any service account sign in interactively (PA-11); SQ-6 was logging stopped, cleared or changed (PA-08); SQ-7 was any privileged password or second factor reset, and did it follow PA-17 (PA-17).
EXAMPLE: the first weekly Tier 0 review, SR-2026-W39, covered 7 elevations and was done on 28 Sep 2026, due by 29 Sep 2026. It answered Yes to SQ-3: an administrator account had signed in outside its tier (PF-03). (EXAMPLE)
Emergency access
Break-glass accounts exist for the day the normal administration route fails, and for nothing else (PA-12). The standard sets how many there are, where their credentials are kept, how every sign-in is noticed, how often they are tested and what happens after each use:
Control | What this standard sets |
|---|---|
How many | [[2]] for each cloud identity tenant or administration portal that could lock every administrator out, and [[1]] for each on-premises directory |
What kind of account | Cloud-only accounts, not synchronised from the directory, not tied to any one person's device, phone or second factor, and excluded from any sign-in policy that could lock every administrator out |
Where the credential is kept | [[The password and the security key sealed in numbered tamper-evident envelopes in the office safe, with a second set in the safe at a second site]]; opening the safe needs [[two people]] |
Monitoring | Every sign-in alerts [[the Head of IT and the Head of Information Security]] at once, by [[email and text message]], and the alert is itself tested |
Testing | Every [[3]] months: sign-in works and the alert fires |
Left out of a sign-in policy | Where a break-glass account must be left out of a sign-in policy so that a fault in that policy cannot lock everyone out, the gap is covered by the seal, the two-person safe, the alert on every sign-in, the test and the reset after use. It is never covered by leaving the account without a second factor when the platform lets a sealed security key be used. |
The Break-Glass Account Control Checklist checks each break-glass account against ten controls, BG-01 to BG-10, at every test and after every use.
After emergency use
After every use, in this order:
Step | What happens | When |
|---|---|---|
1 | The user declares the use to the Head of IT, or the Head of Information Security if the Head of IT is unavailable, with the reason, before signing in or at once after | Before or at the time of use |
2 | The alert is confirmed as received; if it did not fire, that is a finding of its own | At the time of use |
3 | The Head of Information Security reviews every action the account took against the stated reason, from the log the account cannot change | [[1]] working day |
4 | The password is changed, a new security key registered where one was used, and both resealed; the old envelope is kept with the record | [[1]] working day |
5 | The cause is fixed so the normal route works, and the record is closed with the reviewer's name | Before the record is closed |
EXAMPLE: BGU-2026-01, the one use in the quarter, on 5 Sep 2026.
Step | What happened | Against the standard |
|---|---|---|
Reason | A sign-in policy change made at 22:10 required a compliant device that no administration device met, and locked every administrator out of the cloud tenant | The normal route was unavailable: a valid use |
Declared | By phone to Mark Ellis at 22:35 | Before the sign-in at 22:40 |
Alert | Received at 22:41 | Fired, so no finding of its own |
Use | bg-cloud-01, 22:40 to 23:05, by Beth Owen, the managed IT provider's on-call engineer (P06 SUP-001) | Every action matched the reason: the policy was rolled back at 22:52 and nothing else was changed. |
Credential changed and resealed | 7 Sep 2026 | 1 working day after the use: on time |
Session reviewed | 25 Sep 2026, by Ruth Okafor | 15 working days after the use; 14 working days late (PF-02) |
The break-glass use on 5 Sep 2026 was declared and the credential changed on time, but nobody reviewed the session: the Head of IT thought the provider would, and the provider thought the Head of IT would. The fix was to name the Head of Information Security as the reviewer of every use in the checklist. The quarterly test on 14 Sep 2026 covered all 3 accounts: sign-in worked, the alert in 2 minutes, each resealed the same day. (EXAMPLE)
Service accounts
Every service account has a named owner, does one job with the least rights it needs, and cannot sign in interactively (PA-11). One with no owner after [[30]] days is disabled, and deleted [[90]] days later if nothing breaks.
For a service account nobody owns, the Privileged Access Request, Elevation & Revocation Procedure sets six steps: find them, name an owner, stop interactive logon, change and store the credential, cut its rights and watch it. An interim owner is named within [[5]] working days (PA-01), so the account is controlled while its dependencies are checked.
EXAMPLE, PF-01: svc-wms-db, with local administrator rights on both warehouse system servers. The warehouse system's database service account had no owner and was not in the inventory. It could sign in interactively, its password had not changed since the system was installed on 14 Mar 2019, and the supplier's support staff used it to sign in through the remote support tool, most recently on 16 Sep 2026. (EXAMPLE)
Leavers, movers and resets
Privileged access goes on the day a person leaves or moves, and at once for an urgent departure; shared, service and break-glass credentials they could read are changed within [[1]] working day (PA-14). This is stricter than the general leaver rule:
Ref | When | Privileged access removed |
|---|---|---|
RV-1 | A planned leaver | All privileged accounts disabled by the end of the last working day, at the latest when the daily account is |
RV-2 | An urgent leaver, or one leaving on bad terms | All privileged accounts disabled at once, before the person is told, and their sessions ended |
RV-3 | A mover whose new role does not need the access | Removed on the day the move takes effect |
RV-4 | A supplier engineer who leaves or no longer needs access | The supplier must remove access within [[1]] working day of a person leaving the supplier or no longer needing it (P06 CL-09, 9.3). Where we hold the account, we disable it the same day we learn of the leaver. |
RV-5 | Anyone who could read a shared, service or break-glass credential | Each such credential changed within [[1]] working day of the leaving or move |
EXAMPLE: adm-kwalsh, a Tier 0 account, belonged to a network engineer who left on 30 Jun 2026. Nobody removed it; the access review found it and it was removed on 9 Sep 2026, 51 working days later. That is the case PA-14 exists for. (EXAMPLE)
A privileged account's password or second factor is never reset on a call alone (PA-17). Identity is confirmed face to face or on video against the HR record, with a call back to the number held there, and a second administrator approves.
The Privileged Access Request, Elevation & Revocation Procedure sets the six checks of a privileged reset. The general reset checks of the Joiner-Mover-Leaver Operating Procedure are not enough for a privileged account.
Suppliers
A supplier's engineers use named accounts, enabled only for the agreed window and logged; a shared supplier account is not allowed (PA-15).
The supplier contract's access clause (P06 CL-09, Third-Party Security Risk Management pack) requires named personnel, individual accounts with multi-factor authentication, and privileged access logged and kept for at least [[12]] months. The supplier must remove access within [[1]] working day of a person leaving the supplier or no longer needing it (P06 CL-09, 9.3). Where we hold the account, we disable it the same day we learn of the leaver. A supplier's engineer signs in with a named account enabled only for the approved window (AP-6).
EXAMPLE: the warehouse system supplier's engineers signed in through the remote support tool with svc-wms-db, a service account, instead of named accounts. Named accounts for the two engineers are due by 9 Oct 2026, and the finding goes into the supplier's assessment. (EXAMPLE)
Built-in controls
Every rule can be met without a privileged access management platform. How, with tools most organisations already have:
Control | How to build it | Rules |
|---|---|---|
Separate administrator accounts | Create a second account per person per tier in the directory, named by tier (for example a0-, a1-, a2-). Give it no mailbox and no office licence. | PA-02, PA-04 |
No administrator rights on daily accounts | Remove daily accounts from every local and directory administrator group through device management or group policy, and let support use the local administrator password solution. | PA-03 |
Unique local administrator passwords | Turn on the operating system's local administrator password solution (Windows LAPS is built in): a different password on every device, changed automatically and after use, with every opening logged. | PA-10 |
Time-limited elevation | Use the directory's time-limited group membership, or the cloud tenant's time-limited role assignment where the licence includes it. Otherwise add the right by ticket with an end time, and run a scheduled task that removes it and a daily report that lists any right older than its ticket. | PA-06 |
Phishing-resistant sign-in | Register security keys or passkeys in the identity provider the organisation already has, and require them for administrator accounts by sign-in policy. | PA-05 |
Tier separation | Use group policy to deny sign-in by higher-tier administrator groups on lower-tier systems (console, Remote Desktop, batch and service logon), and add Tier 0 accounts to the directory's protected users group. | PA-13 |
Administration devices | A dedicated administrator workstation per tier, or a hardened jump host reached from one. At the least, a separate hardened virtual machine with no email and browsing limited to the administration portals. | PA-04 |
The vault | The organisation's business password manager, in a shared vault open only to named administrators, with its access log kept. Break-glass credentials also go in the safe. | PA-10, PA-12 |
Logging | Forward the directory's security events (for Windows: 4624 sign-in, 4672 special privileges assigned, 4728, 4732 and 4756 group membership added), the cloud tenant's audit and sign-in logs and servers' administrator command logs to the central log store the monitoring provider keeps. | PA-08 |
Session review | A saved search per tier over the forwarded logs, run by the reviewer at the cadence set, compared with the ticket list. Supplier sessions are recorded by the remote support tool where it can. | PA-09 |
Service accounts | Use the platform's managed service accounts or managed identities, which change their own passwords; deny interactive and Remote Desktop logon to every other service account by group policy. | PA-11 |
Guidance — delete before approval
A platform automates the vault, the time limits and the session recording, and is worth buying once the estate is large. It is not a precondition: the rules are the same with or without one.
Control review
Privileged access is reviewed every [[3]] months by the system owner and information security, in the access review campaign, and the controls of this standard are tested system by system (PA-16).
The Privileged Access Control Review Workbook runs 13 tests, CT-01 to CT-13, one or more for each rule it can test, system by system: every [[12]] months, and every [[6]] months for Tier 0. The evidence line under each requirement names its test. A failed test is a finding, with an owner and a date.
EXAMPLE: the first control review, CR-2026-01 on 24 Sep 2026, covered PS-01 Directory and its administrator groups, PS-02 Cloud identity tenant (email and office, P06 SUP-005) and PS-06 Warehouse management system servers (P07 SYS-02): the two Tier 0 identity systems, and the warehouse system because its supplier (P06 SUP-010) has remote support access and is not yet assessed. It failed 5 tests: CT-11 on PS-02 (PF-02), CT-01 on PS-06 (PF-01), CT-09 on PS-06 (PF-01), CT-10 on PS-06 (PF-01) and CT-13 on PS-06 (PF-01). (EXAMPLE)
Measures and reporting
Every measure goes monthly to the security and IT leadership team. A measure outside tolerance goes to the next executive committee with its plan. The Privileged Access Metrics Dashboard holds the measures.
Each measure with its target, and the EXAMPLE at 30 Sep 2026 against the tolerances the security and IT leadership team set. The Privileged Access Metrics Dashboard defines each one.
Measure | Target | EXAMPLE |
|---|---|---|
PAM-01 Privileged accounts | Every one in the inventory with an owner; the count level or falling | 18: no target set |
PAM-02 Administrator accounts on just-in-time access | All | 2 of 5: below target, within tolerance (tolerance [[40% until Tier 1 moves on 19 Oct 2026]]) |
PAM-03 Daily accounts with administrator rights | Zero | 38: below target, within tolerance (tolerance [[40 until the last are removed by 31 Oct 2026 (PIA-01)]]) |
PAM-04 Credentials changed on time | All | 7 of 8: below target, within tolerance (tolerance [[85%]]) |
PAM-05 Reviews on time | All | 2 of 2: on target (tolerance same as the target) |
PAM-06 Break-glass uses reviewed on time | All | 0 of 1: outside tolerance (tolerance same as the target: every use) |
PAM-07 Session reviews on time | All | 1 of 1: on target (tolerance same as the target) |
PAM-03 fell from 146 to 38 in September, after the ransomware incident that began on a daily account with local administrator rights. At the two smaller warehouses, where the label-printing software needs administrator rights to update. Its supplier's fixed version is due in October; until then the rights stay, and the devices are in the Tier 2 session review sample. PAM-06 is outside tolerance: the one break-glass use was reviewed 14 working days late. (EXAMPLE)
Exceptions
Any departure from this standard is a P02 exception, scored and approved by the approver its band sets; a Critical exception is approved by the board or its equivalent (PA-18).
An exception is requested on the Security Exception Request & Approval Form and recorded in the Security Exception Register. Its band sets the approver and how long it may last: from 365 days for Low, approved by the control owner, to 30 days for Critical.
A rule adopted with a later start date, on an approved plan, is a transition, not an exception, while the plan holds. If the plan slips, the rule becomes an exception that day.
EXAMPLE: the transitions approved with the standard.
Rule | From | What changes |
|---|---|---|
PA-06 | 19 Oct 2026 | Tier 1 rights move to just-in-time |
PA-03 | 31 Oct 2026 | The last local administrator rights on daily accounts are removed (P09 PIA-01) |
EXAMPLE: the exception approved with the standard.
Exception | Departure and reason | Score and approval | Expires |
|---|---|---|---|
EX-2026-030 PA-06, PA-15 | The managed IT provider's two engineers (P06 SUP-001) keep standing Server Admins rights in Tier 1, on accounts left enabled between approved windows. The provider runs day-to-day server support under its contract, and time-limited elevation for Tier 1 starts only when Tier 1 moves to just-in-time. Compensating control: security keys on both accounts, in place and tested at approval. | Impact 3 × likelihood 2 (3 before the compensating control, EX-07) = 6, Medium. Requested by Mark Ellis (Head of IT); approved by Ruth Okafor (Head of Information Security) on 18 Sep 2026 (EX-05). | 19 Oct 2026. Both accounts move to time-limited Server Admins membership, enabled only for approved windows, when Tier 1 moves to just-in-time. |
Records to keep
Record | Kept | Rule |
|---|---|---|
The inventory, with every change to it | While the account exists, and [[the period your records policy sets]] after | PA-01 |
Every elevation: ticket, approver, start and end | [[The period your records policy sets, and at least until the next audit]] | PA-06, PA-07 |
Privileged sign-ins, elevations, group and role changes and vault openings | At least [[12]] months, where administrators cannot change them | PA-08 |
Session review records, with anomalies and follow-up | [[The period your records policy sets]] | PA-09 |
Break-glass tests and uses, with reviews and credential changes | [[The period your records policy sets]] | PA-12 |
Privileged resets, with the checks made | [[The period your records policy sets]] | PA-17 |
Control review workbooks and access review results | [[The period your records policy sets, and at least until the next audit]] | PA-16 |
Worked example: the first two weeks
EXAMPLE, not part of the standard. The organisation is the one used throughout the pack: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. Replace it with your own, or delete this section before approval.
Date | What happened | Rule |
|---|---|---|
16 Sep 2026 | Inventory built: 22 privileged accounts in the quarter, 18 still enabled at its end. | PA-01 |
18 Sep 2026 | Standard approved by the Head of Information Security, owned by the Head of IT. | PA-18 |
21 Sep 2026 | Tier 0 live: security keys for every Tier 0 administrator account, time-limited membership of the Tier 0 groups and roles, and the weekly Tier 0 session review. | PA-05, PA-06, PA-09 |
24 Sep 2026 | First control review: 5 failed tests, PF-01 and PF-02 raised. | PA-16 |
24 Sep 2026 | adm-pshah, elevated to Backup Operators (E-04), signs in to FS-02, a Tier 1 file server (PS-08) at 11:10. | PA-13 |
28 Sep 2026 | First weekly Tier 0 review finds it: PF-03. Password changed and sessions ended the same day. | PA-09, PA-13 |
At the quarter end PF-01 was open (1 of 5 actions done, the last due 20 Oct 2026), PF-02 was closed (2 of 2 actions done) and PF-03 was open (2 of 3 actions done, the last due 28 Oct 2026).
The position for the leadership team: Tier 0 is on security keys and just-in-time access since 21 Sep 2026; 2 of 5 Tier 0 and Tier 1 administrator accounts are just-in-time, 38 daily accounts still have administrator rights, and the first reviews found an unowned service account, an unreviewed break-glass use and one tier breach, all being fixed by 28 Oct 2026.
Guidance — delete before approval
What the two weeks taught: the inventory found an account nobody owned before an attacker did; the break-glass use was handled well until the review, which each side thought the other would do; and the first session review paid for itself in its first week.
Related documents
Document | Relationship |
|---|---|
Privileged Access Request, Elevation & Revocation Procedure | Runs the rules: requests, elevation, removal, resets, service accounts and tier breaches |
Privileged & Service Account Inventory | Every privileged and service account, with owner, tier, credential and rotation (PA-01, PA-10) |
Break-Glass Account Control Checklist | The break-glass checks and the record of every test and use (PA-12) |
Privileged Access Control Review Workbook | The control tests, system by system (PA-16) |
Privileged Session Review Record | The session review record (PA-09) |
Administrative Tier Model & Separation Matrix | The tiers and the separation matrix (PA-13) |
Privileged Access Metrics Dashboard | The headline measures (PA-18) |
Access Control Policy; Joiner-Mover-Leaver Operating Procedure | The general joiner, mover and leaver rules and reset checks (Joiner-Mover-Leaver & Access Provisioning pack) |
Access Review Methodology | The review of privileged access every 3 months (PA-16; User Access Review pack) |
Security Exception & Waiver Standard; Segregation of Duties Conflict Matrix | Exceptions and the conflicts of duties (PA-07, PA-18; Security Exception, Waiver & Segregation of Duties pack) |
Supplier Contract Security Clause Library | The supplier access clause (PA-15; Third-Party Security Risk Management pack) |
Security Incident Management Policy | A tier breach with signs of compromise, or misuse of privileged access, is an incident (Security Incident Management pack) |
[[Information Security Policy]] | [[Parent policy]] |
Adapting this template
Guidance — delete before approval
Small organisation: keep the separate administrator accounts, phishing-resistant sign-in for them, the break-glass accounts and the weekly Tier 0 review; they cost little and stop most attacks on administrators. With one or two administrators, Tier 1 and Tier 2 may share a person but not an account. Time-limited group membership is built into most directories; where it is not, the ticket with an end time and a daily report of rights older than their ticket is enough.
Regulated entity (NIS2, DORA): NIS2 Article 21(2)(i) and (j) ask for access control and multi-factor authentication. For the digital providers its Article 1 names, Implementing Regulation (EU) 2024/2690 asks for policies for privileged and system administration accounts (Annex point 11.3), dedicated administration systems (11.4), separate credentials for privileged access (11.6.2(f)) and multi-factor authentication by asset classification (11.7.1). A DORA financial entity needs strong authentication (Article 9(4)(d)), privileged and emergency access on a need-to-use or ad-hoc basis (Delegated Regulation (EU) 2024/1774, Article 21(e)(ii)), strong authentication for privileged access (21(f)(ii)) and dedicated administrator accounts (Article 21, on point (e)(ii)). This standard is written to be that policy.
IT run by a service provider: your managed IT provider's engineers are supplier administrators: named accounts, approved windows, phishing-resistant sign-in and the session review apply to them as to your own staff. Approval and review stay with your organisation; put the rest into the contract.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. ISO/IEC 27001 references name the clause or control this document relates to. They do not say that meeting it meets any other framework's requirement. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA) and Delegated Regulation (EU) 2024/1774.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 8.2 — Privileged access rights | Whole standard: privileged access rights restricted and managed |
ISO/IEC 27001:2022 | Annex A 8.5 — Secure authentication | Phishing-resistant sign-in (PA-05) |
ISO/IEC 27001:2022 | Annex A 5.15 — Access control | Principles; administrative tiers |
ISO/IEC 27001:2022 | Annex A 5.17 — Authentication information | Credential rotation; resets (PA-10, PA-17) |
ISO/IEC 27001:2022 | Annex A 5.18 — Access rights | Just-in-time access and approval; leavers and movers (PA-06, PA-07, PA-14) |
ISO/IEC 27001:2022 | Annex A 8.15 — Logging | Logging of privileged activity (PA-08) |
ISO/IEC 27001:2022 | Annex A 8.16 — Monitoring activities | Session review cadence (PA-09) |
ISO/IEC 27001:2022 | Annex A 5.19 — Information security in supplier relationships | Suppliers (PA-15) |
NIST CSF 2.0 | PR.AA-05 — “Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties” | Whole standard: permissions managed with least privilege and separation of duties |
NIST CSF 2.0 | PR.AA-01 — “Identities and credentials for authorized users, services, and hardware are managed by the organization” | Accounts and credentials; the inventory (PA-01, PA-10) |
NIST CSF 2.0 | PR.AA-03 — “Users, services, and hardware are authenticated” | Phishing-resistant sign-in (PA-05) |
NIST CSF 2.0 | PR.PS-04 — “Log records are generated and made available for continuous monitoring” | Logging (PA-08) |
NIST CSF 2.0 | DE.CM-03 — “Personnel activity and technology usage are monitored to find potentially adverse events” | Session review cadence (PA-09) |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(i) — “human resources security, access control policies and asset management” | Whole standard; regulated-entity tailoring |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(j) — “the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate” | Phishing-resistant sign-in; rollout order |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers | Regulated-entity tailoring: the entities the Implementing Regulation binds |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.3.1 — “The relevant entities shall maintain policies for management of privileged accounts and system administration accounts as part of the access control policy referred to in point 11.1.” | Whole standard: the policy for privileged and administration accounts |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.3.2 — the policies shall “(a) establish strong identification, authentication such as multi-factor authentication, and authorisation procedures for privileged accounts and system administration accounts; (b) set up specific accounts to be used for system administration operations exclusively, such as installation, configuration, management or maintenance; (c) individualise and restrict system administration privileges to the highest extent possible, (d) provide that system administration accounts are only used to connect to system administration systems.” | Separate accounts and devices; sign-in; just-in-time rights (PA-02 to PA-06) |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.4 — the use of system administration systems is restricted and controlled: they are used “only … for system administration purposes, and not for any other operations”, separated logically “from application software not used for system administrative purposes”, and access to them is protected “through authentication and encryption” | Administration devices; tier separation (PA-04, PA-13) |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.6.2(c) — “require the change of authentication credentials initially, at predefined intervals and upon suspicion that the credentials were compromised” | Credential rotation (PA-10) |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.6.2(f) — “require separate credentials to access privileged access or administrative accounts” | Separate administrator credentials (PA-02) |
NIS2 — Implementing Regulation (EU) 2024/2690 | Annex, point 11.7.1 — “The relevant entities shall ensure that users are authenticated by multiple authentication factors or continuous authentication mechanisms for accessing the relevant entities’ network and information systems, where appropriate, in accordance with the classification of the asset to be accessed.” | Phishing-resistant sign-in (PA-05) |
DORA — Regulation (EU) 2022/2554 | Article 9(4)(c) — policies that limit access to information and ICT assets to what is required for legitimate and approved functions, with controls that ensure sound administration of access rights | Principles: access limited to legitimate, approved functions |
DORA — Regulation (EU) 2022/2554 | Article 9(4)(d) — “implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems, and protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes” | Phishing-resistant sign-in; the vault (PA-05, PA-10) |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(a) — “the assignment of access rights to ICT assets based on need-to-know, need-to-use and least privilege principles, including for remote and emergency access” | Just-in-time access; emergency access (PA-06, PA-12) |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(c) — user accountability: generic and shared accounts limited, and users identifiable for their actions | Named accounts; shared accounts only in the vault (PA-02, PA-15) |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(e)(ii) — “assignment of privileged, emergency, and administrator access on a need-to-use or an ad-hoc basis for all ICT systems” | Just-in-time and emergency access (PA-06, PA-12) |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21(f)(ii) — “the use of strong authentication methods in accordance with leading practices and techniques for remote access to the financial entity’s network, for privileged access, for access to ICT assets supporting critical or important functions or ICT assets that are publicly accessible” | Phishing-resistant sign-in for privileged access (PA-05) |
DORA — Delegated Regulation (EU) 2024/1774 | Article 21, on point (e)(ii) — “financial entities shall, where possible, use dedicated accounts for the performance of administrative tasks on ICT systems. Where feasible and appropriate, financial entities shall deploy automated solutions for the privilege access management.” | Separate administrator accounts; built-in controls in place of a platform |
Definitions
Term | Meaning in this standard |
|---|---|
Privileged access | Rights that let an account change a system's configuration, security settings, users or permissions, read or change data beyond one person's job, or turn off a control. Administrator rights are privileged access; so are an application's administrator roles. |
Privileged account | Any account that holds privileged access, standing or when elevated: a named administrator account, a supplier's administrator account, an application administrator role, a service account, a shared or built-in administrator account, or a break-glass account. |
Daily account | The account a person uses for email, web browsing, chat and ordinary work. It holds no administrator rights anywhere (PA-03). |
Administrator account | A separate account, named for one person and one tier, used only for administration (PA-02). It has no mailbox and is never used for email or web browsing. |
Standing rights | Privileged rights an account holds all the time, whether or not the person is doing administration. |
Just-in-time | Privileged rights that are eligible but not active. They are switched on for one task, after approval, for no longer than the tier's maximum, and switch off by themselves. |
Elevation | One activation of just-in-time rights: who, which rights, which system, why, who approved, when it started and when it ended. |
Tier | A group of systems that give the same level of control over the organisation. An administrator account belongs to one tier (A08). |
Control plane | The systems that control identities and every other system: the directory, the cloud identity tenant and anything that can change them. Tier 0. |
Administration device | A device used only for administration: a dedicated administrator workstation, or a hardened jump host reached through one. No email and no web browsing beyond the administration portals it needs. |
Service account | An account used by software, not a person: to run a service, a scheduled task or an integration. It has a named owner and cannot sign in interactively (PA-11). |
Interactive logon | Signing in as a person would: at the console, through Remote Desktop, or through a remote support tool. A service account must not be able to. |
Shared account | An administrator account more than one person can use, including the built-in administrator accounts of devices and systems. Its credential is held in the vault and changed after use (PA-10). |
Break-glass account | An emergency account used only when the normal administration route is unavailable, such as when every administrator is locked out. Sealed, watched, tested and reset after every use (PA-12). |
Vault | Where shared, service and break-glass credentials are kept: a password manager or vault that records who opened which credential and when, open only to named administrators. A break-glass credential is also sealed in a safe. |
Rotation | Changing a credential: a new password, secret or key, with the old one no longer working. |
Phishing-resistant | A sign-in method that a fake sign-in page cannot capture and replay, because it proves possession of a key bound to the real site: a security key, a passkey on a managed device, or a certificate on a smart card or managed device (PA-05). |
Session review | A check, by someone other than the administrator, that privileged activity in a period matches approved tickets and the rules, with anything unexplained followed up (PA-09). |
Tier breach | An administrator account used outside its tier, or for email or browsing. Treated as a possible exposure of that account's credential (PA-13). |
Working day | Monday to Friday, excluding [[public holidays where you are]]. |