Privileged access is the control that decides how bad everything else can get. An ordinary user who is phished can lose their own mailbox; an administrator who is phished loses the company. That asymmetry is why privileged access has its own guide, its own tooling market and its own line in every cyber insurance questionnaire, and it is also why the typical state of affairs is so hard to explain to an audit committee: eleven people reading email with domain-administrator tokens, a backup console reachable with the same credentials, four finance staff sharing an ERP superuser login, a database administrator who can update the settlement tables from a query window, and thirty-eight service accounts whose passwords have never been changed because nobody knows what would break. None of these is exotic. They are the normal accumulation of an organization that grew faster than its identity discipline, and the audit’s job is to make the accumulation visible and countable.
This guide was rewritten in September 2026 and expanded from the original August 2026 version. It defines privilege by capability across every layer rather than by job title, gives the inventory-completeness method that has to come before any control is tested, sets out the nine controls with their evidence and failure modes, treats vaulting, break-glass, service accounts and cloud administrative roles in depth, covers the detective side, watching the watchers, gives an eleven-test program, and finishes with a worked example at MidState Beverage, where the privileged access workstream of an ERP access engagement found the eleven domain administrators and the shared superuser login. It sits between the identity and access management program audit, where privileged access is one of seven domains, and the Active Directory and Entra ID audit, which goes into the directory-specific depth.
In this guide
- What counts as privileged: capability, not title, across every layer
- Inventory completeness: the test that comes first
- The nine controls, their evidence and their failure modes
- Just-in-time elevation: from standing rights to eligibility
- The vault: coverage, check-out, rotation and session recording
- Break-glass: the exception that must be alerted, sealed and reviewed
- The service-account swamp
- Cloud administrative roles
- Watching the watchers: logging, review and the DBA problem
- The metrics a privileged access program should report
- Evaluating privileged access findings: severity by path
- The eleven-test program
- Worked example: MidState Beverage’s eleven domain administrators
- Common mistakes
What counts as privileged: capability, not title, across every layer
An account is privileged if it can change the security of a system, the configuration that other controls depend on, or the data that the application’s own controls are meant to protect, or if it can read everything. That definition is about capability and it cuts across job titles: the help-desk analyst with password-reset rights over executives, the finance manager with the ERP superuser role, the developer with production database credentials, and the marketing contractor who is a tenant administrator of the web platform are all privileged, and none of them appears on a list of “IT admins.” The definition also cuts across layers, and the audit’s first job is to enumerate the layers, because privilege at any one of them undermines the controls at the layers above. The table gives the layers, the typical privileged accounts at each, and where the population is extracted from.
| Layer | Privileged accounts | Where the population comes from | What they can do |
|---|---|---|---|
| Identity directory | Domain, enterprise and schema administrators; operator groups; Entra global and privileged roles; the synchronization account | Directory group and role extracts with nesting expanded | Become anyone; change any control |
| Servers and operating systems | Local administrators; root; sudo rights; remote management rights | Local group membership across the estate (LAPS and management tools); sudoers files; configuration management | Read and alter anything on the host, including application data and logs |
| Databases | Database administrators; application schema owners; accounts with direct data manipulation rights | Database role and grant extracts per instance | Change financial data outside the application’s controls |
| Applications | Superusers; security administrators; configuration administrators; emergency and firefighter roles | Application role extracts (see the SoD analysis) | Alter configuration, roles and master data; approve anything |
| Network and security infrastructure | Firewall, switch and VPN administrators; security tool administrators | Device and console user lists | Open paths; disable monitoring |
| Virtualization and cloud platforms | Hypervisor administrators; cloud account root and owner roles; organization-level administrators | Platform role assignments across all accounts and subscriptions | Copy, alter or destroy entire systems |
| Backup and recovery | Backup console administrators; storage administrators | Backup platform user lists | Delete the last copy (see the backup guide) |
| Development and deployment | Repository owners; pipeline administrators; secrets managers | Repository and pipeline permission extracts | Change what runs in production (see the change management guide) |
| SaaS and third-party consoles | Tenant administrators of every SaaS platform; vendor support accounts | Each console’s administrator list; vendor access registers | Alter the platform’s configuration and export its data |
Inventory completeness: the test that comes first
Every privileged access control operates on the accounts the organization knows about, so the audit begins by finding the ones it does not. The method is the same reconciliation used throughout this site’s IT guides: for each layer, extract the privileged population from the platform itself, with the administrator performing the extraction and the auditor observing and re-counting, and compare it with the organization’s privileged access inventory, which is usually the vault’s account list or a spreadsheet held by security. The differences are the finding before any control is tested: local administrators on servers that the vault has never heard of, database accounts with data-manipulation rights that the application team created for an interface, cloud subscriptions with owners nobody in security knows, SaaS consoles where the person who bought the product is still the only administrator. The reconciled inventory is then the population for everything that follows, and its size is usually two to four times the number in the vault. A privileged access management program whose vault covers 60 percent of the real population is protecting the 60 percent an attacker will not bother with.
The nine controls, their evidence and their failure modes
Nine controls make up a privileged access program. They are ordered from the structural to the detective, and the structural ones carry the most weight: an organization that has separated administrative accounts from daily-use identities and put them behind phishing-resistant multi-factor authentication has removed the mechanism of most compromises, whatever the state of its session recording. The table gives each control, its evidence and the way it typically fails; the sections that follow go deeper into the four that need it.
| # | Control | Evidence | Typical failure |
|---|---|---|---|
| 1 | Separate administrative accounts, never used for email, browsing or ordinary work; privileged access from dedicated workstations for the control plane | Account pairs; logon history by machine; workstation policy | Daily-use accounts in administrator groups |
| 2 | Phishing-resistant multi-factor authentication for every privileged account | Authentication method per account; enforcement policy | Administrators on one-time codes or password only |
| 3 | Least privilege: scoped roles instead of global ones; time-bound and just-in-time elevation | Role assignments; PIM or equivalent configuration; standing versus eligible counts | Standing global rights for convenience |
| 4 | Vaulting: privileged credentials held in a vault, checked out for a purpose, rotated after use, sessions recorded | Vault coverage against the reconciled inventory; check-out records; rotation logs; recordings | Vault covers a fraction; credentials known outside the vault |
| 5 | Break-glass accounts sealed, alerted on use, and reviewed after every use | Account list; seal and storage; alerting; use log with reviews | Break-glass used as a routine admin login |
| 6 | Service and non-human accounts inventoried, owned, denied interactive logon, credentials rotated by the vault or platform | Inventory; owner; logon-type logs; rotation records | Passwords never expire; interactive use; credentials in scripts |
| 7 | Cloud administrative roles: root and owner accounts locked and alerted; organization-level guardrails; MFA; key rotation | Root account status; role assignments across accounts; policy configuration | Root credentials in use; owners on every subscription |
| 8 | Vendor and remote privileged access through a brokered, time-limited, recorded channel | Vendor access register; broker configuration; session records | Standing VPN accounts with administrator rights for vendors |
| 9 | Logging of privileged activity, alerting on privileged changes, and periodic review of sessions and privileged commands | Log sources; detection rules; review records | No review; logs retained thirty days; database activity unlogged |
Just-in-time elevation: from standing rights to eligibility
The single structural change that most reduces privileged exposure is converting standing privilege into eligibility. Under a just-in-time model, an administrator holds no privileged role at rest; they are eligible for one, and they activate it for a bounded period, with a reason, sometimes with an approval, and the activation is logged and expires. The attacker who compromises an eligible account gets nothing until they can also pass the activation gate, which in a well-configured system requires phishing-resistant authentication. Cloud directories offer the mechanism natively, Privileged Identity Management in Entra ID for instance, and vaults offer it for on-premises accounts through time-limited check-out. The audit measures the transition with a simple ratio per platform: standing privileged assignments divided by total privileged assignments, with the target approaching zero for the highest roles and the residual justified individually. The table gives the measurement.
| Platform | Standing assignments | Eligible assignments | Activation controls | What the audit asks |
|---|---|---|---|---|
| Entra ID privileged roles | Permanent role members | PIM-eligible members | MFA on activation; justification; approval for the highest roles; maximum duration; alerts | Why does each permanent member exist; are activations reviewed |
| Active Directory administrator groups | Group members at rest | Accounts added by the vault or a privileged access workflow for a window | Vault check-out with purpose and expiry; group membership cleared on expiry | Is the group empty between changes; who can add members outside the workflow |
| Cloud platform roles | Permanent owner and administrator assignments | Eligible assignments through the platform’s just-in-time feature or an access broker | MFA; approval; duration; session logging | How many permanent owners per account and why |
| Databases and applications | Accounts with standing DBA or superuser rights | Firefighter or emergency roles granted for a window with log review | Approval; log capture; post-use review | Is every use reviewed; how often is the emergency role used |
The vault: coverage, check-out, rotation and session recording
A privileged access management vault holds the credentials of privileged accounts so that nobody knows them, releases them, or brokers a session with them, when an authorized person checks them out for a stated purpose, rotates them after the session so that the released value is useless, and records what was done. Four properties make a vault a control rather than a password store, and the audit tests each. Coverage: the proportion of the reconciled privileged inventory whose credentials are in the vault and managed by it, layer by layer; the unvaulted remainder is the exposure. Check-out discipline: every check-out has a requester, a purpose, an approval where the policy requires one, and a duration, and a sample of check-outs traces to a ticket or a change; check-outs with the purpose “admin work” by the same person every day mean the vault has become a login page. Rotation: credentials rotated after each check-out or on a short cycle, evidenced by the vault’s own log, so that a credential captured during a session expires with it; a vault that manages credentials without rotating them has centralized the exposure. And session recording: privileged sessions recorded and retained, with a review process that actually samples them, because recordings nobody watches are storage. The vault itself is tier-zero infrastructure with its own administrators, who are the most privileged people in the organization; their number, authentication and activity are tested with the same rigor, and the vault’s backup and recovery are tested so that a ransomware event does not lock the organization out of every credential it owns.
Break-glass: the exception that must be alerted, sealed and reviewed
Break-glass accounts exist for the moment the normal path fails: the identity provider is down, the vault is unreachable, the last administrator is locked out, the ransomware has encrypted the management plane. They hold standing high privilege by design, which is why every other control is applied to them at maximum strength. The audit tests that they exist (Microsoft’s guidance for Entra ID is two cloud-only accounts permanently holding Global Administrator, and the equivalent applies to each platform), that they are excluded from the conditional access and vault policies that would block them in the scenario they exist for, that their credentials are sealed, physically or in a separate vault with dual control, and not known to any individual, that any use generates an alert to the security function within minutes, that every use is reviewed afterward and recorded, and that they are tested periodically, because a break-glass account that has never been logged into is an assumption. The count of uses in the period is the metric: zero or a handful with reviews is healthy; weekly use means an administrator has adopted the break-glass account as a convenient way around the vault, which is the failure mode the directory audit worked example illustrates in the other direction, with emergency accounts that would not have worked at all.
The service-account swamp
Service accounts run applications, interfaces, scheduled jobs, monitoring agents and backup software, and in most organizations they outnumber human privileged accounts and are controlled less. The characteristic conditions are passwords set never to expire because rotation would break something nobody understands, credentials embedded in scripts and configuration files that any administrator can read, interactive logon possible with an account whose password four people know, membership in administrator groups because the vendor’s installation guide said so in 2014, and no owner. The audit tests the inventory against the platforms, as the IAM guide describes, then tests four controls: every service account has a named owner and a stated purpose; interactive logon is denied where the platform allows and monitored where it does not; credentials are managed by the vault or by platform mechanisms such as group managed service accounts and rotated on a schedule; and privilege is the minimum the service needs, with membership in administrator groups justified individually. The finding that recurs is the interface or backup account in Domain Admins with a decade-old password that appears in a script on a shared drive, and it is rated as what it is: a standing, unmonitored, widely known administrator credential.
Cloud administrative roles
Cloud platforms concentrate privilege in ways on-premises estates never did: a single root or owner identity can create, copy, alter or delete every system in an account, and an organization-level administrator can do it across every account. The controls are specific to the model and the audit tests them by reading the platform’s own configuration. The root or account-owner credentials are locked away, protected by hardware multi-factor authentication, never used for daily work, and alerted on use. Administrative roles are assigned at the narrowest scope, subscription or account rather than organization, and through just-in-time elevation where the platform offers it. Organization-level guardrails, service control policies and management-group policies, constrain what even administrators can do, such as disabling logging or creating resources in unapproved regions. Long-lived access keys for human users are eliminated in favor of federated, short-lived credentials, and the age of any remaining keys is a metric. Workload identities are used for automation instead of human credentials, which is also what Microsoft’s mandatory multi-factor enforcement for administrative tools now pushes organizations toward. The cloud audit guide covers the platform specifics; the population for this audit is the set of identities holding administrative roles across every account and subscription, reconciled to the inventory, which is where the unknown subscriptions and the contractor-created owner roles appear.
Watching the watchers: logging, review and the DBA problem
Preventive controls over privilege fail eventually, and the detective layer decides whether the failure is noticed. The audit tests that privileged activity is logged at every layer, that the logs go somewhere the administrators cannot alter them, that specific detections exist for the events that matter, privileged group and role changes, break-glass use, vault bypasses, administrative logons from unexpected places, and that someone reviews privileged sessions and commands on a cycle, with a record. Database administration is the hardest case and the one most relevant to financial reporting. A database administrator can update any table in the ERP’s database directly, bypassing every application control, workflow and audit trail; the change management audit finds these as unticketed data changes, and the privileged access audit finds their cause. The controls are direct-access restriction (application accounts only for application schemas, DBA access through the vault with recording), database activity monitoring or native auditing of data-manipulation statements against financial tables with retention, and periodic review of that log by someone outside the database team. An organization that cannot list the direct changes made to its ledger tables in the last quarter does not know whether its financial data has been altered, and that sentence belongs in the report exactly as written.
The metrics a privileged access program should report
A program that cannot report on itself is not being managed, and the audit both computes the metrics from the extracts and tests whether management reports them. Eight numbers cover the program: the reconciled privileged inventory by layer and its growth; vault coverage as a percentage of that inventory; the standing-to-eligible ratio for the highest roles; the proportion of privileged accounts on phishing-resistant authentication; the count of daily-use accounts holding privilege, which should be zero; break-glass uses in the period with the proportion reviewed; service accounts with never-expiring or interactive credentials; and privileged sessions reviewed as a proportion of sessions recorded. Reported quarterly with a trend, they show a program moving in the right direction or not, and they are the numbers the audit committee can understand without a technical briefing: “fourteen people can still become anyone; last quarter it was twenty-six” is a sentence a board remembers. The audit’s contribution is to compute them independently once a year and compare them with what management reported, which is the same reconciliation discipline the vulnerability management audit applies to its dashboard.
Evaluating privileged access findings: severity by path
Privileged access findings are rated by the path they open rather than by the count of accounts involved, and the report should say so explicitly, because the audit committee will otherwise read “eleven domain administrators” as an untidiness rather than as the mechanism by which a single phishing email becomes a company-wide encryption event. The evaluation asks, for each finding, what an attacker who exploited it could reach and what the organization would lose: a daily-use account in the domain administrator group opens a path to everything; a shared application superuser opens a path to unattributable changes in the financial system; an unlogged database account opens a path to altered financial data with no trace; a contractor owner on a cloud subscription opens a path to the copying or destruction of whatever that subscription holds. The directory audit’s attack-path table supplies the reasoning for the identity layer, and the deficiency evaluation framework the structure for connecting the path to a financial reporting consequence where one exists. Findings that share a path, unvaulted credentials and no separation and one-time-code authentication, are rated together as the single exposure they are, and the recommendation is the sequence that closes the path fastest rather than the list of controls the framework names.
The eleven-test program
The program covers the nine controls across every layer for a period. Populations are extracts, handled as information produced by the entity; most tests run over full populations, and samples follow the standard sizes. The privileged access review that management performs, tested in the user access review guide, is one of the controls tested here rather than a substitute for the program.
| # | Test | Population | Evidence | What a failure looks like |
|---|---|---|---|---|
| 1 | Reconcile the privileged inventory to platform extracts at every layer | All layers | Extracts; inventory; reconciliation | Unknown privileged accounts; whole layers absent from the inventory |
| 2 | Test account separation and workstation controls | All human privileged accounts | Account pairs; logon history; workstation policy | Daily-use accounts with privilege |
| 3 | Test authentication strength for privileged accounts | All privileged accounts | Method per account; enforcement policy | Password-only or one-time codes for administrators |
| 4 | Test least privilege and just-in-time elevation | Role assignments per platform | Standing versus eligible; scope; justification | Standing global rights |
| 5 | Test vault coverage, check-out, rotation and recording | Reconciled inventory; check-outs in the period (sample of 40) | Coverage percentage; check-out records traced to tickets; rotation log; recordings and reviews | Low coverage; purposeless check-outs; no rotation; unreviewed recordings |
| 6 | Test break-glass accounts | All break-glass accounts; uses in the period | Seals, exclusions, alerts, use reviews, periodic tests | Untested; routinely used; blocked by policy |
| 7 | Test service and non-human accounts | All service accounts | Owner, purpose, logon type, rotation, privilege | Never-expiring, interactive, over-privileged, unowned |
| 8 | Test cloud administrative roles and root accounts | All accounts and subscriptions | Root status; role assignments; guardrails; key age | Root in use; owners everywhere; keys years old |
| 9 | Test vendor and remote privileged access | Vendor access register; remote access configuration | Brokered channel; time limits; recordings | Standing vendor administrator accounts over VPN |
| 10 | Test database direct-access controls and activity logging | Database accounts with data manipulation rights; DML audit for financial tables | Grants; vault routing; audit configuration; review records | DBAs updating financial tables unlogged |
| 11 | Test logging, detections and review of privileged activity | Log sources; detection rules; reviews in the period | Rule inventory; alert handling; review records | No detections for privileged changes; no review |
Worked example: MidState Beverage’s eleven domain administrators
MidState Beverage, the three-state drinks distributor with twelve depots, a 2013 ERP and a six-person audit function that appears throughout this site’s IT guides, tested privileged access as the third workstream of its FY27 ERP user access engagement, alongside the segregation of duties analysis and the rebuilt access review, with the co-sourced ERP security specialist covering the application and database layers and the analytics and IT auditor the rest. The company had no privileged access management tool and a privileged inventory consisting of the IT manager’s knowledge.
The reconciliation across layers produced 71 privileged accounts against the 19 the IT manager had named. The directory held eleven accounts in the domain administrator group, all daily-use identities that read email and browsed the web, including the IT manager’s, two depot administrators’ and the managed-service provider’s shared account; the backup console was administered through the same group, as the backup audit had found. The ERP had four superuser accounts, one of them a shared login whose password four finance staff knew and used for month-end adjustments, and the route-accounting module’s own administrator role held by the head of route accounting and the developer. The database had three accounts with data-manipulation rights on the settlement tables, one belonging to the route-accounting analyst, whose six direct table updates the change management test had already found. The two cloud subscriptions nobody in finance had known about had six owners between them, four of them former project contractors. The 38 service accounts included 14 with never-expiring passwords and 6 capable of interactive logon, and the interface account’s password was written in a shared spreadsheet. No account at any layer used phishing-resistant authentication; the domain administrators used the same one-time-code method as everyone else. There were no break-glass accounts; the IT manager’s daily account was the recovery plan. Database activity was not logged.
| Layer | Inventory said | Reconciliation found | Finding |
|---|---|---|---|
| Directory | 4 administrators | 11 in the domain administrator group, all daily-use, including a vendor’s shared account; backup console in the group | Standing privilege, no separation, no vault (High) |
| ERP and route module | 2 superusers | 4 superusers including a shared finance login; 2 module administrators including the developer | Shared privileged credentials; developer with production administration (High) |
| Database | 1 DBA (the provider) | 3 accounts with data manipulation on settlement tables; no activity logging | Direct data access unlogged (High, tied to the change finding) |
| Cloud subscriptions | Unknown to finance | 6 owners, 4 former contractors | Cloud privilege ungoverned (Medium) |
| Service accounts | 12 | 38; 14 never-expiring; 6 interactive; interface password in a spreadsheet | Service account governance (Medium) |
| Authentication and break-glass | Not considered | No phishing-resistant MFA for any administrator; no break-glass accounts | Privileged authentication and recovery (Medium) |
The report’s recommendation was a sequence rather than a list, because the company could not do everything at once with a three-person IT team. First month: separate administrative accounts for the eleven, with hardware-key authentication, and removal of the vendor’s shared account in favor of a brokered channel; two sealed break-glass accounts; the shared ERP superuser login retired and replaced with individual accounts and the month-end adjustment moved into an approved workflow. First quarter: a vault covering the reconciled inventory, starting with the directory, database and backup accounts, with rotation and recording; database activity logging on the settlement and ledger tables with a monthly review by the controller’s team; the four contractor owners removed from the cloud subscriptions. Second quarter: service account remediation, starting with the six interactive accounts and the fourteen never-expiring passwords. The CAE reported to the audit committee that the eleven daily-use domain administrators meant that eleven ordinary phishing successes had each been a complete compromise for as long as anyone could remember, and that the first-month actions closed that exposure at a cost of about fifteen hundred dollars in hardware keys. The workstream used 130 hours, 45 of them the specialist’s.
Common mistakes
- Defining privilege by job title. Capability across every layer; the finance superuser and the DBA are privileged.
- Testing the vault’s list. Reconcile every layer to the platform extracts first; the unvaulted accounts are the exposure.
- Treating multi-factor as done. Administrators need phishing-resistant methods, and the side-door paths need closing.
- Accepting daily-use accounts with privilege. Separation is the control that removes the mechanism of most compromises; rate its absence accordingly.
- Counting a vault as a control without rotation and review. Coverage, check-out purpose, rotation and reviewed recordings are the four properties.
- Ignoring break-glass, or finding it used weekly. Sealed, alerted, reviewed, tested, rare.
- Leaving service accounts to next year. They outnumber the humans and hold the oldest credentials.
- Auditing cloud privilege per subscription. Extract across every account and organization level; the unknown subscription has the contractor owner.
- Forgetting the database. Direct data manipulation unlogged means the ledger could have been altered and nobody would know.
- Writing a list instead of a sequence. Small teams need the first-month actions that close the biggest exposure, then the rest.
Related guides
- How to audit identity and access management
- How to audit Active Directory and Entra ID
- How to perform a user access review
- How to run an ERP segregation of duties analysis
- How to audit IT change management
- How to audit backups and recovery
- Auditing cloud computing
- How to audit incident response
- SOX ITGC scoping
- IPE: testing information produced by the entity
- IT general controls: the complete primer
- Building the IT audit plan
- IT & Cybersecurity Audit guides
Leave a Reply