Make privileged authority temporary, narrow, and attributable

Privileged access management controls identities and sessions able to administer security, infrastructure, data, applications, identity systems, or the PAM platform itself. The central design goal is to minimize standing privilege: ordinary work happens under a standard identity, while exceptional authority is activated only for an approved purpose, tightly scoped, strongly authenticated, observed, and automatically removed. A permanent administrator role protected by a vault is still standing privilege.

What interviewers probe first

Interviewers usually open with "what counts as privileged in your environment?" A candidate who answers "admin accounts" has not done the work. The full population is:

• Domain and Tier-0 administrators — forest/tenant admins, directory and federation admins, identity-system operators.
• Break-glass and emergency accounts.
• Service and application accounts, including embedded credentials in scripts and CI jobs.
• Shared and team accounts on databases, network gear, and out-of-band consoles.
• Cloud roles: Entra PIM eligible roles, AWS IAM roles, GCP service accounts.
• Vendor and third-party access.

The follow-up is almost always "how did you find them all?" Discovery — scanning direct grants, nested groups, local accounts, shared credentials, API keys, inherited roles, and alternate recovery paths — is a pillar in its own right. An inventory that lists humans and omits CI roles is not an inventory of privilege. A weak answer names a vault product and stops there; a strong answer walks from discovery to onboarding to rotation of the unmanaged accounts the discovery surfaced.

Assign every privilege an owner, purpose, eligible population, maximum duration, review cadence, and retirement condition. If you cannot say who owns a grant and when it dies, it is standing privilege regardless of what tool stores it.

The pillars, and which threat each one answers

Reason about which control answers which threat; listing all four as "best practice" is the weak answer.

• Vaulting with check-out/check-in and automatic rotation answers credential theft and credential sharing. It does not answer over-broad authority: a vaulted permanent superuser is still a permanent superuser.
• Session brokering and recording via a PAM proxy answers credential exposure and attribution. The password is never revealed to the human; the session is bound to an approved grant and target, and commands are recorded. It does not by itself prevent a dangerous command — recording is evidence, not prevention.
• JIT / zero standing privilege elevation answers standing authority. Time-bound, approval-bound activation shrinks the window from "forever" to "the approved task." It does not answer scope: a 30-minute window with full superuser is still too much if the task needs one table.
• Discovery, onboarding, rotation answers the unknown-privilege problem. You cannot protect grants you have not found.

Checking a password out of a vault and pasting it into an unmanaged session is standing privilege with a receipt — the vault logged it, but nothing constrained the session.

Separation of duties and the tiered administration model

Separate daily and privileged identities so email, browsing, and collaboration compromise does not automatically yield administrative authority. Interviewers probe the tiered model here: Tier 0 (identity, PAM, domain controllers, PKI), Tier 1 (servers, applications), Tier 2 (workstations, helpdesk). The rule that decides it: a Tier-0 identity must never authenticate to a Tier-1 or Tier-2 system, because a lower-tier compromise then harvests Tier-0 credentials and the whole model collapses. This is why jump hosts and hardened administrative workstations exist — the admin path is a separate chain, not the same laptop with a second browser profile.

Bind elevation to a named actor and a fresh phishing-resistant authentication ceremony. Require a reason and ticket where useful, approval independent of the requester for high-impact roles, a bounded activation window, explicit resources and actions, and automatic expiry. Just-in-time controls shrink exposure; just-enough administration constrains what the elevated identity can do.

Credential handling and session controls

Prefer ephemeral, audience-bound credentials or platform-issued sessions over revealing a reusable password. When legacy secrets remain, generate them with strong entropy, encrypt and strictly authorize them, never display them unnecessarily, rotate after checkout or suspected exposure, and prevent logs or recordings from capturing them. The person who administers the vault should not silently approve their own unrestricted access or erase independent audit evidence.

Proxy or broker privileged sessions where it provides command, target, network, and recording controls. Bind the session to the approved grant and target; prevent a connection from being reused against a different host or tenant. Record commands or screens only with declared purpose, access restrictions, tamper protection, retention, privacy controls, and redaction for secrets and personal data. Recording does not replace prevention: dangerous commands, data export, and control-plane changes may need explicit policy or step-up.

Break-glass access

Break-glass is a tested recovery mechanism, not a convenient bypass. Maintain the minimum number of emergency identities, isolate their credentials (sealed, rotated, stored independently of the normal IdP), use strong independent authentication where the failure model permits, restrict their capability, alert on every access attempt, and review immediately afterward with automatic post-use rotation. Dual control on unsealing is right where the failure model permits it; an emergency account one person can use silently is just unmanaged standing privilege.

Test IdP, network, PAM, region, and logging outages. A break-glass account that depends on the failed identity provider is not a break-glass account. If the quarterly drill cannot complete without the production IdP, the design has not been tested against the failure it claims to survive. Interviewers follow up with "what happens when the approval path itself is down?" — the answer is break-glass with compensating visibility, not disabling approvals.

Machine privilege

Machine privilege needs the same discipline without pretending a person is present. Use workload identity and short-lived credentials bound to workload, audience, environment, and task. Avoid shared static cloud keys and human accounts in automation. Restrict who can impersonate a workload or exchange tokens, propagate the initiating user or job identity where delegation matters, and log both actor and effective principal. Rotation alone cannot fix an over-broad service role — a common weak answer treats rotation as the fix for a service role that can read every database.

The PAM control plane and revocation

Treat the PAM control plane as a highest-value target. Separate policy author, approver, operator, auditor, and recovery duties. Protect connector credentials, signing keys, session brokers, agents, vault replicas, backup keys, and audit exports. Make configuration versioned and reviewed, require strong administrative authentication, stream evidence to an independent system, and practice recovery. Prevent a compromised PAM administrator from both granting access and deleting the record.

Revocation must be end to end. Expiring the approval record is insufficient if a cloud role session, SSH certificate, database connection, Kubernetes token, or cached authorization remains valid. Define maximum revocation delay, shorten credential and session lifetimes accordingly, revoke or terminate where supported, and reconcile target state. Handle early revocation, user departure, approver cancellation, incident containment, target removal, and policy rollback. Time the interval from the revocation event to a denied privileged action at the target, not to the ticket status changing. A vault checkout that still leaves a 12-hour cloud role session after the ticket closed is standing privilege with extra steps.

Metrics, failure modes, and what a weak answer sounds like

Measure standing privileged identities, eligible versus active grants, activation and approval latency, grants without tickets, unused entitlement, denied and anomalous activation, emergency use, credential exposure, session-policy violations, early-revocation success, end-to-end revocation latency, orphaned target accounts, review completion, and PAM availability. Test self-approval, confused deputy, target substitution, concurrent activations, expiry boundaries, connector outage, stale group membership, vault compromise, recording failure, IdP outage, and cleanup after partial failure.

The weak answer in an interview names a product and lists its features. The strong answer starts from the threat — permanent authority, credential theft, unattributable action — and shows which control closes which gap, what it costs (operational friction, on-call latency when an approver is needed at 3 a.m.), and how the design behaves when its own dependencies fail. The outcome is bounded attributable authority, not simply more logins routed through a vault.