{
 "slug": "provable-break-glass",
 "topic_id": "TOPIC-220",
 "cluster": "Enterprise IGA, Access Certification & Identity Lifecycle",
 "tier": "Tier B",
 "title": "Break-glass in the enterprise: the account that defeats every other control",
 "summary": "Every organisation keeps emergency accounts exempt from conditional access, MFA policies and monitoring, because those controls can fail. The exemption is necessary; its use is unprovable.",
 "lede": "Ask a security architect to describe their identity controls and they will give you a coherent, layered answer. Ask what happens when the identity provider is down and the answer involves a safe, an envelope, and a logbook.",
 "date": "2024-06-03",
 "category": "Compliance",
 "author_id": "nadia-ferreira-strand",
 "tags": [
  "break glass",
  "emergency access",
  "identity provider outage",
  "privileged access",
  "business continuity",
  "attribution"
 ],
 "image_title": "Provable Break Glass",
 "schema": "Article",
 "key_takeaways": [
  "Break-glass accounts must work when the identity infrastructure does not, so they are deliberately excluded from the controls that would attribute their use.",
  "Cloud identity provider outages have made this an operational rather than theoretical concern.",
  "Two hardware signatures over a canonical incident statement, verified offline, preserve the purpose while restoring attribution."
 ],
 "body": [
  {
   "type": "h2",
   "text": "Prerequisites"
  },
  {
   "type": "diagram",
   "kind": "flow",
   "alt": "The account that exists to bypass everything",
   "caption": "Each property is deliberate. Together they describe the most attractive target you own.",
   "nodes": [
    {
     "label": "Bypasses conditional access",
     "note": "by design"
    },
    {
     "label": "Bypasses approval workflow",
     "note": "by design"
    },
    {
     "label": "Protected by a typed reason",
     "note": "free text",
     "bad": true
    },
    {
     "label": "Reviewed afterwards, if at all",
     "note": "a log entry",
     "bad": true
    }
   ]
  },
  {
   "type": "ul",
   "items": [
    "Your current emergency access procedure, including where credentials are stored and who can retrieve them.",
    "The exemption list: which conditional access policies, MFA requirements and monitoring rules these accounts bypass.",
    "Your last twelve months of break-glass invocations, if they were recorded."
   ]
  },
  {
   "type": "h2",
   "text": "Step 1 — Enumerate the exemptions honestly"
  },
  {
   "type": "p",
   "html": "Emergency accounts are exempt from the controls that could prevent their use during an outage. List them explicitly; most organisations have never written the list down in one place."
  },
  {
   "type": "table",
   "head": [
    "Control",
    "Emergency account status",
    "Why"
   ],
   "rows": [
    [
     "Conditional access policies",
     "Excluded",
     "Policy evaluation may be unavailable"
    ],
    [
     "MFA enforcement",
     "Excluded or using a non-federated factor",
     "The MFA service may be the outage"
    ],
    [
     "Session monitoring",
     "Frequently excluded",
     "Monitoring pipeline may depend on the same platform"
    ],
    [
     "Privileged session recording",
     "Sometimes excluded",
     "Recording infrastructure may be unavailable"
    ],
    [
     "Automated deprovisioning",
     "Excluded",
     "The account must not expire"
    ]
   ]
  },
  {
   "type": "p",
   "html": "Each exclusion is individually justified. Collectively they describe an account with the highest privilege in the estate and the least oversight, which is exactly what an attacker would design if given the chance."
  },
  {
   "type": "h2",
   "text": "Step 2 — Test whether use is attributable"
  },
  {
   "type": "p",
   "html": "Run this as a tabletop. Someone used the break-glass account at 02:40 on a Sunday. Answer, using only records:"
  },
  {
   "type": "ol",
   "items": [
    "Which human retrieved the credential?",
    "Was a second person present, as the procedure requires?",
    "What did they do with it?",
    "Who authorised the use?",
    "Can any of the above be demonstrated to an auditor who assumes nothing?"
   ]
  },
  {
   "type": "p",
   "html": "In most organisations the honest answers are: the logbook says, probably, partially from cloud audit logs if those survived the outage, nobody formally, and no."
  },
  {
   "type": "h2",
   "text": "Step 3 — Understand the constraint"
  },
  {
   "type": "p",
   "html": "The reason break-glass attribution is weak is not negligence. It is that any attribution mechanism depending on the identity platform fails in exactly the scenario the account exists for."
  },
  {
   "type": "p",
   "html": "So the requirement is unusual: attribution that works when the identity provider, the policy service, the monitoring pipeline and possibly the corporate network are all unavailable."
  },
  {
   "type": "h2",
   "text": "Step 4 — Offline dual signature"
  },
  {
   "type": "p",
   "html": "Two people, two hardware credentials, one canonical statement, verified locally against a published key with no network dependency."
  },
  {
   "type": "code",
   "text": "{\n  \"type\": \"manav-stmt/1\",\n  \"action\": \"emergency_access_invocation\",\n  \"render\": [\n    \"Incident: [reference or description]\",\n    \"Account: [emergency account identifier]\",\n    \"Intended scope: [systems, actions]\",\n    \"Expected duration: [hours]\",\n    \"Authorising basis: [on-call authority | incident commander]\"\n  ],\n  \"invoker\": \"[credential assertion]\",\n  \"witness\": \"[credential assertion, distinct authenticator]\",\n  \"at\": \"[timestamp]\"\n}"
  },
  {
   "type": "p",
   "html": "The witness requirement encodes the two-person rule that procedures already require and logbooks already fail to evidence. Distinct authenticators mean one person cannot produce both signatures."
  },
  {
   "type": "h2",
   "text": "Step 5 — Close the loop"
  },
  {
   "type": "p",
   "html": "An invocation receipt is the start of a record, not the whole of it. Pair it with a closing statement: what was actually done, when access ended, and whether the credential was rotated afterwards."
  },
  {
   "type": "p",
   "html": "Rotation after use is in every procedure and is skipped more often than anyone admits, because the outage is over and the urgency has gone. A closing receipt that records whether rotation occurred makes the omission visible."
  },
  {
   "type": "h2",
   "text": "Failure traps"
  },
  {
   "type": "ol",
   "items": [
    "Requiring network connectivity for the signature. If verification calls anything, it fails in the scenario that matters.",
    "Storing the verification key only in the systems that may be down. Distribute it to the devices that will perform verification.",
    "Requiring the witness to be a specific named person. Define a role — any second on-call engineer — or the control blocks during the one night that person is unreachable.",
    "Treating a missing witness signature as a hard failure. Record the exception and proceed; an emergency control that blocks the emergency has failed."
   ]
  },
  {
   "type": "h2",
   "text": "What a usable break-glass control looks like"
  },
  {
   "type": "table",
   "caption": "Requirements that conflict, and how to satisfy both",
   "head": [
    "Requirement",
    "Satisfied by"
   ],
   "rows": [
    [
     "Works when everything else is broken",
     "Offline verification against a cached key"
    ],
    [
     "Cannot be casually used",
     "Two named signatures"
    ],
    [
     "Fast enough in a real incident",
     "Seconds, on devices responders carry"
    ],
    [
     "<strong style=\"font-weight:600\">Produces evidence</strong>",
     "<strong style=\"font-weight:600\">A receipt, not a log line</strong>"
    ]
   ]
  },
  {
   "type": "p",
   "html": "The tension is real: a control that fails when the identity provider is down is not a break-glass control. That is why the verification has to be offline and the credential has to be something a responder holds."
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“Two signatures will slow an incident.”</strong> By the time it takes two people to touch a key. Set against the alternative — an account that bypasses everything and is protected by a text box — that is a good trade."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“We review break-glass use afterwards.”</strong> A review that reads a log naming a shared account can establish that the account was used. It cannot establish who used it, which is the question."
  }
 ],
 "faq": [
  {
   "q": "Does this prevent break-glass use?",
   "a": "No, and it must not. It records who invoked it, with a witness, in a form that survives the outage and can be verified afterwards."
  },
  {
   "q": "What if the second person is unreachable?",
   "a": "Record the exception and proceed. Blocking emergency access to enforce a witness requirement would be a worse outcome than the attribution gap."
  },
  {
   "q": "Can we not rely on cloud audit logs?",
   "a": "They frequently capture the account's actions and not the human behind them, and during a platform outage they may be delayed or incomplete — which is precisely when you need them."
  },
  {
   "q": "How often should we test this?",
   "a": "Quarterly, as a drill on a non-incident. Organisations discover during drills that the envelope is in a safe nobody on-call can open."
  },
  {
   "q": "Why can't break-glass depend on the identity provider?",
   "a": "Because the identity provider being unavailable is one of the scenarios break-glass exists for. Verification must work offline."
  },
  {
   "q": "Is two signatures too slow for an incident?",
   "a": "It is the time for two people to touch a key. Against an account that bypasses every control, that is a good trade."
  },
  {
   "q": "What does after-the-fact review achieve today?",
   "a": "It establishes the account was used. It cannot establish who used it."
  }
 ],
 "sources": [
  {
   "t": "Cloud provider emergency access account guidance and exclusion recommendations."
  },
  {
   "t": "CISA — known exploited vulnerabilities and incident reporting",
   "u": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog"
  },
  {
   "t": "Audit standards addressing privileged access and emergency procedures."
  },
  {
   "t": "Two-person control practice in high-consequence environments."
  },
  {
   "t": "NIST SP 800-53 Rev. 5 — access enforcement",
   "u": "https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final"
  }
 ],
 "related": [
  {
   "slug": "offline-authorization-readiness",
   "title": "Black start and the identity provider you cannot reach",
   "category": "Definitional"
  },
  {
   "slug": "approval-quality-framework",
   "title": "Just-in-time privilege",
   "category": "Compliance"
  },
  {
   "slug": "cryptographic-two-person-control",
   "title": "Two-person control that software cannot prove",
   "category": "Vertical"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/Provable%20Break%20Glass/1500_900/blog.jpg",
 "wordcount": 965,
 "url": "/blog/provable-break-glass.html",
 "reading_time": "4 min read",
 "seo_title": "Break-glass: the account that defeats every control",
 "meta_description": "Every organisation keeps emergency accounts exempt from conditional access, MFA policies and monitoring, because those controls can fail.",
 "hub": {
  "slug": "topics/access-governance",
  "title": "Access governance and certification"
 },
 "answer": "Because it is designed to. A break-glass account exists precisely to bypass the controls that normally apply, and it is protected by a typed reason and a log nobody reads. Every organisation has one, and it is the single most powerful credential in the estate.",
 "answer_q": "Why does break-glass defeat every other control?",
 "glossary": [
  {
   "term": "Break-glass",
   "def": "An emergency credential granting broad access, deliberately exempt from normal controls."
  },
  {
   "term": "Offline verification",
   "def": "Checking a signature against a locally cached key, so the control works when the identity provider does not."
  },
  {
   "term": "Scope rendering",
   "def": "Displaying exactly what access is being granted and for how long, so the approval covers something specific."
  }
 ],
 "checklist": {
  "title": "Making break-glass provable",
  "id": "breakglass",
  "desc": "Four steps.",
  "steps": [
   {
    "name": "Require two named signatures.",
    "text": "Not one, and not an account."
   },
   {
    "name": "Verify offline against cached keys.",
    "text": "Or the control fails exactly when needed."
   },
   {
    "name": "Render what is being granted.",
    "text": "Scope and duration, so the signature covers something specific."
   },
   {
    "name": "Treat every use as an incident.",
    "text": "With a review that has an artefact to read."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav turns an access or elevation decision into an artefact: what the approver was shown, who they were, what authority they held, signed and verifiable without your systems.",
  "href": "../docs.html",
  "label": "See approval receipts"
 }
}