# Privileged access and emergency accounts

An administrator can restore a service or alter its protections. PAM goes beyond a password vault: granting, observing use and removing privilege belong in one design. This guide distinguishes daily administration, service identities and emergencies where the identity provider itself is unavailable.

Original SecNet educational content with fictional examples, not publication/endorsement by referenced organizations. Page exercise choices last only for the open session; no real organizational data is collected.

2026.10 · 2026-10-21

## What should I do tomorrow?

1. Inventory human and service administration for one critical service.
2. Test one maintenance task using a narrow time-bound role.
3. Walk through identity, vault and notification dependencies of emergency access.

## Concepts

**PAM** — Processes and controls governing privileged identity and access throughout its lifecycle.

**JIT** — Activating privilege for an approved need and bounded time.

**JEA** — Narrow action permissions sufficient for a task instead of full administration.

**Break-glass** — Protected and monitored emergency access used when the normal path fails.

**Oturum atfı / attribution** — A trace linking an action to an authorized person and request.

## Process map

### 1. Discover privilege

IAM + service owner

Inventory human, service and local administrative access.

Owned privilege inventory.

### 2. Bound the role

Business owner + security

Define tasks, duration, approval and separation.

Approved role matrix.

### 3. Activate access

Authorized approver

Validate the request and grant time-bound access with strong authentication.

Person-request-role trace.

### 4. Observe use

Operations + SOC

Record sessions and critical actions under access controls.

Protected action trail.

### 5. Revoke and test

IAM + independent reviewer

End privilege and exercise emergency access under control.

Revocation and test evidence.

## Where administrative privilege hides

Include local accounts, cloud roles, virtualization, databases, backup systems and security tools alongside directory administrators. Deployment or deletion rights in CI/CD and service accounts are privileges too. Record owner, purpose, target, role, authentication path and last-use source; never place secret values in the register.

Separate people from automation identities. An ownerless account is investigated for dependencies before controlled restriction, not automatically deleted. Using administrator identities for email and browsing increases exposure. Assess separate administrative identities and appropriate management devices against actual service requirements.

- [ ] Human and automation privileges have owners and purposes.

Reference: [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

## Task and duration instead of permanent privilege

If fictional database maintenance needs only index rebuilding, do not grant tenant-wide administration. Define permitted actions, target and start/end times. Test whether expiry affects open sessions, previously issued tokens and related keys; removing a role may not immediately end every access path.

Separate requester and approver for critical operations. Emergencies still need named ownership and justification; retrospective review must not become routine unapproved work. Approval records the business decision, while technical evidence shows actual target permissions. Reconcile both before closure.

Three distinct access paths

| Path | Boundary | Evidence |
| --- | --- | --- |
| Daily administration | Named person, task and time | Request, role and action trail |
| Automation | Workload identity, narrow scope | Owner, dependencies and lifecycle |
| Emergency access | Independent recovery path, monitoring | Activation, outcome and review |

- [ ] Actual target access is checked after expiry.

Reference: [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

## Authentication and session security

Evaluate phishing-resistant authentication for privileged identities. NIST SP 800-63B-4 provides authentication-assurance guidance, not an automatic legal mandate for every organizational role. Combine authentication with device posture, management paths and target permissions. Strong MFA does not make excessive authorization safe.

When using a vault or bastion, preserve attribution between person, approved request, target and action time. Session recordings may contain sensitive data; restrict access and retention. Do not log passwords or tokens. Define an authorized stop or narrow emergency path if recording is unavailable.

- [ ] Recording access and data scope are restricted.

Reference: [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), [NIST SP 800-63B-4 — Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html)

## Emergency access when identity infrastructure fails

Check whether emergency access shares failure dependencies with daily federation, phones, networks or vaults. Independence depends on provider architecture and does not mean disabling MFA in every product. Follow provider guidance for strong authentication, secure custody, deputies and accessible recovery instructions.

For Microsoft Entra, assess the provider-specific emergency-access guidance instead of copying it unchanged to a local database. Observe emergency use independently of normal administrative access. Controlled tests verify permissions, notification recipients and recovery of controls. Exercise dependencies rather than assuming access survives an identity outage.

- [ ] Shared failure dependencies of emergency access have been tested.

Reference: [Microsoft Learn — Manage emergency access accounts](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access)

## Service identity, departure and secret changes

A service-account owner leaving must not stop operations or leave an unmanaged identity. Record business sponsorship, custodians and consuming workloads. Prefer short-lived workload identity where supported. When long-lived secrets are necessary, manage distribution, rotation and revocation dependencies through controlled storage.

Offboarding goes beyond role removal. Review active sessions, API keys, local accounts, shared secrets and recovery records. Tie secret changes to service tests: the old value should fail and only authorized consumers should receive the new one. Treat attribution gaps in shared accounts as explicit risks.

- [ ] Identity termination covers associated sessions and secrets.

Reference: [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

## Management through evidence and measurement

For a fictional maintenance request link requester, target CI, reason, approval, duration, actual granted role and outcome. A vault record without target logs leaves an attribution gap. Check time zones and clock alignment; similar timestamps alone do not prove actions belong to the same person.

Measure standing privilege, ownerless service identities, expired grants and untested emergency paths. State the scope and data source. Vault coverage alone does not show control of every privilege; make excluded cloud, OT and local accounts visible.

- [ ] Excluded identities are visible in reporting.

Reference: [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final)

## Common mistakes and better approaches

**Vaulting is the entire PAM programme.** — Validate role, approval, session and revocation together.

**Emergency accounts are used routinely.** — Move routine tasks to a separate path and alert on emergency use.

**Service accounts have no accountable owner.** — Maintain business sponsorship and workload dependencies.

## Decision examples and explained answers

### Vault unavailable

The recovery password exists only in the failed vault.

**Wait for that same password to open the vault.** — Revisit

A circular dependency cannot restore the service. If vault access depends on that vault, an untested emergency plan is misleading; design an independent method in advance.

**Activate the independent recovery path under authority.** — Supported approach

The authorized owner follows independent instructions, records activation and verifies monitoring. If no path exists, escalate; do not improvise shared passwords or uncontrolled bypasses.

### Maintenance completed

The role is removed but the old session still performs actions.

**Close the request.** — Revisit

A role-list change does not prove every active access path ended. Sessions and token lifetimes must be checked against target-system behaviour.

**Validate session and token invalidation.** — Supported approach

Verify expiry at the target, apply necessary session/token termination and link evidence to the request. Assess service impact and record a bounded risk if enforcement is delayed.

### Workload owner left

A departing person owns a service account running payment jobs.

**Delete the account immediately.** — Revisit

Deleting without investigation can interrupt service, while leaving it indefinitely is unsafe. A controlled transition must separate human access from workload dependencies.

**Validate dependencies, assign ownership and rotate under control.** — Supported approach

End human sessions and validate workload permissions and ownership. Rotate necessary secrets with testing while ensuring the former owner retains no access.

## Official references

- [NIST SP 800-53 Rev. 5 — control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) — Reference for control families; example workflows are SecNet adaptations, not automatic compliance mappings.

- [NIST SP 800-63B-4 — Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html) — Authentication-assurance reference; the PAM workflow is original SecNet teaching.

- [Microsoft Learn — Manage emergency access accounts](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) — Provider-specific Entra guidance; do not copy it unchanged to other products.
