Privileged Access Standard Template (PAM, NIST SP 800-53)

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.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and applicability
2. Roles and responsibilities
3. Privileged account types
4. Administrative tier model
5. Mandatory requirements
6. Just-in-time elevation workflow
7. Break-glass access
8. Session management and recording
9. Periodic review and recertification
10. Metrics and reporting
11. Exceptions and non-compliance
12. Zero trust alignment
13. Control mapping
14. Glossary and references

1. Purpose, scope and applicability

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

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

3. Privileged account types

4. Administrative tier model

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

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

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.

7. Break-glass access

• 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.

8. Session management and recording

• 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.

9. Periodic review and recertification

• 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.

10. Metrics and reporting

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

• PA-EXC-01 Any deviation MUST be requested through the security exception request 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].

12. Zero trust alignment

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:

13. Control mapping

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

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.