Emergency Access to Shared Credentials: Designing a Break-Glass Procedure

Editorial team Spend Ledger

Treat emergency access as a governance process

A break-glass procedure is a documented way for an authorised person to regain necessary business access when the usual account owner or administrator is unavailable. It is not a shortcut around platform rules, identity checks, security controls or account restrictions. Its purpose is to keep essential work moving while preserving accountability.

This matters in paid advertising, where access may span a business-level account structure, advertising accounts, billing arrangements and campaign operations. If only one person can reach a critical login, their absence can interrupt work or leave the organisation unable to respond to an account issue. Yet simply copying the password into a team chat trades one problem for a larger security and audit risk.

Start by defining what counts as an emergency. It might involve a genuine operational need, such as an urgent account-security response or essential campaign administration when the normal administrator cannot be reached. Convenience, a missed handover or a desire to avoid ordinary approval is not enough. The procedure should explain when it applies, who can invoke it, what access may be granted and how the organisation returns to normal operations.

The account must belong to the business, and the access must be consistent with the platform’s terms and permissions model. If a platform provides role-based access, delegated administration, recovery or official support routes, use those routes rather than sharing a personal login or bypassing a control. Emergency access should preserve the account’s legitimate ownership and established identity.

Map the access before an emergency

A useful plan begins with an inventory of critical business accounts and the people or roles responsible for them. Record the business purpose of each account, its place in the advertising account hierarchy, who administers it, and what work depends on it. Include the relevant business-level structure, advertising accounts, payment administration and access to records needed to operate them.

The inventory should distinguish between access that is essential and access that is merely convenient. A person handling campaign adjustments may not need authority to change billing or business ownership. Someone managing billing may not need permission to edit campaigns. Keeping these responsibilities distinct limits the impact of an emergency grant and makes it easier to review what happened.

Document the normal access route as well as the fallback. For example, note whether the team uses individual named accounts and platform-assigned roles, where recovery information is maintained, and which official channel is appropriate if access cannot be restored internally. Do not put passwords, recovery codes or identity documents in the inventory. The record should tell an authorised responder where the approved process is held, not expose the secrets themselves.

Review the inventory when responsibilities, account structures or platform requirements change. Outdated records can be as dangerous as missing ones: they may direct a responder to an old contact, grant authority to someone who no longer needs it or confuse an advertising account with the business structure that controls it.

Decide who may invoke the procedure

The procedure should name roles, not rely on one person’s informal judgement. Identify who may declare an emergency, who may approve access, and who may provide or enable it. Where possible, separate these duties so a single person cannot request, approve and conceal an access change without review.

Choose roles that are reachable and have a legitimate business reason to act. The person invoking the procedure should describe the operational problem, the account involved, why routine access is unavailable and what work must be done. The approver should confirm that the circumstances fit the written criteria and that the proposed access is proportionate. If a normal approver is also unavailable, define an alternate approval path in advance.

Do not make the process depend on personal relationships or a private message to whoever “knows the password.” A staff member’s familiarity with an account does not automatically make them authorised to use it. Equally, emergency authority should not be treated as permission to take over another person’s personal profile, impersonate an account owner or alter ownership records without proper authorisation.

Make clear that an emergency does not suspend platform rules. If the platform requires an account holder to complete a verification step, the team must follow that requirement through official means. If the authorised person cannot complete it, contact the platform through its official support or appeal channels, as appropriate, and address the underlying issue rather than looking for another route around the control.

Grant only the access needed, for only as long as needed

A break-glass grant should be limited in both scope and duration. Prefer an individual user’s own identity with the narrowest suitable role over handing out a shared password. If the platform supports temporary or readily revocable permissions, use its official access controls. If it does not, establish a documented alternative that remains within the platform’s rules and the organisation’s security requirements.

Before access is granted, confirm the person’s identity through an established internal process. Use more than an unverified chat message or an email account that may itself be compromised. The procedure should specify how an approver verifies the request, how the authorised recipient is informed and where the access decision is recorded. Avoid sending credentials through ordinary chat, email or documents that are broadly available.

State the permitted task clearly. A temporary operator might be allowed to review an account status or make a necessary operational change, but not to alter business ownership, add unrelated administrators, change payment arrangements or create new access paths unless those actions are specifically required and separately approved. The permitted work should be tied to the emergency, not used as an opportunity to reorganise the account.

When the need ends, remove temporary permissions promptly and confirm that the normal access arrangement is working again. A time limit is useful only if someone is responsible for enforcing it. Assign that responsibility when access is granted, and record who will confirm revocation. If access cannot be removed through the usual process, escalate through the platform’s official support channel and document the issue.

Record every use in an auditable log

A break-glass action should leave a clear record that another responsible person can review. The log should capture the reason for invoking the procedure, the account or business structure involved, who requested and approved access, who received it, what permissions were granted and when they were removed. Record the work performed and any material changes, without copying secrets into the log.

Use a recordkeeping location approved for sensitive business information, with access limited to people who need it. A team chat may help coordinate a response, but it should not be the authoritative audit trail and should never become a store for passwords or recovery information. If coordination occurs in chat, transfer the relevant decision and outcome to the approved record.

Keep the record factual. Note what was known at the time, what actions were taken and what remains unresolved. Do not use the log to assign blame or speculate about motives. A neutral record helps the organisation understand whether the procedure worked and gives it a basis for follow-up if the platform later asks about activity or account administration.

The log also supports internal review. After the emergency, a reviewer can check whether the invocation met the criteria, whether permissions were limited, whether changes were appropriate and whether access was removed. If the procedure was not followed, record the deviation and correct the process. A written procedure has little value if there is no way to tell how it was used.

Rotate credentials and restore normal control

After emergency access, determine whether any credential was exposed, shared or used outside its intended channel. If a password or recovery secret was disclosed, change it through the platform’s official security settings or recovery process, where permitted. Do not assume that removing a temporary user role also changes a shared credential. These are separate controls and may require separate action.

Confirm that the business retains authorised control of the account and that recovery information is current and held through approved channels. Check for unexpected administrators, permission changes, billing changes or other account activity relevant to the incident. Remove access that is no longer justified, but do not make ownership or identity changes that conflict with platform requirements. If anything appears compromised, use the official security and support routes.

Where a platform requires an individual login, keep that login individual. A shared password can make it difficult to identify who acted, complicate account recovery and expose access to everyone who has ever received the secret. If the existing setup depends on a shared credential, treat that as a control weakness to resolve through legitimate business administration, not as a reason to distribute the credential more widely.

Record credential rotation or other remediation without recording the new secret. Confirm who is responsible for maintaining it and how authorised users will obtain access in the future. Current platform requirements and security options should be checked on the platform’s own help and policy pages, since these can change.

Why chat-based password sharing fails

Pasting a password into a chat feels quick, but it creates copies that may remain in message history, notifications, exports, backups or devices outside the organisation’s control. The sender may not know who can read the conversation, whether an account is secure or whether the recipient will retain the message. Deleting a visible message does not necessarily remove every copy.

Chat sharing also weakens accountability. If several people use the same login, activity may not be attributable to a specific person. That can make internal review harder and can conflict with a platform’s expectations for individual account access. It also encourages access to persist after the original need has passed, because no one clearly owns revocation.

A better response is to use individual identities and official permissions wherever available, with an approved process for exceptional access. If the organisation must safeguard a business credential for recovery, store it through a controlled and auditable method approved by the business, restrict who can access it, and define how use is authorised and recorded. Do not send the secret itself in chat.

The goal is not to make emergencies frictionless at any cost. It is to make necessary action possible without losing control of business accounts, violating platform requirements or leaving the organisation unable to explain what happened.

Rehearse, review and improve the procedure

A procedure should be understandable before anyone is under pressure. Walk through a realistic scenario with the people responsible for invoking, approving, granting and reviewing access. The exercise can test whether the right records are available, whether alternates can be reached and whether the team understands which actions require platform support. Do not test by exposing a real password or making unapproved changes to a live account.

After a real event or rehearsal, identify gaps. Perhaps the account inventory was unclear, the approver was unavailable, the permitted scope was too broad or revocation was overlooked. Update the written process and assign responsibility for each correction. Review the procedure when staff responsibilities, advertising structures, security practices or platform rules change.

Keep the final guidance concise enough to use under pressure, while retaining the detail needed for accountability. A responder should be able to find the invocation criteria, approval route, access method, logging requirements, revocation steps and official escalation path without relying on memory.

A sound break-glass procedure is a limited exception within normal governance, not a replacement for it. It protects continuity by ensuring that business access does not depend entirely on one person, while preserving individual accountability and respect for platform controls. The safest emergency access is planned, authorised, recorded, promptly withdrawn and followed by a deliberate return to normal administration.