Break-glass access,
with a second pair of eyes.

Why break-glass accounts are the weak point

Every mature environment keeps a break-glass path: a root account, a standing admin role, a sealed credential in the vault. It exists because during an incident there is no time to raise a ticket and wait for someone to wake up.

That urgency is exactly what makes it dangerous. The break-glass path is the one route through your infrastructure with no approval gate, no change window, and frequently no strong record of who used it or why. It is the first thing an auditor asks about and the first thing an attacker with a stolen laptop reaches for.

The usual mitigations are all after the fact — alert on use, review the logs weekly, rotate the credential afterwards. They tell you that something happened. None of them stop it happening.

Put a threshold in front of the credential

The fix is not to remove emergency access. It is to require that more than one person agrees before it opens. Two on-call engineers approving from their phones takes about thirty seconds, which is fast enough for a real incident, and it removes the single point of failure entirely — a stolen laptop, a compromised session, or one person having a very bad day is no longer sufficient.

In TeamSigner you model this as an action with a threshold. Each member holds a secp256k1 private key generated on their own phone, which never leaves the device. When someone raises a request, everyone is notified; each approval is a signature over the exact request being approved, not a click on a button that a server records. Once enough valid signatures exist, TeamSigner delivers a signed webhook to your system and your system releases the credential.

• The request is specific — the signature commits to the action, the threshold, the reason given, and an expiry. Nobody can approve "grant admin" in the abstract and have it reused later.
• The record is cryptographic — you hold signatures from named public keys, not a database row saying an approval happened. It stays verifiable independently of us.
• It expires — every request carries expires_at. An approval that sat unused overnight is not still live in the morning.

Wiring it to your access system

Your endpoint receives the approved request, verifies it, and does the actual work — assuming an AWS role, checking out a vault credential, adding someone to a privileged group for an hour. TeamSigner never holds your secrets; it only tells you, verifiably, that the team agreed.

// POST /hooks/break-glass — fires only when the threshold is met
app.post("/hooks/break-glass", async (req, res) => {
  const ok = verifyTeamSigner(req, process.env.BREAK_GLASS_SECRET);
  if (!ok) return res.sendStatus(401);

  const { canonical_message: m } = req.body;
  if (m.action_name !== "BREAK GLASS ACCESS") return res.sendStatus(400);
  if (m.expires_at * 1000 < Date.now()) return res.sendStatus(410);

  // The team agreed. Grant time-boxed access and log the reason they gave.
  await iam.grantTemporaryRole({
    principal: m.initiator,
    role: "prod-break-glass",
    ttlSeconds: 3600,
    justification: m.message,
  });
  res.sendStatus(200);
});

The full verification routine — HMAC envelope, signature checks, threshold counting — is on the <a href="/docs">docs page</a>, with copy-able Go, TypeScript, Python and Rust versions.

What this changes for an audit

Most frameworks do not mandate multi-party approval on emergency access outright, but every one of them asks how you control it and how you evidence it. Answering with "two named engineers cryptographically signed for it, here are the signatures and the reason they recorded" is a materially stronger answer than pointing at a log file that your own systems produced and could in principle have written anything into.

Common questions

Related