An identity with elevated permissions that can administer systems, alter security controls, access sensitive resources, or affect many users.

Protecting privileged passwords, keys, tokens, or certificates in a managed store that can control retrieval and rotate secrets.

Granting elevated access only when needed and automatically removing it after a short approved period.

Just-enough administration (JEA)

Granting only the smallest set of permissions needed to complete a defined task.

Recording and analyzing privileged activity during an administrative connection, often through a broker or proxy.

Just-enough administration: the minimum permissions necessary for a specific task.

Just-in-time access: temporary elevation granted only when a task requires it.

Privileged Access Management: practices and technologies that control, monitor, and reduce the risk of elevated access.

What is Session proxy?

An intermediary that brokers an administrative connection and can enforce controls, record activity, or terminate a session.

Securing the Keys to the Kingdom — Enterprise IAM and Zero Trust Architecture

1. Why Privileged Access Is Different

The blast-radius problem

A standard account might expose one user's data. A privileged account can alter configurations, create identities, disable defenses, and affect many systems.

PAM changes the default

PAM replaces permanent administrative power with access that is scoped, temporary, approved when needed, and recorded for later review.

Connect to earlier modules

Identity lifecycle answers whether an identity should exist. Authorization answers what it can do. PAM asks whether elevated power is needed now.

2. Identify the Privileged Identities

Quick classification activity

For each identity below, identify its primary category and explain why it is privileged.

`maya.chen@northstar.edu` can add users to the cloud directory.
`svc-payroll-sync` reads HR records and writes updates to the payroll database every night.
`inventory-api-prod` uses an API credential to retrieve stock data from a production service.
A sealed recovery account can restore directory administration if normal administrators cannot sign in.

Reveal

Human privileged account: Maya's account has an administrative directory role.
Service account: `svc-payroll-sync` is a non-human identity that supports an automated process.
Application or workload identity: `inventory-api-prod` is used by software, often through an API key, certificate, token, or managed identity.
Emergency or break-glass account: the recovery account exists for exceptional lockout or outage scenarios.

Do not classify accounts only by their names. Classify them by effective permissions, reachable systems, and the impact of credential compromise.

3. Discover Privilege Before You Manage It

Start with an inventory

Discovery identifies privileged people, service accounts, application identities, credentials, and hidden paths to powerful access across the environment.

Look beyond admin labels

An identity can be dangerous without an `Administrator` title. Resetting passwords, editing secrets, or changing policy can become a path to control.

Make each identity accountable

Record an owner, business purpose, system scope, review date, and effective privileges. Unknown ownership is itself a risk signal.

4. Three Controls, Three Different Jobs

Vaulting protects secrets

A vault stores and rotates passwords, keys, certificates, and tokens. It answers: How is the privileged secret protected and changed?

Elevation grants authority

JIT elevation gives an identity a narrow role for a short period after policy checks. It answers: Who may act, where, and for how long?

Sessions make work observable

Session management brokers, records, and can stop privileged activity. It answers: What happened during the administrative connection?

5. Design a JIT Privileged Access Workflow

1. Request a specific action

Require the target, narrow role, task reason, related change or incident ticket, and requested duration. Vague requests should not produce broad access.

2. Evaluate and approve

Check MFA, device posture, risk, eligibility, and separation of duties. Make approval strength proportional to the potential impact of the request.

3. Grant, observe, expire

Grant the least-capable role, record activity, and automatically revoke access at expiry. Do not depend on an administrator to remember to remove it.

JIT versus JEA

JIT controls when elevated access exists. JEA controls how much authority it includes. Secure workflows use both together.

6. Worked Example: Repairing a Production Outage

The standing-access failure

A permanent production-owner role grants far more power than a five-minute repair needs: secrets, network changes, deletion, and every production service.

The temporary alternative

The engineer requests a 30-minute role tied to an incident. Policy checks on-call status and device compliance before an accountable lead approves it.

Constrain the actual work

The role permits logs, deployment inspection, and one restart. Session controls record activity and block unrelated actions such as secret export.

7. Command Control: Allow, Alert, or Block?

Decide what the session broker should do

An engineer has an approved 30-minute role to restart the `checkout-api` deployment during an incident. For each command, choose allow, alert, or block.

`kubectl rollout restart deployment/checkout-api -n production`
`kubectl get pods -n production`
`kubectl get secret payment-provider-key -n production -o yaml`
`kubectl delete namespace production`

Suggested decisions

Allow the deployment restart because it matches the approved role and task.
Allow or log the pod query because it supports diagnosis.
Alert or block secret retrieval. It is unrelated to restarting the service and may expose durable credentials.
Block namespace deletion. It is destructive, far outside the approved scope, and should require a separate, high-assurance workflow.

Command control should not be treated as a substitute for least privilege. It is a second line of defense when a session contains risky behavior.

8. Emergency and Break-Glass Access

What break-glass means

A break-glass account is an emergency administrative path for identity outages, lockouts, or recovery events when ordinary privileged-access controls cannot operate.

Availability without a back door

Keep emergency access independent enough to work during a lockout, but protect it with controlled storage, immediate alerts, and strict authorization.

Every use creates follow-up work

After use, rotate credentials, review actions and justification, document lessons, and test whether normal access paths can now be safely restored.

9. Check Your Design Choice

Choose the best PAM design

A developer needs to update one production API configuration after an approved change. Which design best applies least privilege and zero-standing-access principles?

Which option is best?

Give the developer a permanent production administrator role so future changes are faster.
Share the production root password in the change ticket, then rotate it next month.
Grant a time-limited role limited to that API configuration, require MFA and the change reference, record the session, and revoke access automatically.
Allow the developer to use a break-glass account because the change was approved.

Show Answer

Answer: C) Grant a time-limited role limited to that API configuration, require MFA and the change reference, record the session, and revoke access automatically.

The third option combines JIT access, JEA scope, contextual verification, session accountability, and automatic expiration. A break-glass account is for exceptional failure scenarios, not ordinary approved work.

10. Key Terms Review

Flip each card

Use these terms to explain how PAM turns administrative power into a controlled, observable, temporary capability.

Privileged account: An identity with elevated permissions that can administer systems, alter security controls, access sensitive resources, or affect many users.
Credential vaulting: Protecting privileged passwords, keys, tokens, or certificates in a managed store that can control retrieval and rotate secrets.
Just-in-time (JIT): Granting elevated access only when needed and automatically removing it after a short approved period.
Just-enough administration (JEA): Granting only the smallest set of permissions needed to complete a defined task.
Session monitoring: Recording and analyzing privileged activity during an administrative connection, often through a broker or proxy.
Command control: Allowing, alerting on, or blocking commands based on policy, task scope, and risk.
Break-glass access: A tightly controlled emergency path used when normal administrative access is unavailable; every use requires alerting and review.

Key Terms

JEA: Just-enough administration: the minimum permissions necessary for a specific task.
JIT: Just-in-time access: temporary elevation granted only when a task requires it.
PAM: Privileged Access Management: practices and technologies that control, monitor, and reduce the risk of elevated access.
Session proxy: An intermediary that brokers an administrative connection and can enforce controls, record activity, or terminate a session.
Command control: A policy capability that permits, flags, or blocks privileged commands according to risk and authorized scope.
Service account: A non-human identity used by an automated service, scheduled task, or integration.
Credential vault: A protected system for storing and managing sensitive credentials such as passwords, keys, tokens, and certificates.
Workload identity: An identity used by an application, API, container, or other software workload to authenticate to another service.
Privileged account: A human or non-human identity with permissions that can significantly change systems, identities, security controls, or sensitive data.
Break-glass account: An emergency administrative account designed for recovery when normal access systems fail.
Credential rotation: Replacing a credential on a scheduled basis or after use, exposure, or a relevant event.
Zero standing access: A model in which privileged access is not permanently active and is instead activated temporarily through controlled workflows.