# Privileged Access Standard: [Organisation]

> Organisation-wide standard for privileged access management (PAM):
> scope, roles, privileged account types, an administrative tier model,
> numbered mandatory requirements for account management, authentication,
> least privilege, just-in-time elevation, privileged access workstations,
> session management and recording, break-glass (emergency) access,
> service and workload accounts, third-party access, monitoring, periodic
> review, metrics and exceptions, with a control mapping to NIST SP 800-53
> Rev. 5 (release 5.2.0, August 2025: AC-2, AC-6, IA-2 and related
> controls) and alignment with the zero trust principles of NIST SP 800-207
> (August 2020). Versions as checked in October 2026. The requirements and
> examples are original. Replace every `[bracketed]` value and every row
> marked *Example*.

<!--
Guidance: How to use this template
- This is a standard: it says what MUST be true, not how a product is
  configured. Keep product runbooks separate and link them.
- Write every requirement so an auditor can test it (who, what, how often,
  evidence). Give every requirement an ID and keep IDs stable.
- Agree the tier model (section 4) with infrastructure and identity teams
  first; most other rules depend on it.
- Pitfall: buying a PAM vault and calling the problem solved. Vaulting
  shared passwords is one control; standing privilege, privileged use from
  ordinary laptops and unreviewed service accounts are usually the bigger
  risks.
- If you are subject to a regulation (for example EU NIS2, DORA, PCI DSS or
  US federal requirements), map this standard to it in section 13 and
  check the current official text; this template is not legal advice.
- Related templates: [IAM solution design](../security/iam-solution-design.md),
  [Zero trust architecture](../security/zero-trust-architecture.md),
  [Secrets management standard](../security/secrets-management-standard.md),
  [Security logging standard](../security/security-logging-standard.md),
  [Access review](../ops/access-review.md),
  [SOC playbook](../security/soc-playbook.md) and
  [Security exception request](../security/security-exception-request.md).
-->

## Document control

<!-- Guidance: Name an owner with authority over identity and infrastructure, and approvers who can accept exceptions for Tier 0. Record the control catalogue version used for the mapping. -->

| Field | Value |
|---|---|
| Document ID | [SEC-STD-PAM-001] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@identity-security-lead] |
| Approvers / reviewers | [@ciso], [@head-of-infrastructure], [@internal-audit] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Effective date | YYYY-MM-DD |
| Transition period | [Requirements marked "Phase 2" apply from YYYY-MM-DD] |
| Next review | YYYY-MM-DD (at least yearly) |
| Parent policy | [Information security policy, access control section] |
| Mapping baseline | NIST SP 800-53 Rev. 5, release 5.2.0; NIST SP 800-207 |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Identity security lead (owner) | [@name] | [Proposed] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Head of infrastructure | [@name] | [Approved / Changes requested] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; tier model and JIT rules in force |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added workload identity rules (PA-SVC-05) after cloud migration |

## Contents

1. [Purpose, scope and applicability](#1-purpose-scope-and-applicability)
2. [Roles and responsibilities](#2-roles-and-responsibilities)
3. [Privileged account types](#3-privileged-account-types)
4. [Administrative tier model](#4-administrative-tier-model)
5. [Mandatory requirements](#5-mandatory-requirements)
6. [Just-in-time elevation workflow](#6-just-in-time-elevation-workflow)
7. [Break-glass access](#7-break-glass-access)
8. [Session management and recording](#8-session-management-and-recording)
9. [Periodic review and recertification](#9-periodic-review-and-recertification)
10. [Metrics and reporting](#10-metrics-and-reporting)
11. [Exceptions and non-compliance](#11-exceptions-and-non-compliance)
12. [Zero trust alignment](#12-zero-trust-alignment)
13. [Control mapping](#13-control-mapping)
14. [Glossary and references](#14-glossary-and-references)

## 1. Purpose, scope and applicability

<!-- Guidance: Define "privileged" in your own terms, broadly enough to catch cloud consoles, SaaS admin roles, CI/CD and database owners, not only domain admins. Questions: Which systems are in scope? Do contractors and managed service providers follow this standard? Pitfall: a scope that covers servers but not SaaS and cloud control planes, where most administrative power now sits. -->

**Purpose.** This standard sets the minimum rules for granting, using, monitoring and removing privileged access, so that a stolen credential or a mistaken action by an administrator cannot cause unlimited damage.

**Privileged access** means any access that can change security settings, read or change other users' data in bulk, manage identities and permissions, change infrastructure, deploy code to production, or turn off logging and monitoring.

**Scope:** [all production and non-production environments that hold production data; on-premises servers and network devices; cloud tenants and subscriptions; SaaS administrative roles; identity providers and directories; CI/CD pipelines and code repositories with production deploy rights; databases; security tools; operational technology where present].

**Applies to:** employees, contractors, managed service providers, vendors with remote access, and non-human identities (service accounts, workload identities, automation and AI agents acting with privileged permissions).

**Normative words:** MUST is mandatory; SHOULD is expected unless a documented reason exists; MAY is optional.

## 2. Roles and responsibilities

<!-- Guidance: Every requirement in section 5 needs a role that does it and a role that checks it. Keep separation of duties: the person who approves privilege should not be the person who receives it. -->

| Role | Responsibilities |
|---|---|
| Identity security lead (standard owner) | Maintains this standard, the tier model and the PAM platform design; reports metrics |
| System owner | Decides who needs privileged access to their system, approves elevation requests, performs periodic review |
| Privileged user | Uses privileged access only for approved tasks from approved devices; protects authenticators |
| PAM platform team | Operates the vault, elevation broker, session recording and their integrations |
| Security operations (SOC) | Monitors privileged activity, investigates alerts, reviews break-glass use |
| Line manager | Confirms the continuing need for a person's privileged roles; triggers removal on role change |
| Internal audit | Tests compliance with this standard independently |

| Activity | Identity security | System owner | Privileged user | SOC | Audit |
|---|---|---|---|---|---|
| Define tiers and roles | A, R | C | I | C | I |
| Approve elevation | I | A, R | I | I | I |
| Monitor privileged sessions | C | I | I | A, R | I |
| Periodic review | C | A, R | I | I | C |
| Break-glass post-use review | A | R | C | R | I |

R = responsible, A = accountable, C = consulted, I = informed.

## 3. Privileged account types

<!-- Guidance: List every type you have. Each type gets its own rules in section 5. Pitfall: forgetting cloud root accounts, SaaS "global admin" roles and CI/CD service principals. -->

| Type | Description | Examples | Key rules |
|---|---|---|---|
| Personal admin account | Separate privileged account for a named person, never used for email or browsing | `adm-[name]` | PA-ACC-02, PA-AUTH-01 |
| Role-based elevation | Privilege granted to a personal identity for a limited time | Cloud role activation, sudo via broker | PA-JIT-01 to PA-JIT-05 |
| Emergency (break-glass) account | Account kept for when normal access paths fail | Cloud tenant emergency account | Section 7 |
| Built-in or root account | Account created by the platform with full power | Cloud root, local administrator, `root` | PA-ACC-05 |
| Shared account | Account that cannot be tied to one person by itself | Network device `admin` | PA-ACC-04 |
| Service or workload account | Non-human identity used by software | Database service account, CI deploy identity | PA-SVC-01 to PA-SVC-05 |
| Third-party account | Access by vendors or managed service providers | Vendor support access | PA-VEN-01 to PA-VEN-04 |

## 4. Administrative tier model

<!-- Guidance: A tier model stops an attacker who compromises a low-value system from harvesting credentials that control high-value systems. The core rule: credentials of a higher tier are never exposed on a lower-tier system. Adapt the tiers to your estate and list concrete systems in each. -->

| Tier | What it controls | Examples *(Example)* |
|---|---|---|
| Tier 0 | Identity and control planes: whoever controls these controls everything | Directory and identity provider, PKI, PAM platform, cloud organisation root and management groups, backup control plane, security tooling with fleet-wide agents |
| Tier 1 | Servers, workloads, data and business applications | Production servers, cloud subscriptions and accounts, databases, Kubernetes clusters, CI/CD production deploy |
| Tier 2 | User devices and user-facing support | Laptops, mobile devices, helpdesk tools, end-user SaaS administration of low-risk settings |

```mermaid
flowchart TB
    T0["Tier 0: identity and control planes"]
    T1["Tier 1: servers, workloads, data"]
    T2["Tier 2: user devices and support"]
    P0["Tier 0 access workstation"] --> T0
    P1["Tier 1 access workstation"] --> T1
    P2["Standard managed device"] --> T2
    T0 -->|"controls"| T1
    T1 -->|"controls"| T2
    T2 -. "no logon with higher-tier credentials" .-> T1
    T1 -. "no logon with higher-tier credentials" .-> T0
```

Tier rules:

- **PA-TIER-01** A privileged identity MUST belong to exactly one tier, and MUST NOT be used to sign in to a system of a lower tier.
- **PA-TIER-02** Systems that can control Tier 0 (for example agents with fleet-wide administrative rights, backup servers holding directory backups) MUST be classified as Tier 0.
- **PA-TIER-03** The tier of every system MUST be recorded in the configuration management database, and changes reviewed by the identity security lead.
- **PA-TIER-04** Tier 0 membership SHOULD be kept to the smallest number of people that still covers operations and absence ([target: no more than n named people]).

## 5. Mandatory requirements

<!-- Guidance: Each requirement has an ID, a testable statement and a mapping in section 13. Mark requirements that phase in later. Keep them short; put procedures in runbooks. -->

### 5.1 Account management (PA-ACC)

- **PA-ACC-01** Every privileged account MUST have a named owner, a documented purpose, a tier and an expiry or review date in the identity governance system.
- **PA-ACC-02** People who need privileged access MUST use an account or role separate from their everyday account; everyday accounts MUST NOT hold standing privileged roles.
- **PA-ACC-03** Privileged accounts MUST be disabled within [24 hours] of the holder leaving or changing role, and within [1 hour] for a termination with risk.
- **PA-ACC-04** Shared accounts MUST be avoided. Where a platform requires one, its password MUST be vaulted, checked out to a named person per use and rotated after use.
- **PA-ACC-05** Built-in and root accounts MUST be secured with strong, vaulted credentials and phishing-resistant multi-factor authentication where the platform supports it, and used only for tasks that need them.
- **PA-ACC-06** Privileged accounts unused for [35 days] MUST be disabled automatically.

### 5.2 Authentication (PA-AUTH)

- **PA-AUTH-01** All privileged access MUST use multi-factor authentication; Tier 0 and Tier 1 access MUST use phishing-resistant authenticators (for example FIDO2 security keys, platform passkeys bound to a managed device, or PKI smart cards).
- **PA-AUTH-02** SMS, voice and email one-time codes MUST NOT be used for privileged access.
- **PA-AUTH-03** Authenticators for privileged accounts MUST be issued only after identity verification and MUST be revoked when the account is disabled.
- **PA-AUTH-04** Privileged sessions MUST re-authenticate at elevation time, not only at sign-in.

### 5.3 Least privilege (PA-LP)

- **PA-LP-01** Privileged roles MUST be designed per task (for example "database backup operator", "network change implementer") instead of full administrator roles.
- **PA-LP-02** Rights to change security functions (logging, monitoring, access control, encryption keys) MUST be granted only to roles whose task requires it.
- **PA-LP-03** Use of privileged functions MUST be logged (see section 8).
- **PA-LP-04** Non-privileged users MUST be technically prevented from running privileged functions, including disabling or bypassing security safeguards.

### 5.4 Just-in-time elevation (PA-JIT)

- **PA-JIT-01** Tier 0 and Tier 1 privileges MUST be granted just in time, for a limited duration ([default 4 hours, maximum 8 hours]), with no standing assignment. Phase 2 for Tier 2: [YYYY-MM-DD].
- **PA-JIT-02** Each elevation MUST record requester, role, scope, reason, linked ticket and approver.
- **PA-JIT-03** Elevation to Tier 0 MUST be approved by a second person who is not the requester.
- **PA-JIT-04** Privilege MUST be removed automatically at the end of the duration.
- **PA-JIT-05** Pre-approved elevations MAY be allowed for low-risk, repeated operational roles, with a monthly review of their use.

### 5.5 Privileged access workstations (PA-PAW)

- **PA-PAW-01** Tier 0 administration MUST be done only from dedicated, hardened privileged access workstations with no email, general web browsing or user software.
- **PA-PAW-02** Tier 1 administration MUST be done from a privileged access workstation or a hardened jump host reached from a managed device.
- **PA-PAW-03** Administrative interfaces of Tier 0 and Tier 1 systems MUST accept connections only from privileged access workstations or jump hosts (network restriction plus conditional access).

### 5.6 Service and workload accounts (PA-SVC)

- **PA-SVC-01** Every service account MUST have a named human owner, a purpose and an inventory record.
- **PA-SVC-02** Service accounts MUST NOT be used for interactive sign-in; interactive logon MUST be technically blocked where the platform allows.
- **PA-SVC-03** Credentials MUST NOT be embedded in code, scripts or images; they MUST come from the secrets manager or a platform workload identity.
- **PA-SVC-04** Static secrets for service accounts MUST be rotated at least every [90 days] and immediately after suspected exposure.
- **PA-SVC-05** Cloud workloads and CI/CD pipelines SHOULD use short-lived federated workload identities instead of long-lived keys.

### 5.7 Third-party access (PA-VEN)

- **PA-VEN-01** Third-party privileged access MUST be through the PAM platform with named individual accounts, never shared vendor accounts.
- **PA-VEN-02** Access MUST be time-boxed to the support window and approved by the system owner each time.
- **PA-VEN-03** All third-party privileged sessions MUST be recorded and MAY be monitored live for Tier 0 and Tier 1.
- **PA-VEN-04** Contracts MUST require the third party to notify [the organisation] of staff changes affecting access within [1 business day].

### 5.8 Monitoring (PA-MON)

- **PA-MON-01** Privileged sign-ins, elevations, role assignments, vault checkouts and break-glass use MUST be sent to the security monitoring platform in near real time.
- **PA-MON-02** The SOC MUST alert on: privileged use outside an approved elevation, Tier 0 sign-in from a non-PAW device, new privileged role assignments outside the workflow, and any break-glass sign-in.
- **PA-MON-03** Privileged activity logs MUST be protected from change by the administrators whose activity they record.

## 6. Just-in-time elevation workflow

<!-- Guidance: Show the standard elevation path end to end. The diagram must match PA-JIT-01 to PA-JIT-04. -->

The standard path below applies to every Tier 0 and Tier 1 elevation. The broker checks eligibility and the device before asking the system owner, requires fresh phishing-resistant authentication, grants the role for the approved duration (default 4 hours) and removes it automatically at expiry. Every step produces an event for the SOC.

```mermaid
sequenceDiagram
    participant A as Administrator
    participant B as Elevation broker
    participant O as System owner
    participant T as Target system
    participant S as SOC monitoring
    A->>B: Request role, scope, duration, ticket
    B->>B: Check tier, eligibility, PAW device
    B->>O: Approval request
    O-->>B: Approve
    B->>A: Re-authenticate with phishing-resistant MFA
    A-->>B: MFA completed
    B->>T: Grant role for 4 hours
    B->>S: Elevation event
    A->>T: Privileged session, recorded
    T->>S: Activity logs
    B->>T: Remove role at expiry
    B->>S: De-elevation event
```

## 7. Break-glass access

<!-- Guidance: Break-glass accounts exist for when the identity provider, MFA service or PAM platform is down. They are the most powerful and least used accounts, so the controls are about protection, alerting and testing. Pitfall: a break-glass account that depends on the very system whose failure it is meant to survive. -->

- **PA-BG-01** [Two] break-glass accounts per critical platform MUST exist, excluded from conditional access rules that would block them during an identity outage, but protected by phishing-resistant authenticators kept in [two separate physical safes].
- **PA-BG-02** Break-glass credentials MUST NOT depend on the systems they are meant to recover (for example a federated identity provider).
- **PA-BG-03** Any break-glass sign-in MUST raise an immediate high-priority alert to the SOC and the identity security lead.
- **PA-BG-04** After each use, credentials MUST be rotated and a post-use review completed within [2 business days], recording reason, actions taken and whether the use was justified.
- **PA-BG-05** Break-glass access MUST be tested at least [every six months], including the alert.

```mermaid
stateDiagram-v2
    [*] --> Sealed
    Sealed --> InUse: Declared emergency, two-person retrieval
    InUse --> Alerted: Sign-in event
    Alerted --> Reviewed: Post-use review within 2 business days
    Reviewed --> Rotated: Credentials rotated
    Rotated --> Sealed: Resealed and logged
    Sealed --> Tested: Six-monthly test
    Tested --> Rotated
```

## 8. Session management and recording

<!-- Guidance: Decide which sessions are recorded, what is captured, who can view recordings and how long they are kept. Recordings contain sensitive data; treat them as such. Check employee monitoring and privacy rules in each country before recording; this is not legal advice. -->

- **PA-SES-01** All interactive Tier 0 and Tier 1 sessions, and all third-party privileged sessions, MUST be brokered and recorded (keystrokes or commands for shell sessions, video or event capture for graphical sessions).
- **PA-SES-02** Privileged sessions MUST end automatically after [15 minutes] of inactivity and at the end of the elevation window.
- **PA-SES-03** Recordings MUST be retained for [12 months] and protected from change and deletion by recorded administrators.
- **PA-SES-04** Access to recordings MUST be limited to the SOC, internal audit and investigators, and each viewing logged.
- **PA-SES-05** A sample of [5%] of Tier 0 session recordings per month MUST be reviewed against the linked ticket.
- **PA-SES-06** Users MUST be told, before privileged sessions start, that sessions are recorded and why.

| Session type | Recorded | Live monitoring | Retention |
|---|---|---|---|
| Tier 0 interactive | Yes | Optional | [12 months] |
| Tier 1 interactive | Yes | No | [12 months] |
| Third-party privileged | Yes | Tier 0 and Tier 1: yes | [12 months] |
| API and automation (non-interactive) | Activity logs only | Alert-based | [Per logging standard] |

## 9. Periodic review and recertification

<!-- Guidance: Reviews remove privilege that is no longer needed. Make the reviewer the system owner, give them usage data, and track revocations to completion. Pitfall: rubber-stamping; a review where nothing is ever revoked is a sign the review is not working. -->

- **PA-REV-01** System owners MUST review all privileged eligibility and assignments for their systems at least [quarterly] for Tier 0 and Tier 1 and [every six months] for Tier 2.
- **PA-REV-02** The review MUST show last use date for each entitlement; entitlements unused in the period SHOULD be removed.
- **PA-REV-03** Revocations MUST be completed within [5 business days] of the review decision.
- **PA-REV-04** Service account inventories MUST be reviewed by their owners at least [every six months].

*Example* quarterly review: 412 privileged entitlements reviewed across Tier 0 and Tier 1; 37 revoked (9.0%), of which 29 had no use in 90 days; all revocations completed within 5 business days.

| Review ID | Scope | Reviewer | Entitlements | Revoked | Completed |
|---|---|---|---|---|---|
| PAR-2026-Q3-01 *(Example)* | Tier 0 and Tier 1 | System owners (24) | 412 | 37 | YYYY-MM-DD |

## 10. Metrics and reporting

<!-- Guidance: Report a small set of metrics monthly to the security leadership and quarterly to the risk committee. Show trend and target. Numbers below are illustrative. -->

| Metric | Definition | Target | *Example* value (quarter) |
|---|---|---|---|
| JIT coverage | Tier 0 and Tier 1 elevations through the broker / all privileged elevations | 100% | 1,178 / 1,240 = 95.0% |
| Standing privileged assignments | Tier 0 and Tier 1 roles assigned permanently to people | 0 (except break-glass) | 3 |
| Session recording coverage | Tier 0 and Tier 1 systems with recording enforced / all Tier 0 and Tier 1 systems | 100% | 312 / 330 = 94.5% |
| Phishing-resistant MFA coverage | Privileged identities with only phishing-resistant methods / all privileged identities | 100% | 46 / 52 = 88.5% |
| Review revocation rate | Entitlements revoked / entitlements reviewed | Tracked, not targeted | 37 / 412 = 9.0% |
| Break-glass uses | Count, with share reviewed in time | 100% reviewed | 2, both reviewed |

*Example* follow-up: 62 elevations bypassed the broker (1,240 minus 1,178) through legacy local administrator rights on 18 systems not yet onboarded to recording (330 minus 312); onboarding is tracked in the PAM roadmap.

## 11. Exceptions and non-compliance

<!-- Guidance: Systems that cannot meet a requirement (legacy, OT, vendor appliances) need a recorded exception with compensating controls and an end date. -->

- **PA-EXC-01** Any deviation MUST be requested through the [security exception request](../security/security-exception-request.md) process, stating requirement ID, reason, compensating controls and expiry (maximum [12 months]).
- **PA-EXC-02** Tier 0 exceptions MUST be approved by the CISO.
- **PA-EXC-03** Non-compliance found in audit or monitoring MUST be recorded and remediated; repeated or wilful misuse of privileged access is handled under [the disciplinary policy].

| Exception ID | Requirement | System | Compensating control | Expiry | Approved by |
|---|---|---|---|---|---|
| EXC-PAM-004 *(Example)* | PA-JIT-01 | Legacy billing server | Vaulted local admin password rotated after each use; session recorded through jump host | YYYY-MM-DD | [@ciso] |

## 12. Zero trust alignment

<!-- Guidance: Show how this standard applies the zero trust model, so architects can link it to the zero trust architecture document. -->

NIST SP 800-207 describes zero trust as removing implicit trust based on network location and making access decisions per request using identity, device and context. This standard applies those ideas to privileged access:

| Zero trust idea (own summary of SP 800-207) | Where it appears in this standard |
|---|---|
| Access granted per session, with least privilege | PA-JIT-01, PA-JIT-04, PA-LP-01 |
| Decisions use identity, device posture and context | PA-AUTH-01, PA-PAW-03, PA-JIT-01 (broker checks device) |
| Policy decision separated from enforcement (policy engine and administrator, policy enforcement point) | Elevation broker decides; target system and access proxy enforce (section 6) |
| No trust from network location alone | PA-PAW-03 combines network restriction with conditional access |
| Continuous monitoring of assets and activity | PA-MON-01 to PA-MON-03, PA-SES-01 |

## 13. Control mapping

<!-- Guidance: Map each requirement group to the control catalogue your organisation reports against. The list below uses NIST SP 800-53 Rev. 5 control and enhancement identifiers; add columns for ISO/IEC 27001:2022 Annex A, CIS Controls, PCI DSS or sector rules if you use them. -->

| Requirement group | NIST SP 800-53 Rev. 5 (release 5.2.0) |
|---|---|
| PA-ACC Account management | AC-2, AC-2(1), AC-2(3), AC-2(7), AC-2(9), AC-2(13) |
| PA-AUTH Authentication | IA-2, IA-2(1), IA-2(8), IA-5 |
| PA-LP Least privilege | AC-6, AC-6(1), AC-6(2), AC-6(5), AC-6(9), AC-6(10), AC-5 |
| PA-JIT Just-in-time elevation | AC-2(6), AC-6(1), AC-6(5) |
| PA-PAW Privileged access workstations | AC-6(3), AC-17, SC-7 |
| PA-SVC Service and workload accounts | AC-2, IA-5, IA-5(7) |
| PA-VEN Third-party access | AC-2, AC-17, AC-6(6) (this enhancement restricts privileged access by non-organisational users; record how named vendor staff are brought under organisational control) |
| PA-MON Monitoring | AC-2(4), AC-2(12), AC-6(9), AU-6, AU-9 |
| PA-BG Break-glass | AC-2(2) |
| PA-SES Session management and recording | AC-12, AU-14, AU-9 |
| PA-REV Periodic review | AC-2(3), AC-6(7) |
| PA-TIER Tier model | AC-6(4) separate processing domains; SC-7 |

Read each control in the official catalogue: identifiers are cited here, the control text is not reproduced, and baselines (low, moderate, high) differ in which enhancements they select.

## 14. Glossary and references

<!-- Guidance: Define terms that readers may not share and record exact versions. -->

| Term | Meaning |
|---|---|
| PAM | Privileged access management: the processes and tools that control privileged access |
| JIT | Just-in-time: privilege granted for a short, approved period instead of permanently |
| PAW | Privileged access workstation: hardened device used only for administration |
| Break-glass account | Emergency account for when normal access paths are unavailable |
| Tier 0 | Systems that control identity or the control plane of the whole estate |
| Phishing-resistant authenticator | Authenticator that binds the login to the real site or device, so a fake site cannot replay it (for example FIDO2) |
| Workload identity | Identity issued to software by a platform, usually with short-lived tokens |

| Reference | Version (as checked October 2026) | Official page |
|---|---|---|
| NIST SP 800-53 Rev. 5, Security and Privacy Controls | Rev. 5 with updates (Dec. 2020); catalogue release 5.2.0 (27 August 2025) | https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final |
| NIST SP 800-207, Zero Trust Architecture | August 2020 | https://csrc.nist.gov/pubs/sp/800/207/final |
| NIST SP 800-63B-4, Authentication and Authenticator Management | July 2025 | https://csrc.nist.gov/pubs/sp/800/63/b/4/final |
| NIST SP 800-53 OSCAL catalogue | 5.2.0 | https://github.com/usnistgov/oscal-content |

## Standard and licence note

Based on NIST Special Publication 800-53 Revision 5 (control catalogue
release 5.2.0), NIST SP 800-207 and NIST SP 800-63B-4, which are works of
the US government and not subject to copyright in the United States.
Control and enhancement identifiers are cited for mapping; the
requirements, tier model description, workflows and examples are original
and written for this collection. Check the current official versions at
csrc.nist.gov before relying on the mapping, and check any law or
regulation that applies to you in its current official text with a
qualified professional; this template is not legal advice. Template
licence: MIT.