03.10.01 Physical access authorizations

NIST SP 800-171 03.10.01 asks you to keep an approved list of people who may enter the facility where your CUI system resides, review it on a defined schedule and remove access that is no longer needed. Assessors test the list, the reviews and the removals.

On this page

What 03.10.01 physical access authorizations requires in practice

03.10.01 requires you to build and maintain an approved list of the people who may enter the facility where your CUI systems reside, issue access credentials from that list, review the list at a defined frequency, and remove people as soon as they no longer need access. The risk it addresses is simple: anyone physically inside the building, including a former contractor with a working badge, can reach servers, workstations, backup media and network closets that hold CUI. Assessors test this by asking for the authorized access list, the procedures that govern it, and the record of reviews, then checking whether the people on the list match people who should still be there.

The difficulty is that the list drifts. Access is granted in one system, often the badge or facilities platform, while employment status lives in HR and contractor end dates live in procurement or a sponsor's inbox. When one of those sources changes and the others do not, the physical list is wrong without anyone noticing. The review frequency is also an organization-defined parameter: NIST does not set it for you, so you must choose a value, write it into your procedures, and then meet it. Confirm the ODP value with your contracting officer or assessor if a federal agency has specified one, because the nonfederal organization must assign the value when none is given.

Rev. 2 had this as 3.10.1, and NIST's change analysis classifies the move to Rev. 3 as significant, mainly because Rev. 3 expects more detail and foundational tasks such as the procedures themselves. The requirement is distinct from 03.10.02, which is about monitoring and reviewing physical access events to detect incidents, and from 03.10.07, which enforces authorizations at entry and exit points through verification, escorts and logs. In practice, 03.10.01 is the list and its upkeep, and the other two requirements depend on it being right.

Which facilities, people and systems fall under 03.10.01

The access list in 03.10.01 covers only the facility where the CUI system resides, so the first scoping decision is physical. Shared buildings, colocation space, contractors and cloud facilities each change who must appear on the list and who must prove they were reviewed. Settle these boundaries in the system security plan before building the list.

The room or facility holding the system

Start by identifying the exact room, cage, rack or building where the CUI system and its storage physically sit. The access list must cover people with authorized access to that facility, so a vague boundary such as the whole campus leaves gaps or creates an unmanageable list. Record the boundary in the system security plan with a floor plan or site diagram, and confirm that every person who can reach the hardware, including through an adjacent area, is accounted for. Check whether backup media or a disaster recovery site is a second facility that needs its own list.

Shared buildings and tenant space

When the CUI system sits in an office or floor that other companies or departments also use, the access list must show who can cross from common areas into the protected space. Lobby staff, facilities teams and other tenants may not need the list, but their paths to the protected area do. Ask the building owner or landlord for written entry records, badge issuing rules and who controls the key or card system. Where the boundary cannot be controlled, document the compensating measures and the responsibilities agreed with the building operator.

Colocation and data center space

In colocation, the provider controls the building, but your cage or rack is still the facility where your system resides. Confirm with the provider how it issues credentials, whether it keeps a named authorized list for your space, how it removes people, and how often it reviews that list. Ask for the provider's review records and its assurance reports, then decide whether your own list must mirror its list or sit above it. Many organizations keep their own record of who is authorized to request access on their behalf.

Contractors, cleaning and maintenance staff

Contractors, cleaning crews and maintenance vendors often reach the protected space without being employees. Decide whether each category is on the authorized list, is escorted, or is kept out entirely, and write that rule into the procedure. Set an end date for each contractor credential that matches the contract term, and confirm that the vendor's personnel records support the removal of access when the contract ends. Ask vendors to confirm in writing how they track their own staff who hold credentials.

Cloud provider facilities and inherited controls

If the CUI system runs in a cloud or hosted environment, the provider's data center is usually outside your direct control. Your assessment can rely on inherited controls only when the provider's controls are documented and you can confirm they operate as described. Obtain the provider's compliance documentation, identify which physical controls it claims, and confirm that its scope covers the region and facility where your data is stored. Record any gap as a responsibility you retain, and do not assume the provider's list satisfies your own review obligation.

Setting the review frequency

03.10.01 requires the access list to be reviewed at a defined frequency, and that frequency is an organization-defined parameter. NIST does not assign the value. If the federal agency or contract does not set it, your organization must assign one and document it in the system security plan. Ask the contracting officer or prime contractor first, record the answer, and then state the interval you chose with a reason. An assessor will check that the value is defined, so an undefined or unstated frequency can fail the requirement even when reviews take place.

How to build the access list and review cycle step by step

This sequence turns 03.10.01 into a working process: a defined facility boundary, a named owner and approver, an initial list built from authoritative records, a review frequency set as the organization-defined parameter, controlled credential issuance, and removals tied to offboarding. Each step produces a document or record an assessor can examine.

  1. Define the facility boundary for the system

    Identify every physical location where the system resides, including data halls, server rooms, colocation cages, offices with workstations that access CUI, and any storage for backups or media. Record the boundary in the system security plan and in a short signed boundary definition. The step is complete when the facility named in the list matches the locations in the system inventory, so nobody with access to a site is missing from the list or appears on it without a reason.

  2. Name the list owner and the approver

    Assign one accountable owner for the access list, usually the facilities or security lead, and a separate approver who can authorize access, often the system owner or CISO. Write both roles into the physical protection policy and procedures. The output is a roles entry that shows who maintains the list, who approves additions, and who receives review results. Confirm that the approver is not the same person who grants the credentials where your size allows it.

  3. Build the initial authorized access list

    Compile the first list from authoritative sources: HR records for current employees and contractors with a documented need, the badge or access control system export, and the contract register for vendors and maintenance staff. Compare the sources and resolve each mismatch, such as a badge with no HR record. Each entry should carry the person, the facility, the business reason and the approval date. The step closes when the owner signs the list as approved and it is stored under version control.

  4. Set the review frequency as the organization-defined parameter

    NIST does not assign the review frequency for 03.10.01, so the organization must set it. Choose an interval that fits the facility risk, record it in the physical protection procedures, and state it in the system security plan. Ask your assessor or the sponsoring agency whether they require a specific value. The output is a documented frequency that an assessor can compare against the review records, because an undefined value leaves the ODP unmet.

  5. Issue facility access credentials under the approved list

    Issue badges, keys or codes only to people on the approved list, and record each credential against the list entry with the issue date and the issuer. Credentials for visitors or temporary staff should be linked to a time-bound authorization and an escort rule if your procedures allow visitors. The step is complete when a reconciliation shows that every active credential maps to an approved entry and no credential exists without one.

  6. Run the scheduled review and record decisions

    At the frequency you set, the owner compares the approved list against current HR records, contract end dates and badge activity, then asks each sponsor to confirm that access is still needed. Record each decision as keep, change or revoke, with the reviewer and date. Access certification tools such as midPoint can route these decisions to designated reviewers within a set timeframe and keep the audit trail, but the review must still be done and evidenced whichever tool you use.

  7. Wire removals into the offboarding workflow

    Connect removal to HR termination, contract end and role change events so that facility access is revoked when access is no longer required, not only at the scheduled review. Where identity is managed centrally, a provisioning connector such as the authentik SCIM provider can deprovision accounts in target applications when a user loses access, but physical credentials usually need a separate revocation step recorded on the list. The output is a removal log that shows the date each credential was deactivated and the trigger that caused it.

How an assessor tests the access list

The examine method looks at documents and records. For 03.10.01, an assessor starts with the physical protection policy and the procedures for physical access authorizations, then checks whether they describe who approves access, how credentials are issued, how often the list is reviewed and how removal works. The assessor then asks for the authorized personnel access list itself and the records of past reviews, because those records show whether the stated process was followed.

  • Policy and procedures: the documents must name the approver, the review frequency and the removal steps, not just the intent.
  • Authorized access list: each entry should show the person, the access granted, the approver and the date approved.
  • Review records: dated sign-offs showing that someone compared the list against current staff and contractors.
  • Removal evidence: tickets or logs showing credentials were revoked after a role change or departure.
  • Common finding: a list with no approver, or a review record with no date, which cannot show the defined frequency was met.

Before the assessment, confirm the review frequency your organization has set for the ODP and make sure every document uses that same value.

Which evidence passes the 03.10.01 test

An assessor testing 03.10.01 will examine written policy, the access list itself, and the records showing that the list is reviewed and cleaned up. Each card below is one artifact, and together they show that access was authorized, credentialed, checked at the defined frequency and removed when it was no longer needed.

Approved facility access list

This is the core artifact: a list of every individual authorized to enter the facility where the system resides, with a named owner for the list and the approval date and approver for each entry. Record the access purpose and the level of access granted, so the list can be matched against actual entries. Export a dated copy on a fixed schedule so the list at any past point can be shown, not only the current version. Confirm with your assessor which list format they accept.

Badge and credential issuance records

Issuance records show that each facility credential, such as a badge, key or PIN, was issued to a person on the approved list and only after approval. Log the credential identifier, the recipient, the issue date and the authorizing approver. An assessor will compare these records against the access list to find credentials with no matching approval. Confirm with your facilities team how lost and replaced credentials are recorded, because those events also need traceable approval.

Signed access review records

Each periodic review of the list should produce a signed record showing which reviewer checked it, the date, and the decision for each entry: keep, change or remove. A review that confirms every entry without showing any reasoning is weak evidence. Identity platforms such as midPoint can run access certification campaigns in which designated reviewers decide within a set timeframe, and their decision history can serve as this record. Confirm the review frequency with your own policy before the first review cycle.

Removal tickets tied to offboarding

Removal is the step most often missing from evidence. For each individual removed from the list, keep a ticket that records the trigger, such as a role change or departure, the date access was revoked and the person who confirmed it. Link these tickets to HR offboarding so that a departure cannot close without a matching facility removal. An assessor will often sample recent leavers and check whether their access was actually removed on time. Confirm your target timing with your own policy.

Written review frequency

03.10.01 includes an organization-defined parameter for how often the access list is reviewed, so the frequency must be assigned and written down. Put the value in the physical protection procedures and the system security plan, and name the role responsible for running each review. An assessor checks that the documented frequency matches what the review records show. If the review records show a different cadence than the written one, the gap is a finding even if the reviews themselves were sound.

Physical protection policy and procedures

The policy states why facility access is controlled and who is accountable for it. The procedures explain the steps: how access is requested, approved, issued, reviewed and removed. Both should name owners and show a revision history with approval dates. An assessor examines these first to understand what the other artifacts are meant to prove. Keep a dated copy of each version so that the procedure in force during any past review can be shown.

What meeting 03.10.01 costs in money and effort

This table breaks the cost of keeping an approved facility access list into components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request, since no price or duration is published for this requirement.

Cost componentWho is paid or who does the workOne-time or recurringWhat drives the cost
Badge or physical access system licensesAccess control vendor or reseller, or none if the system is self-hosted open sourceUsually recurring if commercial; open-source platforms remove license spend but not hostingNumber of facilities, number of doors and readers, and whether the vendor charges per credential
Building the initial access listFacility or security staff, with HR and system owners confirming who needs accessOne-timeNumber of people with physical access, number of facilities and how many records exist today
Ongoing list maintenance and credential issuanceFacility security staff and HRRecurringHiring and role change volume, contractor turnover and visitor or temporary badge use
Periodic access list reviewDesignated reviewers, often facility managers and system ownersRecurring, once per review cycleThe review frequency you set as the 03.10.01 parameter, and the number of entries each reviewer must check
Removal work during offboardingHR, facility security and system administratorsRecurring, tied to each departureSpeed of HR notification, number of physical sites, and whether removal is automated from the identity source
HR and identity integrationInternal IT or an implementation partner building connectorsOne-time build, then recurring upkeepNumber of identity sources, quality of HR data and whether a directory such as FreeIPA or an identity provider is already in place
External consulting and readiness supportImplementation partner preparing evidence, or a consultant reviewing the listUsually one-time for setup, optional recurring for supportFixed-scope written agreement versus retainer, and how many facilities are in scope
Assessor timeIndependent assessor or the federal agency reviewing evidenceRecurring with each assessment cycleNumber of facilities sampled, quality of records and how easily evidence can be produced

Who owns the access list, who helps and who audits it

Your organization owns the requirement. Your security or facilities function must decide who belongs on the access list for the facility where the system resides, approve each entry, issue credentials, and remove people when their need ends. No outside party can make those decisions for you, and the access list is only credible if it reflects choices your staff can explain. The 03.10.01 requirement also asks you to set the review frequency yourself when no federal agency has specified it, because the organization-defined parameter must have a value.

  • Approving the list: Named managers or the security office approve each individual and record who approved them and when.
  • Issuing and retrieving credentials: Badges, keys and codes are issued against the approved list and collected on departure.
  • Running reviews: Staff compare the list against current roles and remove or re-justify entries at the frequency you defined.
  • Setting the parameter: Document the review frequency in your physical protection procedures, or confirm the value with the agency that holds your contract.
  • Keeping the record: Retain approvals, review sign-offs and removal tickets as the evidence an assessor will examine.

Before relying on this tab, confirm who in your organization holds each of these duties, in writing.

Where 03.10.01 programs usually fall short

Most access list failures are not technical. They come from lists with no owner, no review cadence and no link to the people processes that create and end access. The cards below cover the gaps assessors most often find when they test 03.10.01 Physical access authorizations, with a closing action for each.

No defined review frequency

03.10.01 has one organization-defined parameter: the frequency at which the access list is reviewed. NIST does not set that value, so if the organization has not defined it, the requirement is not complete. Assessors check that a number exists, that it is written down in the policy or procedure, and that the reviews actually happened at that interval. Confirm the value with your own policy owner and record it in the system security plan.

Lists not tied to HR and badges

The access list is often built by hand from memory, so it drifts from the people who actually hold credentials. Each entry should trace to an HR start date, a sponsoring manager and a badge or key that was issued. Ask for a sample of ten badge holders and check that each one appears on the approved list with a documented approval.

Removals that wait weeks

Access that stays active after a departure is one of the most visible findings in physical access testing. The gap usually sits between the HR termination notice and the facility team, which may learn about it days or weeks later. Set a written removal trigger tied to the offboarding ticket, and test it by comparing terminated employees against active badge records at the last review.

Reviews with no recorded decisions

A review that produces no written outcome is hard to defend. Assessors look for evidence that a designated reviewer looked at each entry and decided to keep, change or revoke it, with the date and the reviewer's name. Access certification tooling such as midPoint can record those decisions with a timeframe for reviewers, which gives the review a durable record rather than an email thread.

Visitors and contractors left out

Contractors, vendors and temporary staff often receive escorted or short-term access that never reaches the authorized list. Their credentials may stay active after the work ends. Confirm whether the list covers every person with unescorted access, whether each contractor has a named sponsor and an end date, and whether the list is reconciled against contractor badge records.

List with no owner

A spreadsheet on a shared drive usually has no accountable owner, no change history and no protection against edits. When the person who maintained it leaves, the list goes stale. Name one accountable role for the list, store it in a controlled system with an audit trail, and document who may change it and how changes are approved.

Questions buyers ask about 03.10.01

How much effort does maintaining a physical access list take?

The effort is mostly recurring administration rather than a one-time build. Building the list is a single pass over people who already hold facility access, but keeping it accurate depends on how often people join, change roles and leave, and on how many entry points and credential types the facility uses. The requirement also expects a defined review frequency, and each review consumes time from the access owner and an approver. The organization sets that frequency, and NIST leaves the value to be defined through an organization-defined parameter. Ask any provider to break the effort into one-time setup and recurring review, and to state which hours fall on your staff versus theirs.

Does 03.10.01 apply to a cloud-only company with no data center?

It applies to the facility where the system resides, so the question is where your CUI-handling systems physically run and where people work with them. A company that runs everything in a public cloud still has offices, and those offices or the staff who administer the cloud environment may fall within the scope the assessor defines. The cloud provider's physical controls are generally covered through that provider's own attestations, but you still need to show how your staff and any on-premises equipment are controlled. Confirm the boundary with your contracting officer or assessor before you write the system security plan.

Can an implementation partner build the access review workflow for us?

Yes, a partner can plan, configure and document the workflow, but the organization still owns the control. The review decisions, the approval of who gets access and the review frequency must be made and signed off by your people. A partner can connect an identity source to an access certification tool, set up reminders and reviewer assignments, and produce records showing each review was completed. DeployOpen plans and implements self-hosted open-source platforms in your own infrastructure and prepares evidence for assessments, but it does not issue assessment reports or certificates. An independent assessor makes that judgment.

What does the access list need from facilities and HR staff?

The list depends on two feeds that usually sit outside IT. Facilities or physical security must confirm who holds badges, keys or other credentials and must deactivate them when access ends. HR must notify the access owner when someone joins, transfers or leaves, so removals happen promptly. Plan a short written procedure that names the owner of each feed, the trigger for a change and the record kept. Without that handoff, the directory can show a person as removed while a badge still works, which is the gap an assessor is most likely to test.

Does the Rev. 2 requirement for this control differ from Rev. 3?

The core expectation is similar, but Rev. 3 is more detailed. Under Rev. 2, the matching requirement is 3.10.1, which covers maintaining a list of authorized individuals, issuing credentials and reviewing the list. NIST's change analysis classifies the Rev. 3 change for this area as significant, because it adds more detail and foundational tasks. Rev. 3 also adds an organization-defined review frequency that you must set. CMMC Level 2 still assesses the Rev. 2 wording as PE.L2-3.10.1, and it is worth 5 points under 32 CFR 170.24, so DoD contractors should confirm which version their contract currently requires.

Will an assessor accept an open-source directory as evidence?

An assessor evaluates the evidence and the process around it, not the license of the product that produced it. An open-source directory such as FreeIPA can hold the users and groups that define who is authorized, and its access control and delegated administration help show who can change the list. The assessor will still expect an approved list, documented review records, dated removals and proof that the list reflects physical reality. Tools like midPoint can record access certification decisions, and authentik's SCIM provider can deprovision users from target applications. Confirm each capability in your own environment and test that the records export in a form an assessor can read.

How does access revocation tie into the rest of the access list process?

Revocation is where most lists fail, so treat removal as a timed workflow rather than an occasional clean-up. When a person's access ends, the directory change should remove their application access through provisioning, while facilities deactivates physical credentials. Automated deprovisioning in identity tools covers digital access only. Physical credentials still need a manual or badge-system step, and that step needs a record. Ask your provider to show a test removal that produces a log entry on both the digital and physical side.

How DeployOpen prepares access evidence for 03.10.01

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares the systems and evidence an assessment will examine for 03.10.01. Scope, deliverables and timelines are agreed in writing before work starts, so the organization knows in advance which access lists, review records and identity configurations will be produced and who owns each one. DeployOpen does not issue assessment results, attestations or certifications. An independent assessor decides whether the requirement is met, and the organization owns its controls, its facility and its physical access decisions.

In practice, the preparation work for this requirement sits in two places. The first is the authorized access list for the facility where the system resides, which the organization must approve and keep current. Where that list is held in a self-hosted identity platform, DeployOpen can help configure groups that map to facility authorizations and document who approves additions. The second is the removal step. For example, an open-source identity provider such as authentik can use its SCIM provider to deprovision users from target applications when they lose access, which supports the removal evidence an assessor will ask for. This is illustrative only: the physical access list itself is usually maintained by facilities or security staff, so the integration must be confirmed against the organization's own process and the platform's current documentation.

The review frequency is the parameter the organization must set for 03.10.01, and it is the part most often left undocumented. Before work begins, the reader should confirm the review interval with their security and facilities leads, decide who signs each review, and check whether an access certification tool such as midPoint is in scope for recording keep, change or revoke decisions. Ask any implementation partner to state in the written scope which evidence artifacts it will produce, which remain the organization's responsibility, and which items fall outside the engagement entirely.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.