Physical Access Authorizations

Physical Access Authorizations (NIST SP 800-53 Rev. 5 PE-2) is a deceptively simple requirement that breaks many audits because teams treat badges as a facilities problem, not a security control with strict lifecycle rules. If your system is hosted in a data center, office suite, cage, comms room, or any controlled area that houses system components, you need a documented, repeatable way to decide who gets in, how they’re credentialed, how you revalidate access, and how you remove it when conditions change (NIST Special Publication 800-53 Revision 5).

For FedRAMP Moderate environments, auditors look for two things: (1) a clean story about governance (authorization, approvals, cadence, and removals) and (2) hard evidence that the story matches reality (badge system reports, termination offboarding tickets, visitor controls, and exception handling). This page gives requirement-level implementation guidance you can assign to Facilities, Security, IT, and HR immediately, plus the evidence package you need to keep continuously audit-ready. Where third parties (data centers, managed office providers, colocation operators) control the physical perimeter, your job is to contractually and operationally ensure you still have the required list, review, and removal capability.

Regulatory text

Requirement (PE-2): “Develop, approve, and maintain a list of individuals with authorized access to the facility where the system resides; issue authorization credentials for facility access; review the access list detailing authorized facility access by individuals at an organization-defined frequency; and remove individuals from the facility access list when access is no longer required.” (NIST Special Publication 800-53 Revision 5)

Operator interpretation (what this means in practice):

• Develop/approve/maintain an access list: You need a controlled roster of authorized people for each facility (or controlled area within a facility) that contains system components. The roster must be owned, approved, and kept current.
• Issue credentials: Badges/keys/codes must be issued only after authorization, and you must be able to show who approved what.
• Review at a defined frequency: You must define the review cadence and perform it. Auditors will ask for evidence that the review happened and that it resulted in action.
• Remove when no longer required: Offboarding and role change events must trigger access removal. “No longer required” includes termination, contract end, role change, or facility scope change.

Plain-English requirement: what PE-2 is really testing

PE-2 tests whether you control physical entry with the same discipline you apply to logical access:

• Authorization: entry is based on job need and management approval.
• Least privilege: access is limited to the facility/area needed.
• Lifecycle discipline: access is reviewed and removed reliably.
• Auditability: you can prove all of the above with records.

If your badge system is messy (shared badges, generic “contractor” profiles, no end dates, no reviews), PE-2 becomes a recurring finding even if your doors are locked.

Who it applies to (entity + operational context)

Applies to:

• Cloud Service Providers operating FedRAMP Moderate systems (NIST Special Publication 800-53 Revision 5).
• Federal Agencies hosting or operating systems in facilities they control or share (NIST Special Publication 800-53 Revision 5).

Operational contexts that typically fall in scope:

• Corporate offices with production admin workstations or secure enclaves.
• Data centers, colocation cages, meet-me rooms, telco closets, server rooms, and secure storage where system media is kept.
• Third-party managed facilities where you have staff access (even if the third party controls the perimeter).

Scope decision you must make early: define “facility where the system resides.” If the system is in a colocation cage, treat the cage as the facility boundary for PE-2 purposes, but also address any upstream perimeter access you request from the colocation operator.

What you actually need to do (step-by-step)

1) Define the facilities/areas and the “authoritative list” owner

• Identify each facility or controlled area containing system components.
• Assign a single system owner or security owner accountable for the PE-2 access list per site.
• Decide the system-of-record for the roster (badge system export, GRC register, or identity platform). The key is that it is authoritative and reviewable.

Deliverable: a short “Physical Access Authorization Standard” stating scope, owner, approval roles, review cadence, and removal triggers.

2) Create an authorization workflow for new access

Minimum workflow checkpoints:

• Request includes person identity, employer (employee/third party), role, areas requested, justification, and start/end date (or explicit statement that access is ongoing with periodic review).
• Approvals:
  • Manager (or sponsor for third parties) approves business need.
  • Security/Facilities approves based on area sensitivity and policy.
• Identity proofing occurs before issuance (at least verify government ID in your intake process if you issue badges onsite; if a third party issues credentials, require their process description and evidence availability through contract language).

Deliverable: an access request form/ticket template and an approval matrix.

3) Issue credentials with traceability

• Ensure each credential maps to a unique person (avoid shared badges).
• Configure badge profiles by area (door groups) aligned to least privilege.
• If you must issue temporary badges, set explicit expiration and require check-in/check-out.

Evidence to produce: credential issuance record tied to an approved request.

4) Perform periodic access list reviews (and record results)

PE-2 requires review “at an organization-defined frequency” (NIST Special Publication 800-53 Revision 5). Pick a cadence you can sustain, then operationalize it:

• Generate the current authorized access list per facility/area from the system-of-record.
• Send to approving authorities (Facilities/Security + functional managers) for attestation:
  • Confirm each individual still needs access.
  • Confirm access scope is correct (areas/doors).
  • Confirm employment/contract status and end dates.
• Record outcomes: approved/removed/modified, who reviewed, when, and what changed.

Practical tip: treat this as an access recertification event with a tracked ticket and attachments.

5) Remove access promptly when no longer required

Define removal triggers and assign ownership:

• HR termination feed triggers badge disablement.
• Contract end date triggers disablement for third-party personnel.
• Role change triggers reassessment (e.g., engineer moved off the program).
• Lost badge triggers immediate disablement and re-issuance workflow.

Make sure “removal” includes:

• Badge deactivation in the access control system.
• Recovery of physical badges/keys where feasible.
• Update to the authorized list.

6) Handle third-party facilities without losing control of PE-2

If a data center operator controls the badge system:

• Contract for the ability to obtain current access lists, credential issuance records, and removal confirmation for your personnel.
• Define an operational process for requesting adds/removals and receiving confirmations.
• Keep copies of monthly/periodic access reports and your review sign-offs.

This is where teams often stumble: you can outsource the door, but not the control objective.

Required evidence and artifacts to retain (audit-ready package)

Keep evidence per facility/area:

Governance artifacts

• Physical Access Authorization policy/standard referencing PE-2 (NIST Special Publication 800-53 Revision 5).
• Role-based access approval matrix (who can approve which areas).
• Defined review frequency and reviewer responsibilities.

Operational records

• Current authorized access list (named individuals, access areas, sponsor/manager, start/end date if applicable).
• Samples of access requests with approvals and issuance proof.
• Recertification/review packets: exported lists, reviewer attestations, and resulting removals/changes.
• Offboarding records: tickets showing badge disablement tied to HR/contract termination.
• Exception records: temporary access approvals, escort requirements, or emergency access.

System evidence

• Badge/access control system reports showing active badges by area.
• Deactivation logs (who disabled, when).
• If applicable, third-party data center access reports and confirmation emails/tickets.

Common exam/audit questions and hangups

• “Show me the current list of authorized personnel for this facility, and who approved it.”
• “What is your defined review frequency, and show the last completed review and resulting removals.” (NIST Special Publication 800-53 Revision 5)
• “How do you ensure contractors are removed when their engagement ends?”
• “Do you have shared badges, generic ‘visitor’ badges with broad access, or badges without owners?”
• “How do you handle after-hours or emergency access?”
• “If the facility is run by a third party, how do you get access records and ensure timely removals?”

Hangup pattern: the badge system list and the “approved list” don’t match, or nobody can show documented review sign-off.

Frequent implementation mistakes (and how to avoid them)

1. No single authoritative list.
   Fix: designate one roster source per facility and reconcile it to the badge system on every review cycle.

2. Approvals happen verbally or in email threads.
   Fix: require a ticketed workflow with captured approver identity and timestamp.

3. Contractors have no end dates.
   Fix: require an end date for third-party access requests, then re-request if extended.

4. Reviews are “we do it when we remember.”
   Fix: calendar the reviews, assign a control owner, and store the review packet in a consistent repository.

5. Terminations don’t reach Facilities fast enough.
   Fix: connect HR offboarding to an automatic ticket or a daily report to Facilities/Security for badge disablement confirmation.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. From an audit and incident-response perspective, weak PE-2 controls increase the chance of unauthorized physical entry, tampering, theft of media, and compromise of systems hosted in controlled spaces. The operational risk shows up quickly during FedRAMP assessments because auditors can test PE-2 through a simple roster-to-badge-system reconciliation and by sampling recent terminations against deactivation logs (NIST Special Publication 800-53 Revision 5).

Practical execution plan (30/60/90)

You need speed without inventing schedules. Use phases tied to deliverables.

First 30 days (stabilize and document)

• Confirm scope: facilities/areas that contain system components.
• Name the PE-2 control owner and Facilities/Security co-owners.
• Standardize the access request and approval workflow (ticket template + approval matrix).
• Export current badge holders per area and create the initial “approved list” baseline.
• Identify stale access candidates (no sponsor, no role alignment, unknown end dates) and open remediation tickets.

By 60 days (operate the lifecycle)

• Run the first formal access review on the baseline list; record approvals and removals.
• Implement offboarding triggers (HR/contract end) with documented confirmation steps.
• Ensure temporary access is time-bound and tracked.
• For third-party data centers, put in place a repeatable access reporting and removal confirmation process.

By 90 days (make it audit-ready and sustainable)

• Demonstrate at least one complete cycle of review-to-removal with clean evidence.
• Reconcile discrepancies between the approved list and the badge system until variance is explainable and documented.
• Add metrics that are evidence-friendly (counts of adds/removes, overdue reviews) without relying on unsourced benchmark targets.
• If you run GRC in Daydream, map PE-2 evidence requirements to recurring tasks so reviews, rosters, and samples are collected continuously rather than assembled during audit.

Frequently Asked Questions

Do we need a separate physical access list for each building and each server room?

Maintain lists at the level you can control and review meaningfully: per facility or controlled area where the system resides (NIST Special Publication 800-53 Revision 5). If a server room has stricter access than the rest of the building, treat it as a separate controlled area with its own roster and approvals.

What counts as an “authorization credential” for facility access?

Any mechanism that grants entry, including badges, keys, fobs, mobile credentials, or door codes (NIST Special Publication 800-53 Revision 5). The key audit point is traceability: the credential must map to an authorized individual and an approval record.

Our data center provider controls the badge system. How do we comply?

Contract and operationalize access reporting: you need a current list of your authorized individuals, proof of credential issuance, periodic review evidence, and removal confirmations (NIST Special Publication 800-53 Revision 5). Keep provider reports and your internal review sign-offs together as the PE-2 evidence packet.

How do we handle visitors and escorted access?

Visitors should not be added to the authorized access list unless they genuinely need recurring unescorted access. Use a visitor log, escort rules, and time-bound temporary badges, then retain those records as supporting evidence for how you prevent unauthorized access.

What triggers removal besides termination?

Role changes, program reassignment, contract end, and facility scope changes all trigger “access no longer required” under PE-2 (NIST Special Publication 800-53 Revision 5). Define these triggers in your standard and make one team accountable for initiating the removal ticket.

Can we satisfy the “review” requirement with a badge system report stored in a folder?

Not by itself. A stored report shows data exists, but PE-2 expects a review action: named reviewer, date, decision outcomes, and evidence of removals or modifications when needed (NIST Special Publication 800-53 Revision 5).