Your executive becomes unavailable tomorrow: who holds the digital keys?

Monday morning, 8:10. The company president will not be in this week. An accident, a health issue or a family emergency has forced them to disconnect entirely. Nothing suspicious, no cyberattack, no acrimonious departure. Just a sudden absence with no firm return date.

The team knows its responsibilities and operations should carry on. Then the obstacles appear.

The Microsoft 365 administrator account is in the president's name. Renewing the domain requires a code sent to their phone. A vendor portal uses their personal address for recovery. Nobody knows where the phone system credentials are. As for the password manager, it is properly configured — but only one person can approve emergency access.

The business is not paralyzed by its executive's absence. It is paralyzed because its digital keys were entrusted to a person rather than to a role.

The indispensable-person risk

In many smaller businesses, access concentrates without any obviously bad decision. At startup, the owner opens the accounts personally. Later, the controller takes over the financial software, an assistant handles vendors, and a consultant configures Microsoft 365. Responsibilities accumulate as needs arise, but nobody keeps a complete register.

You end up with one person who knows almost everything: where the passwords are, which vendor to call, how to renew a service, and which account holds administrative rights. That person is valuable. They are also a single point of failure.

The risk does not rest only on the owner. It can sit with:

the IT lead who holds the only administrative access;
the controller whose phone receives every verification code;
the assistant who knows the contracts and customer numbers;
the developer who controls the domain and web hosting;
the outside consultant who built the cloud environment.

A temporary absence is enough to expose the dependency. A sudden departure can make it permanent.

Microsoft describes this scenario explicitly in its own documentation: the person holding the last Global Administrator access leaves the organization, and the account is deleted or disabled on the on-premises side. The organization can then find itself unable to recover its own environment.

What are the company's digital keys?

The goal is not to list every password used by every employee. It is to identify the accesses capable of maintaining, changing or recovering essential services.

The inventory should cover at least:

Microsoft 365 or whatever identity platform the company uses;
the domain registrar and DNS management;
backups and restore tooling;
the firewall, network, Wi-Fi and remote access;
the phone system and main numbers;
accounting, payroll, CRM and line-of-business applications;
website hosting and certificates;
the team password manager;
vendor portals and critical contracts;
security, monitoring and cyber insurance accounts.

For each service, the company should know the account owner, the authorized administrators, the recovery method, whether it depends on one person's phone or email, and the procedure to follow if that person does not answer.

The exercise usually turns up surprises: a personal Gmail address, an expired credit card, a former provider still listed as an administrator, or an authentication code that can only reach a single device.

The Canadian Centre for Cyber Security recommends exactly this: create and maintain an inventory of all administrative accounts, including domain and local accounts. It also draws a clear line between emergency and temporary accounts and merely infrequently used ones — and specifies that emergency accounts should not be subject to automatic disabling or removal for inactivity. That detail looks trivial until the day a cleanup policy silently disables your safety net.

Sharing every password is not a continuity plan

The first instinct is often to put all the credentials in a document and hand it to several managers. Simple, and dangerous.

Well-designed continuity does not give everyone permanent access to everything. It preserves least privilege: each person normally uses their own account and receives only the rights their work requires.

Emergency access is a separate path. It becomes available when a defined situation occurs, for authorized people, following a documented procedure. Its use must leave a trace and trigger a review.

Put differently: you do not hide a master key under the mat. You place it in a controlled safe, you specify who may open it, and you check every opening.

A business password manager can be part of the answer, provided recovery and emergency access are configured too. A digital vault whose recovery rests with one person reproduces the exact problem it was meant to solve.

The break-glass account is no longer a password in an envelope

For the most critical systems, organizations use an emergency account — commonly called a break-glass account. It is not for daily work. It exists to regain control when the usual administrative accounts are unavailable or locked out.

If your mental image is a very long password, printed and sealed in an envelope, that image is out of date.

Microsoft has tightened its requirements. Configuring an emergency access account in Microsoft Entra now requires choosing a passwordless authentication method: a FIDO2 passkey, which is recommended, or certificate-based authentication if the organization already has a public key infrastructure. The reason is stated plainly: these are the methods that satisfy the multi-factor authentication requirements that have become mandatory.

In practice, the backup account is no longer a line of text. It is a physical object to buy, enroll and store somewhere.

Microsoft recommends maintaining at least two of them, for redundancy. They must be cloud-only accounts on the .onmicrosoft.com domain, neither federated nor synchronized from an on-premises environment — because a backup account that depends on the system that just failed is not a backup account.

Other requirements worth knowing:

A different authentication method from your regular administrator accounts. If your admins use the Authenticator app, the emergency account should use a FIDO2 key. The point is to avoid a common failure mode.
No association with an individual user or an employee-provided device — so not the president's phone.
Credentials and devices that do not expire and are not at risk of removal by an automated cleanup policy.
Storage in secure, fire-resistant safes in separate locations, accessible to authorized people. And one step almost nobody takes: changing those safe combinations when someone with access leaves the organization.
An alert on every sign-in, so that any use is noticed immediately.

The two settings that quietly disable your emergency account

These are the nastiest traps, because they stay invisible until the day they block everything.

Conditional Access. Microsoft is emphatic: emergency access accounts must be excluded from any Conditional Access policy that blocks or restricts sign-in. If the account is subject to a policy requiring multi-factor authentication, a compliant device or another control, it can become unusable during the exact emergency it was built for. The recommended approach is a dedicated security group — Microsoft suggests naming it EmergencyAccess — excluded from the relevant policies. Report-only policies do not block access and do not need exclusion.

Role assignment. In Privileged Identity Management, the Global Administrator role must be active and permanent for these accounts, not "eligible." Microsoft spells out the failure scenario: if every Global Administrator assignment is eligible rather than active, activation requires approval, and no approver is available, nobody can approve — and tenant administration is effectively locked out.

Neither setting is ever noticeable in normal operation. Both are noticeable exactly once, at the worst possible moment.

What a break-glass account does not solve

Scope matters here, because confusion creates false confidence.

A break-glass account solves regaining control of your identity platform. That is important, but it covers only part of the problem this article opened with.

There is no break-glass account for:

your domain registrar;
your phone provider's portal;
banking access and signing authority;
your line-of-business software vendor's account;
your website hosting;
your cyber insurance policy.

For those, continuity runs through administrative measures: multiple authorized contacts on file, a recovery address owned by the company rather than an individual, and an identification procedure agreed in advance with each vendor. Less technical, often slower to put in place — and where half the real blockages actually live.

Building a digital continuity kit

A digital continuity kit is not a binder full of passwords sitting in a cabinet. It is a limited set of information, procedures and secure mechanisms that let the right people take over temporarily.

It should contain at minimum:

The inventory of critical services. Which systems absolutely must stay reachable to serve customers, pay employees and communicate?
Owners and backups. Who normally manages each service, and who is authorized to step in?
The activation procedure. What circumstances permit using emergency access, and who can authorize it?
Vendor contact information. Support numbers, contract identifiers, named contacts and the escalation path.
Recovery mechanisms. Where are the security keys, the recovery codes and the protected instructions?
The limits of the intervention. Which actions may the stand-in take, and which require a second approval?
Closing out the emergency. How do you remove temporary access, rotate the secrets that were used, and review the logs afterward?

The kit has to be usable without the absent person, but inaccessible to unauthorized ones. Depending on the sensitivity of the access, you can also require two people to activate certain privileges — a practice the Canadian Centre for Cyber Security calls two-person integrity.

One detail almost nobody considers: the device used for emergency authentication should be able to communicate over at least two network paths that do not share a common failure mode — for example the building's wireless network and a cellular carrier. That is an explicit Microsoft recommendation, and it follows the same logic as genuine internet failover : your backup plan must not depend on what just went down.

Your IT provider is part of the plan — they should not be the plan

An IT partner can document the environment, monitor emergency accounts and act quickly. They should not, however, be the only holder of the company's keys.

Your organization should remain the owner of its domains, licences, data and environments. It should also know what access its provider holds, how to revoke it, and how to transfer management to another resource if needed.

The Canadian Centre for Cyber Security is explicit on this point: even when using a cloud service provider or a managed service provider, your organization remains responsible and accountable for securing its data, and the restrictions you apply to your own administrative accounts should be reflected in your service agreement with the provider.

Conversely, listing only the president as the authorized contact with your provider creates its own blockage. At least one legitimate stand-in should be able to request urgent work through an identification process established in advance.

This preparation complements the disaster recovery plan . Restoring data does not help much if nobody can open the backup console or authorize restarting the systems.

The only way to know: run an exercise

An untested plan is a hypothesis.

Pick a simple scenario: the executive and the IT lead are unreachable for 48 hours. Without using their phones, their inboxes or their memory, the team has to demonstrate it can:

reach critical vendors;
access contact information and procedures;
take over Microsoft 365 administration;
verify the state of backups;
change an urgent configuration;
communicate with employees and customers;
document every action taken.

You do not need to cause a real outage. A guided exercise already surfaces stale contact details, missing rights, and recovery methods that still depend on the wrong person.

For the technical emergency accounts, Microsoft gives a specific cadence: validation at least every 90 days. That validation is not just checking that a credential works. It includes reviewing the list of authorized people, confirming the procedure is documented and current, verifying the accounts can actually sign in and perform administrative tasks, and checking that the alerts fire.

Microsoft also recommends repeating the exercise at two other moments: when IT staff change — a termination or a role change — and when the organization's subscriptions change.

Finally, every real use of an emergency account should trigger a review afterward, to determine whether it was a planned drill, a genuine emergency where no administrator could use their regular account, or improper use. Examining the logs then confirms that the actions taken matched authorized use.

The full plan should also be revisited after a departure, a change of provider, an acquisition, or the adoption of a significant new system. The article on access to revoke when an employee leaves covers the other side of the same question: knowing how to close access matters, and knowing how to hand it over properly matters just as much.

Seven questions to ask this week

Do our domains and cloud environments officially belong to the company?
Can at least two people reach and authorize work with our critical vendors?
Does any administrative access depend on one person's personal phone or email?
Do we have a current inventory of administrative accounts?
Are our emergency accounts excluded from the policies that could block them, and is their role permanently active?
Does every use of emergency access generate an alert and a record?
Have we tested the process in the last 90 days?

If several answers are unknown, the fix is not to hand out more privileges in a hurry. It is to structure the continuity plan.

In closing

Preparing for an executive's unavailability is neither pessimistic nor impersonal. It protects the business, the employees, and the absent person from needless pressure at the worst possible time.

A well-prepared organization does not depend on a hero who knows every password. It has clear responsibilities, individual accounts, an authorized stand-in, and an emergency procedure that actually works.

So the right question is not "who knows the president's password?" It is "if that person becomes unavailable, can we carry on without bypassing our own security?"

An IT project or a question?

MMO Techno can help you inventory your critical access, structure a digital continuity plan and test your emergency procedures — while maintaining rigorous controls over administrative privileges.

Talk to an MMO Techno expert .