The Response Plan Was Approved.
Could Anyone Execute It?

The previous publication, “The Control System Obeyed. The Process Failed.”, examined how unauthorised digital instructions can make a physical process unsafe even while its controls remain responsive. The focus here turns to human intervention in IT environments: once a protective action has been authorised, can the responder still reach and use the required control when normal identity, authentication or supplier access is unavailable?

An emergency account can exist while still depending on the identity provider, device or approval service that has failed. A useful rehearsal follows one approved intervention through privileged sign-in, application of the restriction and confirmation of its effect. The missing dependency must be part of that rehearsal.

The next publication, "The Internal Report Was Clean. The Business Still Stopped.", examines a different dependency: a critical external service whose unavailability can interrupt the business while local systems remain healthy.

Microsoft’s guidance for emergency access in Entra ID identifies several routes to administrator lockout: an unavailable federated identity provider, unavailable multifactor authentication, or privileged-role activation with no available approver. An organisation can therefore have an approved response while its administrators cannot sign in to carry it out.

The immediate problem is the route between the person and the control. A responder may be authorised to suspend a suspect connection, but the account, authentication method or management service needed to do so is unavailable. Calling another decision-maker does not restore that route.

Emergency access, often called break-glass access, provides an exceptional administrative route when ordinary access cannot be used. Its value depends on which failure it can survive and which controls it actually reaches.

Choose a representative restriction and a specific access failure. A controlled exercise should establish four observable results, using a safe test environment or a defined test scope that avoids unintended service disruption.

• The authorised responder is identified. A named person can obtain the emergency access material through the approved process while the normal route is unavailable. A shared emergency account does not remove the need to identify who used it.

• Privileged sign-in succeeds through the intended alternative. The responder reaches the required management function with the necessary permissions, without silently restoring the dependency the exercise assumes is missing.

• The defined restriction is applied. The control accepts and enforces the intended change on the relevant target. Reaching a dashboard or completing sign-in is only part of the exercise.

• The effect is confirmed. The team checks that the targeted access or activity has stopped and examines the service consequence. If the usual monitoring route is unavailable, the plan needs another reliable way to establish the result.

Record where the sequence fails. A credential that cannot be retrieved, a role that cannot be activated and a restriction that produces no confirmed effect need different remedies. An exercise that ends at successful sign-in can leave the operational failure undiscovered.

Emergency administrative rights may be broader than the intervention your organisation has approved. Preserve the boundary around the specific action, including when a different decision-maker must become involved. The existing authority discussion is developed in The First Hour: Who Is Allowed to Act?

The narrowest technically available action may still carry a serious business consequence. Revoking an account used by several services could interrupt them all. Disconnecting a supplier route might remove remote support for a critical function. Your response arrangements need to recognise those dependencies instead of assuming that a small technical change creates a small operational impact.

Where a supplier holds the control, the exercise must establish whether the customer can apply the restriction or needs the supplier to execute it. Test the actual contact and access arrangement. An agreement that names a responsibility cannot substitute for a reachable operator and a usable control. Restoring the supplier’s underlying service remains a separate task.

Human emergency access and deployed automatic containment perform different jobs. Within the supported layers it protects, our platform’s Ransomware Containment automatically isolates the responsible user or session when active encryption is detected. Its operation follows the deployed capabilities and configuration.

That response can interrupt supported malicious activity while responders work on the wider incident. It does not recover an unavailable identity provider, supply break-glass access or restore an external supplier’s service. Equally, a working emergency account does not itself detect and contain malicious activity. Check each capability and its dependencies in the environment where it will operate.

After the exercise or real use, review who accessed the emergency account, what changed, whether the intended effect was confirmed and which temporary restrictions remain. Retain the relevant records securely and resolve any credential exposure according to your procedures. Returning to ordinary administration should leave the emergency route available for its intended purpose.

Your executive team needs the outcome of that demonstration: the access failure assumed, the intervention attempted, the result established and any gap still owned by a named team. Those details show which response commitments are executable under the tested conditions.

Take one approved response from the plan and rehearse it with a normal access dependency deliberately unavailable. The result should show whether the authorised responder could reach the relevant control, make the defined change and confirm what it did. Any untested dependency remains a limit on that assurance.

A focused conversation about our platform can clarify which malicious activity its deployed capabilities can contain and which access dependencies need separate arrangements in your environment.

"The Internal Report Was Clean. The Business Still Stopped." turns to the work your organisation must sustain when a critical external service is unavailable. Even with usable local controls, the technical restoration path may belong to someone else. The next article examines the operating choices that remain within your own responsibility.