How should an MSP store and manage break-glass credentials for client environments?
Glassbreak Team · Published 2026-07-24
MSPs live with a paradox: the client pays them to reduce risk, while the engagement itself creates the largest concentration of it — one firm holding global-admin, firewall, and backup credentials for dozens of environments. Attackers noticed years ago; now insurers and auditors have too, and the questionnaires clients receive increasingly include a question aimed straight at you: how does your MSP manage privileged and emergency credentials for our environment? This page is a policy and register template that lets you answer it well — and turn the answer into a differentiator.
Why the usual setup fails the question
The standard MSP pattern is a shared documentation platform or password manager, with technician access governed by roles. It fails the modern question set in three specific ways:
- Single-person access. However tight the roles, some individuals can each take a client's most dangerous credential alone, silently. "Which of your staff can access our global admin?" should not have the answer "any of these nine, at any time, without anyone knowing."
- Flat blast radius. A compromised technician session or a breached documentation tool exposes every client tier at once. The credentials that can destroy a client sit in the same store as the Wi-Fi passwords.
- No evidence. When a client's auditor asks for the access history of their emergency credentials, an export of "the vault log" mixing all clients — or nothing — is the common reality.
The policy template
Adapt the following as your client break-glass policy. It's deliberately short; the structure does the work.
1. Scope & tiering. Client credentials are tiered: Tier 0 (break-glass) — tenant global admin, domain admin, firewall/root, backup console, cyber-insurance-relevant emergency accounts; Tier 1 — operational admin; Tier 2 — routine. This policy governs Tier 0. Tier 0 credentials never live in the day-to-day documentation platform.
2. Storage & release. Tier 0 credentials are stored end-to-end encrypted, segregated per client, and split so that release requires approval from at least two named individuals (quorum). No single technician — including owners — can retrieve one alone. Release triggers an immediate alert to the service-desk lead and, where contracted, to the client.
3. Register. Each client has a break-glass register recording: credential name and system, storage location, the named keyholders, quorum threshold, last rotation date, last verified-retrievable date, and each access (who, when, approved by whom, why). The register — not the secrets — is shareable with the client and their auditor on request.
4. Use & review. Every Tier 0 activation gets a post-use review within 5 business days: was the use justified, was the credential rotated, does the client need notification under the MSA or their insurance policy. Reviews are logged in the register.
5. Joiners, movers, leavers. Keyholder changes take effect the same day. A leaver's shares are revoked and reissued immediately; credentials the log shows they accessed are rotated. The register records the change.
6. Testing. Per client, at least annually: a retrieval drill proving the quorum path works and the credentials are current — ideally inside a broader tabletop exercise. The drill record goes in the register; clients pursuing certification or renewals can attach it as testing evidence.
The per-client register (columns)
| Column | Example |
|---|---|
| Credential / system | M365 tenant emergency global admin |
| Tier | 0 |
| Keyholders (shares) | J.M., A.K., R.P. (3 shares, quorum 2) |
| Last rotated / last verified | 2026-05-14 / 2026-07-02 (drill) |
| Access history | 2026-06-30 22:41 — released to J.M., approved A.K. — ransomware containment; reviewed 2026-07-03, rotated |
Why this is a sales asset, not just hygiene
Every client renewal now includes some form of the break-glass question, and most 20–200-person firms answer it badly. An MSP that can attach a per-client register showing quorum-gated storage, alert-on-access, and an annual drill is handing the client a pre-packaged "yes" — and handing their broker a reason to recommend that MSP to the next client who fails the question. The control you build for risk reasons becomes the artifact that wins deals.
How Glassbreak fits (and honest limits)
Glassbreak implements the storage model this policy describes: per-organization E2EE vaults, credentials split M-of-N across named keyholders with quorum-gated release and deletion, alert-on-access, append-only attributed logs, drills, and an exportable evidence pack per client organization. The honest limits: there is no multi-tenant MSP console yet — today an MSP operates per-client organizations, which works but scales manually; we're taking one or two MSPs as design partners to shape the multi-tenant layer rather than promising it. And E2EE cuts both ways: we cannot read or recover client material, so the recovery-kit discipline in your onboarding matters. If the register above is the artifact you wish you had, that's the conversation to start.
Frequently asked questions
- Isn't our password manager with role-based access enough?
- For day-to-day operational credentials, often yes. Break-glass material is different in kind: it's the tenant global admin, the firewall root, the backup-console master — credentials that can end a client. For those, role-based access still means some set of individuals can each, alone and silently, take the credential. The bar clients' insurers are moving to is: no single person, alert on every access, and a log the technician can't edit. That's quorum release, not another role.
- Doesn't quorum slow us down in a real emergency?
- It adds one approval step measured in minutes — from a second on-call approver with a phone. Against that, weigh what the quorum prevents: silent credential use by a compromised or departing technician, and the unanswerable audit question "who could have accessed this?" In practice, MSPs that run this model use standing on-call approver rotations so a quorum is always reachable, and they exercise the path in drills so the emergency isn't the first test.
- What happens when a technician leaves?
- With shared vaults, offboarding means rotating every credential the person could ever read — across every client — and hoping the list is complete. With per-client quorum-held material, their keyshares are revoked and reissued, the register records it, and only credentials they actually accessed (which the log shows exactly) need rotation. The offboarding burden drops from "everything, everywhere" to a known list.
- Does Glassbreak have a multi-tenant MSP console?
- Not yet — honest answer. Today each client is an organization with quorum-gated secrets, delivery/escalation, drills, and evidence packs, and an MSP can operate several client organizations. A true multi-tenant MSP admin layer is on the roadmap, and we're taking one or two MSPs as design partners to shape it. If that's you, we'd rather build it with you than promise it to you.