Emergency access during a production outage is the controlled ability for specifically authorized people to make urgent physical or logical changes needed to restore a system. For cmmc emergency access during production outage situations, CM.L2-3.4.5 requires the organization to define who may act, document the restrictions, approve the access process, and enforce it—even when normal change windows and standard approvals cannot be followed. An outage is not a blanket permission for any administrator to make any change.
What does CM.L2-3.4.5 officially require?
NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice CM.L2-3.4.5 state:
“Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.”
This requirement sits within configuration management. Its purpose is straightforward: changes to servers, network devices, cloud services, applications, software libraries, firmware, and other organizational systems should be made only by people who are authorized to make them, using approved paths and under defined conditions.
- Define: Decide which roles can make which types of changes. For example, a network engineer may modify firewall rules, while a database administrator may change database configuration but not production identity-management settings.
- Document: Put those decisions into policies, change procedures, access-control standards, role descriptions, system inventories, and emergency-change records. An assessor should not have to rely on verbal explanations.
- Approve: Have management or an authorized system owner approve the restrictions and the emergency process. Approval can include pre-approving a limited break-glass role for use during declared incidents.
- Enforce: Configure technical and physical controls so that unauthorized people cannot simply bypass the process. Written rules alone are not sufficient.
For a COO or finance leader, the important distinction is that this is not primarily a requirement to buy an expensive emergency-access product. It is a requirement to demonstrate that urgent changes remain governed, traceable, and limited to qualified personnel. Technology may support that evidence, but clear ownership and repeatable operating procedures are equally important.
How does cmmc emergency access during production outage work?
CM.L2-3.4.5 does not use the phrase “emergency access” as a separate permission category. Instead, it governs access restrictions associated with all system changes, including changes made under pressure during an outage. A compliant organization can allow emergency changes, but it must define the conditions under which that access is used and preserve accountability for what happened.
In practice, an emergency change process usually begins when an authorized incident leader declares that a production outage, security incident, or serious service degradation requires immediate action. The organization may temporarily permit an approved administrator to use elevated access, bypass a normal change window, or make a narrowly scoped configuration change. That does not mean controls disappear.
A defensible emergency process normally includes:
- A defined list of roles permitted to authorize an emergency change, such as the CIO, IT director, incident commander, or designated system owner.
- A defined list of qualified technical roles permitted to perform the change, such as a senior systems administrator, cloud engineer, network engineer, or managed service provider contact.
- Restricted access mechanisms, such as Microsoft Entra Privileged Identity Management, CyberArk, Okta privileged access workflows, a managed jump host, or time-limited administrator credentials.
- A record of why the emergency occurred, what was changed, who authorized it, who performed it, and when normal review occurred afterward.
- A post-incident review to confirm the system is stable, identify undocumented follow-up work, and revoke temporary access if it is no longer needed.
The process applies to both logical access and physical access. Logical access includes logging into a production server, changing a cloud security group, updating a firewall policy, installing a patch, modifying source-code deployment settings, or updating a software library. Physical access includes entering a server room, connecting directly to network equipment, replacing a failed storage device, or using a console connection to restore a system.
The requirement is triggered whenever someone needs access in order to make a change to an organizational system. It applies during normal maintenance, scheduled deployments, urgent vulnerability remediation, and production outages. The urgency may change the approval timing, but it should not eliminate authorization, logging, or later review.
What does compliant emergency access look like in practice?
An assessor is not looking for a perfect outage response. They are looking for evidence that the organization’s stated restrictions actually work. The following examples show what an assessor would generally recognize as credible implementation evidence for CM.L2-3.4.5.
| Scenario | Access restriction and emergency action | Evidence an assessor can review |
|---|---|---|
| Azure production application outage | Only members of the Production-Cloud-Admins group can activate Global Administrator or Contributor access through Microsoft Entra Privileged Identity Management. Activation is limited to two hours, requires a ticket number, and sends an approval alert to the IT director. |
Entra role settings, eligible-user list, PIM activation logs, ServiceNow incident ticket, and post-incident review record. |
| Firewall failure affecting customer connectivity | A designated network engineer connects through a monitored jump host to update a Palo Alto Networks firewall policy. Direct administrator login from ordinary workstations is blocked, and only network-team accounts can access the firewall management interface. | Firewall administrator role configuration, jump-host logs, badge or VPN logs, approved emergency-change procedure, and the recorded policy change. |
| Failed server hardware in an on-premises rack | Only facilities-approved IT staff and a contracted data-center technician can enter the server room using badge access. The technician may replace failed hardware but cannot alter system configuration without a systems administrator directing the work. | Badge-access roster, visitor log, vendor authorization record, hardware maintenance ticket, and system restoration notes. |
| Critical software library vulnerability | Developers cannot directly update the production application server. An authorized release engineer uses an approved CI/CD pipeline in GitHub Actions or Azure DevOps, with production deployment rights limited to the release-management group. | Repository permissions, deployment workflow settings, pull-request record, vulnerability ticket, deployment logs, and emergency approval. |
A small contractor does not need every tool in this table. A managed service provider may operate some of the controls, but the organization remains responsible for ensuring its provider personnel are identified, authorized, and governed by the same restrictions. Contract language, access rosters, service tickets, and periodic access reviews can help demonstrate that responsibility is being managed.
For budget planning, focus on whether the organization can answer four questions with evidence: Who can make emergency changes? What systems can they change? How is access technically limited? How can management reconstruct the decision afterward? If the answer depends on an individual’s memory or an informal text message, the process is likely too weak for a CMMC assessment.
What records should leadership expect to see after an emergency change?
Leadership does not need to approve every technical command during an outage, but it should require enough documentation to show that emergency access was controlled. A practical emergency-change record may contain the following information:
Incident ID: INC-2026-0717-042 System: Production customer portal / Azure App Service Business impact: Customer login unavailable for 38 minutes Emergency approver: Director of IT Operations Authorized implementer: Senior Cloud Engineer Access method: Entra PIM, Contributor role, 2-hour activation Change performed: Rolled back application configuration to version 4.18.2 Start and end time: 14:08 UTC to 14:31 UTC Validation: Synthetic login test and application health check passed Follow-up review: Scheduled for next business day Temporary access revoked: 14:34 UTC
That record does not need to be created before restoring a critical system if doing so would delay recovery. However, the organization should define when the record must be completed and who reviews it. Many organizations require retrospective documentation within one business day and management review within a defined period, such as three to five business days.
FAQ
Does CM.L2-3.4.5 require a break-glass account?
No. CM.L2-3.4.5 does not specifically require a break-glass account. It requires defined, documented, approved, and enforced access restrictions for system changes. A tightly controlled break-glass account can support compliance when it is limited, monitored, protected with strong authentication, and reviewed after use.
Can an administrator make an emergency change without prior approval?
Possibly, if the documented emergency-change procedure allows it for defined circumstances. The organization should identify who may declare an emergency, which roles may act, what access is permitted, and how retrospective approval and review will occur. “The administrator believed it was urgent” is not, by itself, a sufficient process.
What is the difference between emergency access and emergency change management?
Emergency access is the ability to obtain the physical or logical permissions needed to make a change. Emergency change management is the broader process for authorizing, recording, implementing, validating, and reviewing that change. CM.L2-3.4.5 focuses particularly on the access restrictions that make emergency change management enforceable.
Do managed service providers need to follow our emergency access restrictions?
Yes. If a managed service provider can change systems that process, store, or protect CUI, its personnel should be included in the organization’s authorized-access model. The company should be able to show which provider roles have access, how that access is approved, and how provider emergency activity is logged and reviewed.
Next step: Ask your IT leader to provide one recent emergency-change record and verify that it shows authorization, restricted access, technical logs, and post-incident review before allocating budget for additional compliance tooling.
