PE-3(4): Lockable Casings

The pe-3(4): lockable casings requirement is a practical physical security control that often fails for a simple reason: teams buy locks, but never define scope, ownership, and evidence. Assessors typically look for consistency and traceability. They want to see that the organization identified what needs protection, installed appropriate lockable casings, and can show who can open them and why.

This enhancement sits in the Physical and Environmental Protection (PE) family and is commonly applied to environments where system components are exposed to casual contact or opportunistic access: offices, shared suites, closets, remote/branch locations, labs, and third-party facilities. If your threat model includes “someone can get close to the device,” lockable casings become a baseline hardening step.

Treat PE-3(4) like a requirement you can operationalize with a short runbook: define the protected items, pick standard enclosure-and-lock options, implement key/combo control, and perform routine inspections with documented results. The remainder of this page gives requirement-level guidance you can hand to Facilities, IT, and Security operations and get executed fast. (NIST SP 800-53 Rev. 5)

Regulatory text

Requirement (verbatim): “Use lockable physical casings to protect {{ insert: param, pe-03.04_odp }} from unauthorized physical access.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator interpretation (what you must do)

• Use lockable casings means you must implement a physical barrier with a lock (key, combination, or managed electronic lock) around the item(s) in scope.
• Protect [organization-defined parameter] means you must define the “what”: the specific devices, components, or interfaces that require a lockable casing in your environment.
• From unauthorized physical access means you must prevent unapproved opening, removal, or manipulation of the protected item, including access that could enable tampering (e.g., unplugging, inserting rogue devices, swapping media, pressing reset buttons).

Practical translation: you are expected to (1) define scope; (2) install lockable housings; (3) control who can unlock them; and (4) prove it with documentation and inspection artifacts. (NIST SP 800-53 Rev. 5)

Plain-English interpretation of the requirement

PE-3(4) is about reducing “walk-up” physical risk to critical hardware. If an unauthorized person can open a casing, they can often:

• Disconnect power or network to cause outages.
• Insert hardware implants or rogue USB/Ethernet devices.
• Remove storage media or whole devices.
• Trigger factory resets or change configuration via exposed ports.

Lockable casings are not the same as “the room has a badge reader.” This control expects a lock at the device boundary for items that need protection even when someone reaches the device.

Who it applies to (entity and operational context)

Entity types

• Federal information systems implementing NIST SP 800-53 controls. (NIST SP 800-53 Rev. 5)
• Contractor systems handling federal data where 800-53 controls are flowed down contractually (common in SSPs and ATO packages). (NIST SP 800-53 Rev. 5)

Operational contexts where PE-3(4) is commonly in scope

Use cases that frequently trigger PE-3(4) scoping decisions:

• Network closets with shared access (leased buildings, shared IT rooms).
• Public- or customer-adjacent areas (reception, conference rooms, kiosks).
• Branch/remote offices with minimal on-site security staff.
• Labs, staging rooms, and shared engineering spaces.
• Third-party colocation or managed spaces where your staff is not always present.

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

Step 1 — Define the “ODP” scope (the protected items)

The control text includes an organization-defined parameter (“{{ insert: param, pe-03.04_odp }}”). You must fill this in with a clear scope statement. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Create a short scoping standard that answers:

• Which asset classes require lockable casings? Example buckets: network gear, removable media, end-user endpoints in public areas, IoT/OT controllers, backup devices.
• Which environments trigger the requirement? Example: “Any device located outside controlled data centers” or “any device in shared office spaces.”
• Which interfaces are in scope? Example: console ports, USB, reset buttons, storage bays.

Deliverable: a one-page “PE-3(4) Scope Statement” approved by Security/Facilities and referenced in your SSP/control narrative.

Step 2 — Pick approved lockable casing patterns

Standardize. Audits go smoother when you can show “these are the three approved enclosure types.”

Build an approved catalog:

• Enclosure type: rack cabinet, wall-mount cabinet, lockbox, tamper-resistant endpoint case, kiosk enclosure.
• Lock type: keyed, combination, or electronic. (Pick based on operational realities; don’t create a key-management mess you can’t run.)
• Installation standard: mounting method, anchoring expectations, ventilation considerations, cable routing, and whether ports are covered.

Decision matrix (use internally):

Scenario	Minimum casing pattern	Notes for operators
Network switch in shared closet	Lockable rack/cabinet	Keep patch panels accessible without exposing switch ports where feasible
Small router at branch office	Wall-mount lockable cabinet	Include power brick containment if unplugging is the main risk
Workstation in public area	Lockable kiosk/endpoint casing	Also consider port blockers if USB is a concern
Exposed USB/storage media	Lockbox or locked drawer within locked cabinet	Tie to media control procedures

Step 3 — Implement installation and asset linking

Your procedure should force traceability:

1. Identify device (asset tag/serial).
2. Assign casing (casing ID, location, model).
3. Install (date, installer, photos).
4. Validate (confirm it locks; confirm ports/buttons are protected as intended).
5. Update inventory/CMDB with a “PE-3(4) protected = yes” attribute and reference to the casing ID.

Step 4 — Control access to keys and combinations

Lockable casings fail if keys are uncontrolled.

Minimum operational controls:

• Authorized access list by role (e.g., Network Ops, Field Services, Facilities).
• Key issuance log (who has which key, when issued, when returned).
• Combination management (who can know it, when it changes, where it is stored).
• Break-glass process for emergencies, with after-action documentation.

If you already run a physical access control system for buildings, keep PE-3(4) separate: building access does not equal device casing access.

Step 5 — Run inspections and handle exceptions

Set a recurring inspection cadence that fits your environment (you choose the frequency as internal guidance). During inspections:

• Confirm casing is present, locked, and not damaged.
• Confirm keys/combo access list is current.
• Check for signs of tampering or bypass (missing screws, forced hinges, exposed ports).

Exception handling:

• Document temporary unlocks (maintenance windows, vendor support visits).
• Record compensating controls if a lockable casing is infeasible (and track remediation plan). Keep the exception time-bound and approved.

Required evidence and artifacts to retain

Assessors commonly ask for evidence that ties policy to real installations. Keep these artifacts ready:

Design and governance

• PE-3(4) scope statement (the filled-in “ODP”).
• Standard(s) for approved lockable casing types and lock management.
• Roles and responsibilities (control owner, Facilities/IT implementers).

Implementation evidence

• Asset inventory or CMDB export showing in-scope assets and “protected by lockable casing” attribute.
• Installation records (work orders/tickets) for each location.
• Photos (or video) of installed casings showing lock points and context.

Operational evidence

• Key/combo issuance and return logs.
• Inspection checklists and results (including failures and corrective actions).
• Exception register with approvals and compensating controls.

Daydream (as a workflow) is a natural fit where teams struggle: mapping PE-3(4) to a control owner, documenting the procedure, and generating recurring evidence prompts so inspections and key logs don’t go stale.

Common exam/audit questions and hangups

Expect questions like:

• “What exactly is {{ insert: param, pe-03.04_odp }} for your system?” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “Show me which devices are in scope and where they are located.”
• “Who can unlock these casings, and how do you remove access when someone changes roles?”
• “Show inspection results and how you tracked remediation when a cabinet was found unlocked.”
• “How do you handle third-party technicians who need temporary access?”

Typical hangup: teams show a policy but cannot show asset-level traceability and recurring operational records.

Frequent implementation mistakes and how to avoid them

1. Mistake: Scope is vague (“critical equipment”).
   Fix: define scope by asset class + location context + interfaces to be protected.

2. Mistake: Buying cabinets but not managing keys.
   Fix: treat keys/combinations like privileged access. Maintain issuance/return records and role-based authorization.

3. Mistake: Locks exist, but devices are still reachable.
   Fix: validate that the casing actually blocks access to ports, reset buttons, storage bays, and power disconnect points when those are the risks.

4. Mistake: One-off installs with no standard.
   Fix: publish an approved pattern library. Require Facilities/IT to select from it unless an exception is approved.

5. Mistake: No evidence beyond photos.
   Fix: tie installs to tickets, inventory, inspections, and access logs. Audits want an operating control, not a snapshot.

Enforcement context and risk implications

No public enforcement cases were provided in the source materials for this requirement, so treat enforcement risk as indirect: PE-3(4) failures tend to show up during audits/assessments as control deficiencies and can contribute to broader findings about physical security, configuration integrity, and unauthorized access paths. The practical risk is straightforward: if someone can physically reach and open a device enclosure, many logical controls become easier to bypass.

A practical 30/60/90-day execution plan

Use phases so you can start immediately without inventing time estimates.

First 30 days (Immediate)

• Assign a control owner and implementers (Security + Facilities + IT Ops).
• Draft and approve the PE-3(4) scope statement (define the ODP).
• Inventory likely in-scope assets by location; flag high-exposure areas first.
• Select approved casing/lock patterns and document procurement/install standards.

Days 31–60 (Near-term)

• Deploy lockable casings to the highest-risk locations first (public/shared access).
• Establish key/combo control process: authorized roles, issuance logs, and break-glass.
• Update CMDB/asset inventory to link assets to casings and locations.
• Create an inspection checklist and start recording results.

Days 61–90 (Operationalize)

• Expand deployment to remaining in-scope sites.
• Run a complete inspection cycle; log corrective actions.
• Stand up exception handling with approvals and compensating controls.
• Package evidence for assessors: scope statement, inventory mapping, install tickets, inspection results, access logs.

Ongoing (Steady state)

• Keep inventory current when devices move.
• Reconcile key/combo access when staff changes roles.
• Repeat inspections and track remediation to closure.

Frequently Asked Questions

What counts as a “lockable casing” for PE-3(4)?

A physical enclosure with a functioning lock that prevents unauthorized opening and direct access to the protected item. In practice this can be a lockable rack, cabinet, lockbox, or purpose-built kiosk/endpoint enclosure, as long as it blocks the access path you are trying to control. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Do we still need lockable casings if the room is badge-controlled?

Often yes. PE-3(4) targets device-level protection against unauthorized physical access, and building access controls do not always limit access to the specific device or ports. Your scope statement should specify when room controls are sufficient and when device casings are required. (NIST SP 800-53 Rev. 5)

How do we define the {{ insert: param, pe-03.04_odp }} scope without over-scoping?

Start with assets where physical access enables high-impact actions: network infrastructure, shared-area endpoints, exposed consoles, removable media, and devices in third-party or shared spaces. Document environment triggers and allow exceptions with compensating controls to avoid forcing impractical installs everywhere. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence is most persuasive to auditors?

Asset-to-casing traceability plus operational proof: inventory records showing which devices are protected, installation work orders, key/combo access logs, and inspection results with remediation tickets. Photos help, but they rarely stand alone in an assessment.

How should we handle third-party technicians who need cabinet access?

Treat it like temporary privileged physical access. Use a documented escort or supervised access process, time-bound authorization, and record the event (who, when, what device, and reason). Update your key/combo process so third parties do not retain standing access.

Our casings are lockable, but keys are stored in an unlocked drawer. Is that compliant?

That setup will usually fail a practical assessment because it defeats the purpose of the casing. Store keys in a controlled method aligned to your physical security model (locked key cabinet, controlled issuance, or equivalent) and document the process as part of operating the control.