A.8.2
Privileged access rights
Technological controlsCheckpoints 5Evidence 6Cases 6
Control objective
Privileged access rights (administrator, root, system/DB administrator privileges, and so on) can cause organization-wide damage if misused or stolen, so this control requires granting them to as few people as necessary and controlling their use strictly. It aims to manage the full lifecycle of privileged accounts (grant, use, review, revocation), keep them separate from ordinary work accounts, and thereby reduce the risk of misuse and compromise while preserving accountability for privileged activity.
Key checkpoints
- Are criteria and an approval process for granting privileged access rights defined, with grants based on least privilege and need-to-use?
- Are privileged accounts separated from ordinary user accounts and individually identifiable, and is the use of shared/default administrator accounts controlled?
- Is stronger authentication (such as multi-factor authentication) applied to privileged access, and are session/time limits or just-in-time grants considered?
- Is privileged account activity logged/retained and reviewed periodically, and are holdings reviewed on a regular cycle so unnecessary rights are revoked?
- Are privileged credentials (administrator passwords, SSH keys, and so on) stored/rotated securely, and are privileged rights granted to external/outsourced personnel managed separately?
Implementation guidance
- Define a list of privileged right types/roles, process grants only with documented approval and an expiry (time limit), and minimize standing privileges.
- Use individually identifiable privileged accounts, minimize shared administrator account use, and where unavoidable ensure use is logged and attributable to a responsible person.
- Apply hardening measures to privileged access, such as multi-factor authentication, access via bastion/jump hosts, session recording, and privileged access management (PAM) solutions.
- Grant privileges only when needed through just-in-time elevation, and revoke them automatically once the task is complete.
- Protect privileged credentials in secure storage and replace them according to type, compromise risk, and applicable obligations. Disable unnecessary default accounts and replace default secrets. Renaming an account does not replace changing default passwords or restricting access.
- Adjust privileged rights immediately on transfer/termination/role change, and link with periodic access reviews (A.5.18) to check for excessive grants.
- Retain privileged activity logs separately and link them with logging/monitoring (A.8.15, A.8.16) to detect anomalous behavior.
Evidence
- Privileged access request forms and approval/change history
- Privileged account inventory and holdings (account, scope of rights, reason for grant, expiry date)
- Authentication configuration for privileged access (multi-factor authentication) and PAM/bastion policy screens
- Privileged account activity logs and periodic review records
- Privileged credential storage/rotation history and evidence of default-account disablement
- Periodic access review results and records of revoking unnecessary rights
Nonconformity examples
- Privileged rights are used without approval or a documented basis, or no expiry/revocation procedure exists.
- Multiple administrators share a common root/administrator account, so individual actions cannot be traced.
- Multi-factor authentication is not applied to privileged access, so a simple password alone grants access.
- Privileged account activity is not logged, or logs are collected but never reviewed.
- Privileged rights of leavers/role-changers are not revoked and remain active.
- Default administrator passwords remain unchanged or unnecessary default administrative access remains enabled.