164.312(a)(2)(ii) emergency access procedure explained

What the 164.312(a)(2)(ii) emergency access procedure requires in practice

The rule requires a documented, implemented procedure for obtaining necessary ePHI during an emergency, and it is a required implementation specification, not an addressable one. If an audit is coming and nobody can name the path a clinician or administrator takes to reach ePHI when normal access fails, that gap is the finding. The specification exists because a locked-out administrator, a failed identity provider or a directory outage can stop clinical care just as surely as a ransomware event. The procedure has to work under pressure, yet it must stay controlled, logged and reviewed, so the difficulty lies in balancing speed of recovery against the risk of an unmanaged superuser path.

The specification also supports the emergency mode operation plan required under the contingency plan standard in 45 CFR 164.308(a)(7)(ii)(C). Your contingency plan should say which systems keep ePHI available during an outage, who can invoke the emergency path, and how that access ends. The emergency access procedure is the technical mechanism behind that plan, so an auditor will often read the two together. Confirm that the same systems and people appear in both documents.

The rule does not prescribe a tool. A break-glass account in a directory, a privileged access vault, a documented manual process with sealed credentials, or a combination may all be valid, depending on what your risk analysis shows about your systems and staff. Make the choice explicitly and record why it is reasonable for your environment. Then test it, record the test, and confirm that every emergency use leaves a trail that your information system activity review will examine. Ask your implementation partner or assessor to walk through one real scenario with you before the audit does.

Which systems, accounts and teams the emergency access procedure covers

The emergency access procedure is only as good as its scope. Each decision below determines which paths must exist, who may use them and which parties must be bound by them. Start from your own risk analysis and system inventory, not from a generic list.

Systems holding ePHI that need a path

List every system that stores or processes ePHI and ask what a clinician or operator would need if normal login failed during an outage. The EHR, clinical databases, reporting stores and backup catalogs are the usual candidates. For each one, record whether the emergency path is a local account, a vendor break-glass feature or a restored copy, and confirm the system can actually be reached when the identity provider is down.

Identity provider and key management

The identity provider and the secrets store are often the single points of failure that make other systems unreachable. Decide how administrators reach them if federated sign-in fails, and where the emergency credentials for these two components are kept. Document who can unseal or recover them. OpenBao, for example, can generate short-lived credentials with leases that revoke automatically, which limits how long an emergency secret stays useful.

Privileged and service accounts

Break-glass access usually targets administrator, root and service accounts rather than end users. Inventory these accounts, confirm each has a named owner, and check whether any shared or embedded credentials exist in scripts, configuration or repositories. Repository secret scanning can help find credentials that should never have been committed, but it does not replace an inventory of emergency accounts.

Clinical and operations teams

Decide which roles may invoke the emergency procedure, such as on-call clinical informatics staff, senior nurses or incident commanders, and which must never be able to. Map each role to the systems it needs during an emergency, and confirm that the emergency path does not grant broader rights than the role's normal duties. Training on the trigger conditions matters as much as the account itself.

Managed service providers and hosting vendors

If a managed service provider, hosting vendor or subcontractor holds break-glass credentials, the procedure extends to their staff. Confirm in writing who holds each credential, how the vendor records its use, and how the covered entity or business associate is notified. Business associate contracts should reflect these duties, and the vendor's own emergency access must be reviewed on the same schedule as internal access.

Backup stores and recovery systems

Backup repositories and disaster recovery environments hold complete copies of ePHI and are often reached through separate administrative paths. Include them in scope so that restoring data during an emergency does not require an untracked account. Check that the recovery credentials are stored apart from the systems they restore and that their use is logged for later review under the audit controls.

How an assessor tests emergency access and what evidence passes

This table compares what an assessor does, what they ask you to produce, and where emergency access procedures typically fail. Read each row as a question the assessor will ask, with the evidence that answers it. The main takeaway is that a written procedure alone does not pass; it must be exercised, logged and reviewed.

Test area	What the assessor does	Evidence that passes	Common findings
Written procedure	Reads the emergency access procedure and checks that it links to the emergency mode operation plan in the contingency plan	Procedure that names who may invoke emergency access, when, and how it connects to the contingency plan	Procedure exists on paper only, with no reference to the contingency plan
Tabletop or live walkthrough	Asks staff to run a break-glass scenario and observes whether they can obtain necessary ePHI	Dated walkthrough record, participants, steps taken and timing, with any gaps logged as corrective actions	Staff cannot locate the credentials or the approver, and the scenario is never repeated
Break-glass event sampling	Selects recorded emergency access events and compares them with logs and approval records	Log entries tied to a named individual, a documented reason, an approver and a closure record for each event	No logging of emergency use, or logs that do not identify the person who used the account
Review after use	Checks whether each emergency event was reviewed by someone other than the user	Post-event review tickets showing what was accessed, whether access was justified and any follow-up	No review after use, or reviews that are signed off by the same person who used the access
Review cycle for emergency accounts	Checks that emergency accounts and their credentials are included in periodic access reviews and rotation	Access review listings that include emergency accounts, with dated sign-off and rotation records	Emergency accounts omitted from access reviews because they are treated as outside normal scope
Shared or standing credentials	Looks for shared emergency logins and credentials that stay active between events	Individually assigned emergency identities or time-limited credentials that are disabled after use	One shared password known to several staff and never changed
Technical controls	Confirms the emergency path works with the systems that hold ePHI and is limited to the intended systems	Configuration exports, system tests and a list of systems the emergency path covers	Emergency path covers systems not in the risk analysis, or fails for key ePHI systems
Ask your reviewer or auditor	Confirms what sampling size and evidence period they will apply before testing begins	Written confirmation of scope, sample selection method and evidence window from the assessor	Evidence collected for a period or system the assessor does not test

How to implement an emergency access procedure step by step

This sequence turns the emergency access requirement into a working procedure: defined scenarios, a controlled access mechanism, approval rules, logged use, a tested runbook and a post-use review that closes every emergency session.

Confirm systems and emergency scenarios
Start from your risk analysis and contingency plan. List every system that stores or processes ePHI, then identify the emergency scenarios that could block normal access, such as an identity provider outage, a lost administrator credential or a ransomware event that takes down directory services. Ask the security official and system owners to sign off on this list. The output is a scoped inventory of ePHI systems and the emergency scenarios each one must survive, linked to the emergency mode operation plan in the contingency plan standard (45 CFR 164.308(a)(7)(ii)(C)).
Choose the access mechanism
Select how emergency access will be obtained. Common options are sealed break-glass credentials held in a physical or logically separated vault, or a secrets manager that issues short-lived access on request. OpenBao, an open-source secrets manager under the MPL-2.0 license, can generate dynamic credentials with leases that expire automatically and can revoke individual secrets or whole credential trees. Confirm with your platform team which features your chosen version supports before you rely on them. The output is a documented mechanism, a list of accounts it covers, and a decision record explaining why it was chosen.
Define approval and activation rules
Write the rules for who may request emergency access, who must approve it, how activation is recorded and how the emergency is declared and closed. Separate the people who can activate access from the people who review it where your staffing allows. Define what counts as an emergency so staff do not use the procedure for convenience. Name the minimum information each request must contain, such as the incident ticket and the systems involved. The output is an approved written procedure that the workforce can find during an outage.
Configure logging and alerting on use
Configure audit logging so every emergency credential request, activation, session and revocation is recorded with a unique user identity and timestamp. Forward these events to your central log platform and create alerts that notify the security team the moment emergency access is used. Confirm that the logs cannot be altered by the people who use the access. The output is a tested alert, a log sample from a test activation and a configuration record that links the logs to the audit controls standard (164.312(b)).
Test the procedure in a controlled exercise
Run a planned exercise in a non-production or scheduled window. Simulate the loss of normal access, follow the written procedure from request to activation, confirm that ePHI is reachable for the authorized purpose, and confirm that the alert fired. Record what worked, what was slow and what was unclear, then correct the procedure. Testing against your own environment is what shows the procedure works, so ask your implementation partner or internal team to document the results. The output is a signed test record with findings and corrective actions.
Set post-use review and revocation
After every real or test activation, review the session logs against the incident ticket to confirm the access was needed, limited to the required systems and used for its stated purpose. Revoke the credential or rotate the break-glass secret, and confirm revocation in the system. Record the review outcome and any follow-up actions. Review the procedure itself on a schedule you define in your policies. The output is a completed review checklist for each activation and an updated procedure when lessons are learned.

Evidence that proves the emergency access procedure works

The procedure itself is only the start. An assessor will look for a chain of records showing the procedure was written, the accounts it covers are known, each use was approved and logged, and the team tested it and learned from every activation. Keep these artifacts current between audits, not just in the month before one.

Written emergency access procedure

The written procedure states who may invoke emergency access, which systems and ePHI it covers, how access is granted and ended, and how it links to the emergency mode operation plan in the contingency plan standard (45 CFR 164.308(a)(7)(ii)(C)). Check that the document names the current system owners and that it is reviewed whenever the contingency plan or system inventory changes. Ask the team to walk you through the procedure from an activation request to revocation, and confirm each step matches the document.

Emergency account inventory

Maintain a register of every break-glass account, shared administrator, or emergency mechanism that can reach ePHI. Each entry should record the system, the named owner, where credentials are stored, who can retrieve them, and when they were last rotated or tested. Inventory checks should run on a fixed schedule and compare the register against directory and system account lists, so accounts created outside the process are caught. Confirm that no emergency account is also a daily-use account.

Activation and approval records

Each activation should produce a ticket or form that records the reason, the requester, the approver, the systems accessed, the time window and the justification. Approval should come from a person who is not the requester where the environment allows it. Auditors test whether activations follow the documented path, so look for missing approvals, retroactive entries and activations with no linked incident. Ask whether the approval workflow still works when the ticketing system itself is down.

Break-glass event logs

Logs from every emergency account should go to a central store that the emergency account users cannot edit. They should capture logins, privilege use, data access and session start and end times, tied to the activation record. This is the audit control evidence that shows what was done during the emergency. Confirm log retention is long enough for your review cycle, and test that an alert fires when an emergency credential is used outside an approved window.

Post-event review records

After each activation, a reviewer should compare the logged actions against the approved purpose, record any out-of-scope activity, and decide whether credentials must be rotated. Keep the signed review with the activation record and link it to any incident or change ticket. Reviews are where gaps in the procedure surface, so track findings and their closure dates. An activation with no review is a finding in most assessments.

Test and tabletop records

Run emergency access drills on a set schedule, including a live test that uses an emergency account in a non-production environment and a tabletop exercise that walks through an outage with staff who would really invoke the procedure. Record the scenario, participants, time to access, failures and corrective actions. Testing also confirms the emergency credentials still work, which is easy to lose track of when passwords or identity providers change. Ask the team what the last drill exposed and how it was fixed.

What meeting emergency access requirements costs in money and effort

This table compares each cost component of an emergency access procedure, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Read it as a checklist for building a quote, since most of the spend comes from integration and review work rather than from the secrets software itself. The main takeaway is that self-hosted open source can remove license spend, but the configuration, testing and log review effort recurs for as long as the procedure exists.

Cost component	One-time or recurring	What drives it up or down, and how to keep it down
Tooling or licenses	Recurring if commercial; none for OpenBao (MPL-2.0)	Commercial vaults price by user, secret or node count. Self-hosting OpenBao removes license spend, but ask any implementation partner to quote hosting, backup and patching separately.
Engineering time to configure the mechanism	One-time, with later changes	Rises with the number of emergency paths, databases, cloud accounts and identity providers to integrate. Keep it down by limiting break-glass paths to a few documented, centrally managed methods.
Identity integration and hardening	One-time, plus recurring change work	Rises when break-glass access must work during an identity provider outage, which needs a separate authentication path. Plan this early, because retrofitting it is costlier.
Documentation and procedure writing	One-time, with annual or event-driven updates	Rises with the number of systems holding ePHI and the number of roles that can invoke emergency access. Keep it down by writing one procedure that covers all systems and naming the owner of each step.
Testing and tabletop exercises	Recurring	Rises with the number of systems in the test and the number of staff who must practice the procedure. Keep it down by rotating scenarios and testing the most critical systems first.
Log review and evidence upkeep	Recurring	The largest ongoing cost. Rises with the volume of emergency sessions and the number of logs to reconcile. Keep it down by alerting on every break-glass use so reviews focus on exceptions.
Staffing for access reviews	Recurring	Depends on who reviews each emergency session and how quickly. Keep it down by naming a reviewer outside the team that used the account and setting a review routine that fits existing staff time.
External testing or review	Periodic, scoped per engagement	Rises with the scope of the test and the number of emergency paths tested. Agree the scope in writing before work starts and ask the provider to confirm which findings it will retest.
Auditor sampling	Recurring, per assessment cycle	Rises when the procedure has gaps in its records. Keep it down by keeping each emergency session tied to a ticket, a named user and a review record that an auditor can sample.

How OpenBao and GitLab secret detection support emergency access evidence

Emergency access under 164.312(a)(2)(ii) depends on credentials that are held securely, released only when needed and removed afterward. The two tools below can produce records that support that story, but they supply evidence only. The procedure, approvals and periodic review remain the covered entity's or business associate's responsibility.

OpenBao secrets storage

OpenBao is an open-source, MPL-2.0 licensed secrets manager that keeps secrets encrypted in one place. For emergency access, the useful capability is that it can issue dynamic, short-lived credentials for systems such as databases, so a break-glass login does not rely on a standing shared password. Each secret carries a lease that revokes it automatically on expiry, and single secrets or whole trees can be revoked after use. Confirm with the vendor how break-glass workflows, approval steps and audit logging are configured in your version before you cite them as evidence.

Time-limited break-glass credentials

Lease-based issuance supports the idea that emergency access is granted for a defined window and then ends. An assessor will ask who could request an emergency credential, how it was approved, when it expired and whether it was revoked after the incident. Lease records and revocation events can answer those questions if they are retained and reviewed. Ask your platform team which events are logged, where they are stored and who can alter them.

Pipeline secret detection in GitLab

GitLab Community Edition, licensed under MIT, includes pipeline secret detection in every tier. It scans files committed and pushed to the repository in a CI/CD job and writes the results to a gl-secret-detection-report.json job artifact. This helps show that emergency credentials, such as database passwords or service tokens, are not hardcoded in source code, configuration or infrastructure definitions. Confirm the scan covers every repository that holds system configuration and that findings are triaged, not just generated.

Retained scan reports as evidence

A scan report proves little on its own. Assessors look for a pattern: scans run on each relevant change, reports are kept for the period your retention policy sets, and detected secrets are rotated and tracked to closure. Store the JSON artifacts with your contingency plan records so they can be pulled during an audit or after an emergency access event. Ask whether your GitLab version and configuration retain artifacts for the period your policy needs.

Ownership of the procedure

Neither tool decides who may use emergency access, when it may be used or how it is reviewed. The covered entity or business associate must document the procedure, tie it to the emergency mode operation plan under 164.308(a)(7)(ii)(C), and review break-glass use on a schedule it sets. Use the tools to show what happened, and use your own records to show the procedure was followed. An implementation partner can help configure and document these controls, but the organization owns the outcome.

Who owns emergency access, who can help, and where the auditor stops

The covered entity or business associate owns the emergency access procedure. Under 45 CFR 164.312(a)(2)(ii), the organization must establish, and implement as needed, procedures for obtaining necessary ePHI during an emergency. No vendor or consultant can accept that duty on your behalf, so internal roles must be named and documented before an emergency occurs.

Compliance owner: Holds the written procedure, confirms it matches the contingency plan and the emergency mode operation plan in 45 CFR 164.308(a)(7)(ii)(C), and tracks open review findings.
Security engineers: Define who may invoke break-glass access, which systems are covered, how credentials are issued and how each use is logged and alerted.
System owners: Approve which ePHI sources fall under the procedure and confirm that the access granted matches what clinical or operational needs require.
Reviewers: Examine each break-glass event after the fact, record whether the emergency was genuine and close out any anomalies.
Training and drills: Ensure staff know when the procedure applies and that tests occur on a schedule your risk analysis supports.

Before you engage anyone, confirm that these roles exist with named individuals and that the procedure is approved by someone accountable for it.

Common questions about emergency access cost, effort and outsourcing

How much effort does an emergency access procedure take and what drives it?

The written procedure itself is usually modest work, but the effort grows with the number of systems holding ePHI, how many break-glass paths exist, and how many approval and review steps the organization wants. Effort rises when each system has its own local administrator accounts, when vendors hold access to production, or when logs from emergency sessions are spread across tools. The main cost is the time from the people who know the systems and can decide who may invoke emergency access, then test it and keep the records current. Ask any implementation partner to price the work from a written list of systems and paths, not from a headline figure.

Can a small practice write and run an emergency access procedure in-house?

Often yes, if the practice has a small number of systems holding ePHI and a named person who understands them. The rule requires the procedure to exist and be implemented as needed, not a specific tool, so a clear written process, a sealed record of who holds emergency credentials, and a documented review after each use can be workable without outside help. Practices with a hosted electronic health record, a single practice management system and a managed IT provider often rely on the vendor's emergency access features and contract terms. Outside help is most useful for checking that the procedure really works during a test, not for writing it.

What does the organization need to provide before any work starts?

The organization needs to name owners who can decide and sign off, including a security official, a system owner for each ePHI system, and someone authorized to approve an emergency invocation. It also needs a current inventory of systems that hold or transmit ePHI, with the accounts that can reach them and where credentials are stored. Leadership must make decisions on who may trigger emergency access, how long it lasts, and what review follows. Without these inputs, any partner will spend its time discovering the environment rather than preparing the procedure and evidence.

How long does it take to get emergency access evidence ready?

The timing depends on what drives the work rather than on a fixed duration. The main factors are how many systems need an emergency path, whether existing break-glass accounts are already documented and tested, how quickly decision-makers can approve a design, and whether logs from emergency sessions are retained and reviewed. An organization with mature identity and logging tools usually moves faster than one that must first build them. Ask for a schedule tied to the written scope and agreed milestones, and confirm which steps depend on the organization's own approvals.

Do I need a secrets manager to meet the emergency access requirement?

No. The rule does not name a product or require a secrets manager. It requires that procedures exist for obtaining necessary ePHI during an emergency, and that the organization can show how those procedures are used and controlled. A secrets manager such as OpenBao can help by storing break-glass credentials encrypted in one place and issuing short-lived credentials with leases that expire, but the procedure, the approval steps and the review of logged emergency sessions are still required. Organizations without a secrets manager can meet the requirement with sealed credentials, documented approvals and reviewed access logs, provided the process is consistent and testable.

Is there an official HIPAA certification that covers emergency access?

No. There is no HIPAA certification. HHS has stated that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that such certifications do not stop HHS from finding a violation later. Independent assessors and auditors can test evidence against the requirement, including whether an emergency access procedure is written, implemented and reviewed, and they issue their own reports. Anyone offering a HIPAA certificate should be asked what they actually test and which report, if any, they issue. Neither a certificate nor an implementation partner replaces the organization's own accountability for the control.

How DeployOpen scopes and prepares emergency access evidence

DeployOpen helps organizations set up the emergency access procedure in their own environment, inside their own cloud accounts, data centers or air-gapped networks. The organization owns the procedure and its decisions, and DeployOpen prepares the systems and records that show how emergency access works and how it is reviewed.

How we scope

Engagements are fixed-scope, with the systems holding ePHI and the emergency access paths agreed in writing before work starts.
The written scope lists which break-glass accounts, secrets stores and admin paths are in and which are out.
Scope also names who approves emergency use and which contingency plan emergency mode operation it supports.

How we build

Emergency credentials are configured so they are issued only on defined triggers and are kept separate from routine user accounts.
Short-lived credentials and automatic lease expiry are set up where the chosen platform supports them, and this is confirmed during build.
Usage alerts and logging are configured so every emergency access event is recorded and can be traced to a named person.

How we hand over

Deliverables include the written emergency access procedure, configuration records and a sample review workflow for each emergency event.
Testing results from break-glass exercises are documented, including what worked, what failed and what was corrected.
The organization receives the evidence set so its own staff and any independent assessor can trace each control to a record.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer support can cover periodic break-glass exercises and reviews of emergency access logs.
Ask us to confirm which platform versions and features are supported before you rely on them for your procedure.