Privileged Access Policy Template

A privileged access policy defines which accounts can change security settings, reach sensitive data in bulk or control other identities, and sets stricter rules for them than for everyone else: separate accounts, access only when needed, vaulted credentials, recorded sessions and frequent review. Most large identity breaches end with an attacker holding one of these accounts, so this is the policy that does the most to limit damage. This template follows ISO/IEC 27001:2022 Annex A 8.2 Privileged access rights and the NIST SP 800-53 Rev. 5 AC-6 Least Privilege family, with break-glass rules drawn from Microsoft's emergency access guidance.

How to use this template

1. Build the privileged inventory (section 2) before writing rules. You cannot apply a rule to accounts you have not found.
2. Decide for each privileged role whether it can be just-in-time (section 4). Record the ones that must stay standing and why.
3. Fill the [bracketed fields]. The values shown in brackets are suggested starting points, not standards.
4. Adopt it under your IAM policy, section 4.4.

Owner: [ ] | Approved: [date] | Review: every [12] months

1. Definitions

• Privileged access: any access that can change security configuration, create or modify other identities or their permissions, read or export sensitive data in bulk, or bypass normal controls. See PAM.
• Tier 0: systems that control identity itself: the identity provider, directory (Active Directory domain controllers), federation servers, PKI, PAM and secrets vaults, cloud organization root and management accounts, and CI/CD systems that can deploy to them.
• Standing privilege: privileged rights held permanently whether used or not (standing privilege).
• Just-in-time (JIT): privileged rights granted for a limited time on request and removed automatically (JIT access).
• Break-glass account: an emergency account used only when normal administrative access fails (break glass).

2. Privileged inventory

Guidance: include SaaS admin roles (email, CRM, HR, code hosting), not only infrastructure. Include service accounts with admin rights; the Cloudflare intrusion used service account credentials that had not been rotated.

3. Account rules

1. Privileged tasks must be performed with a dedicated admin account that has no mailbox, no web browsing and no everyday access. (NIST AC-6(2) Non-privileged Access for Nonsecurity Functions)
2. Admin accounts must be individual. Shared privileged accounts are allowed only where the system offers nothing else, must be vaulted, and checkout must be logged to a named person. (NIST AC-2(k) changing shared authenticators when members leave)
3. Tier 0 admin accounts must be cloud-only or directory-only as appropriate, and must not be synchronized from a lower-tier directory. [Adjust to your architecture]
4. Admin accounts must use phishing-resistant MFA (device-bound keys or smart cards; see the MFA standard). (NIST IA-2(1); ISO 8.5)
5. Privileged roles may be held only by [employees / named contractors with approval from ...]. (NIST AC-6(5) Privileged Accounts)

4. Standing versus just-in-time access

Rules:

1. JIT is the default for every privileged role the platform supports. (NIST AC-2(2) Automated Temporary and Emergency Account Management)
2. Target standing privileged human accounts: [number] by [date]. Report the count monthly; it should fall.
3. Approvers must not approve their own requests, and approval for tier 0 needs [a second admin / security].

Guidance: see the zero standing privileges rollout and zero standing privileges. Watch the PIM lockout case Microsoft describes: if every Global Administrator assignment is eligible and approval is required with no active approver, nobody can approve activation. Break-glass accounts (section 7) prevent this.

5. Credential vaulting and rotation

1. Passwords and keys for shared, local admin, root and privileged service accounts must be stored in [PAM vault / secrets manager], not in documents, chat or personal password managers.
2. Vaulted credentials must rotate after each checkout for tier 0, and at least every [90 days] otherwise, and immediately when someone with access leaves.
3. Local administrator passwords on endpoints and servers must be unique per machine and rotated automatically ([Windows LAPS or equivalent]).
4. Privileged secrets must never be embedded in scripts or code. (NIST IA-5(7) No Embedded Unencrypted Static Authenticators)

6. Sessions, workstations and monitoring

1. Tier 0 administration must be performed from a privileged access workstation or [hardened jump host]. (Microsoft's emergency access guidance also requires a designated secure workstation for break-glass use.)
2. Privileged sessions to [tier 0 servers, databases, network devices] must be brokered and recorded (session recording). Recordings are retained [__ days] and reviewed when an alert fires or on sample.
3. Use of privileged functions must be logged and sent to [SIEM]. (NIST AC-6(9) Log Use of Privileged Functions)
4. Alerts must fire on: new privileged role assignment, activation outside [hours], MFA method change on an admin account, and any break-glass sign-in.
5. Vendor and support access to privileged functions follows the third-party access policy and is always JIT and recorded.

7. Break-glass (emergency access) accounts

Based on Microsoft's emergency access account guidance; apply the same principles to other IdPs and to on-premises directories.

• At least two emergency access accounts per tenant or directory.
• Cloud-only (no dependency on federation or on-premises sync), for example on the tenant's onmicrosoft.com domain.
• Phishing-resistant authentication (FIDO2 security key or certificate-based authentication) that is different from the methods normal admins use.
• Not tied to any individual's phone or personal device.
• Credentials and keys stored in separate, secure locations known only to authorized people. Safe combinations changed when someone with access leaves.
• Role assignment is permanent active, not eligible, so activation cannot be blocked.
• Excluded from conditional access policies that block or restrict sign-in (report-only policies do not need the exclusion). Recorded in the conditional access exclusions register.
• Credentials do not expire and are not removed by inactive-account cleanup.
• Every sign-in raises a critical alert to [on-call and security leadership].
• Every use is reviewed afterwards: drill, real emergency, or misuse.
• Validated at least every 90 days, and after admin staff changes: sign in, perform an admin task, confirm the alert fired, review the authorized list.
• Separate break-glass accounts for on-premises and cloud, with no dependency of one on the other.

8. Reviews

1. Privileged access must be reviewed every [3] months by the system owner and security. (NIST AC-6(7) Review of User Privileges; ISO 8.2)
2. Each review must confirm: the holder still needs the role, JIT could replace standing access, MFA method is phishing-resistant, and the account has been used (unused privileged accounts are removed).
3. Evidence (reviewer, date, decisions, removals) is kept [__ years].

9. Exceptions

Exceptions follow the IAM policy process, are limited to [3 months] for tier 0, and always name a compensating control.

Control mapping

Why this matters

• At MGM Resorts, a help desk call led to control of Okta super administrator accounts. Phishing-resistant MFA and a hardened reset path for admins (section 3 and the MFA standard) target exactly that.
• In the Okta customer help desk super admin takeovers, attackers persuaded service desks to reset all MFA factors on super administrator accounts, then changed authentication policies and added a second identity provider so they could sign in as anyone. JIT access with approval, alerts on admin MFA changes and a two-person reset rule for tier 0 each break that chain.

Related

• Implementing privileged access management
• What is PAM
• How to choose a PAM solution
• PAM vendors such as Idira (formerly CyberArk, now part of Palo Alto Networks), BeyondTrust and Delinea, and access-broker tools such as Teleport and StrongDM (acquired by Delinea in March 2026)
• Kerberoasting and ADCS certificate template abuse (common tier 0 escalation paths)