Run a Production Access Review

Inventory production identities and permissions, remove stale or excessive access, verify MFA and break-glass paths, and schedule the next review.

intermediate~90 minsecurityaccess-controlcompliance

Objective

Reduce the production attack surface by proving that every human and machine identity has a current owner, a justified role, and a reviewed access path.

Environment

An identity provider or cloud IAM with an exportable list of users, roles, and keys
An inventory of services and the credentials they use
An approval record for privileged roles
A break-glass procedure with logging and alerting

Steps

1. Export identities and permissions

List human users, service accounts, roles, access keys, and group memberships with their last activity and creation date.

Expected state: A reviewed dataset exists for every production identity, not only the obvious admin accounts.

2. Classify by necessity

Mark each identity as active, seasonal, service-owned, or stale. Identify permissions that exceed the documented role.

Expected state: Every identity has an owner and a justification, or is marked for removal.

3. Remove stale and excessive access

Disable unused accounts and keys, remove unused roles, and narrow wildcard permissions to the operations actually used.

Expected state: Removed credentials fail and the remaining set matches the approved roles.

4. Verify strong authentication

Confirm MFA or SSO for human access, short-lived credentials for automation, and no long-lived keys where federation is possible.

Expected state: Human access requires MFA and machine access uses scoped, rotatable credentials.

5. Test the break-glass path

Confirm the emergency access process is documented, monitored, and requires an explicit alert. Verify that normal access removal does not disable it accidentally.

Expected state: A break-glass use is possible, logged, and reviewed afterward.

6. Schedule and record the next review

Set a recurring review date, assign owners, and store the evidence in the compliance system.

Expected state: The next review has a date and an accountable owner.

Decision points

Should dormant accounts be disabled or deleted?

Disable first, delete after a retention window
Delete immediately

Disable first so ownership can be confirmed and accidental dependencies can be discovered; delete after the retention window.

How often should privileged access be reviewed?

Quarterly
Annually

Review privileged production access quarterly; annual reviews leave stale access in place for too long.

Expected outcome

Production access is limited to current, owned identities with strong authentication, and the organization can prove when it was last reviewed.

Verification

Verify that disabled identities cannot authenticate, that remaining roles match the approved matrix, that MFA is enforced for humans, and that break-glass activity generates an alert.

Cleanup

Archive the review evidence, close tickets for removed access, and update the identity inventory with the new review date.

Inventory is the hard part

Most organizations know who has admin access. Fewer can list every service account, CI key, delegated role, and forgotten contractor account. Export from the identity provider and the cloud IAM, then reconcile the two. Include credentials stored in CI variables and deployment tools; they are production identities even if they never log in through a browser.

aws iam list-users --query 'Users[].{User:UserName,Created:CreateDate}' --output table
aws iam list-access-keys --query 'AccessKeyMetadata[].{User:UserName,Key:AccessKeyId,Status:Status}' --output table

Equivalent commands exist in every cloud. The important output is a joinable table of identity, owner, role, last activity, and credential age. Without last activity, the review becomes a popularity contest rather than an evidence-based cleanup.

Least privilege must be testable

A role named admin with Action: "*" is not a review outcome. Compare granted permissions with the operations recorded in audit logs over a representative window. Remove wildcards that are not used, and move human access behind SSO and short-lived sessions. For automation, prefer workload identity or short-lived tokens over static keys.

Break-glass is part of the design

Removing access can accidentally remove the emergency path. Keep a documented break-glass identity with strong authentication, an alert on use, and a post-use review. Test it during a drill, not during the incident.

Make the next review inevitable

Record the review date, owners, and evidence. Put the next review on the calendar and assign an accountable person. A review that depends on someone remembering is a review that will not happen. Track stale-account count and long-lived key count as metrics so the trend is visible between reviews.