The platform team keeps a standing break-glass path around the enforcement point — how do you govern it?
answer
- the bypass is a control, not an exception
- least enforcement, often least recorded
- expiry whose default action is deletion
- reviewed by someone who did not use it
- make the enforced path work at 3am first
basics
~20 sTreat the bypass as its own control: one named owner, an expiry that defaults to removal, its own strong authentication, and every use reviewed by someone who did not make it. Then make the normal path fast enough at 3am that nobody prefers the bypass.
solid answer
~60 sA standing bypass is not an exception to the architecture, it is part of it — the path with the least enforcement and usually the least recording, which makes it the most valuable credential in the estate. I govern it as a control in its own right: a single named owner who is senior enough to authorise its removal, authentication at least as strong as the path it bypasses, an expiry date where the default action is deletion rather than renewal, and a record of every use reviewed by someone other than the user. The organisational half is harder than the technical half. The platform team keeps it because the normal path is unusable under pressure, and arguing about risk will not change that. So the real work is making the enforced path work during an incident — pre-authorised elevated roles, a tested procedure, no dependency on a system that may itself be down — and only then taking the bypass away. Removing it before the replacement works means it comes back informally and undocumented.
go deeper
Know that break-glass access exists on every platform and that using it should always leave a record somebody else reads. Do not use it because it is quicker.
Explain why the bypass is usually the least-enforced and least-recorded path, and what an attacker gains by stealing its credential rather than a normal one.
Show how you would instrument it: strong authentication, tamper-resistant use records, second-person review, and a rehearsed enforced alternative measured against it.
Own the negotiation and the funding. Decide who signs for the exception, set an expiry that defaults to deletion, and commit to building the emergency path before you take the bypass away.
## Why the bypass exists and why it never leaves Every enforcement point on a shared platform acquires a way around it, because someone eventually has to fix the platform when the platform is broken. The path starts as a temporary measure for one incident, and by the following year it is in the runbook, three people have the credentials, nobody remembers who approved it, and the ticket that created it says *remove after migration*. The reason it survives is not laziness. It survives because at 3am, with an outage running, the bypass works and the enforced path either does not or nobody has ever practised it. Any governance approach that treats this as a discipline problem fails, because the people using it are making a correct local decision. ## What the adversary gets The bypass is a concentrated target. It reaches the estate without passing the deny, it is often used by accounts with the broadest rights on the platform, and it is frequently the path with the thinnest recording, because it was built in a hurry and the logging was somebody's second task. An attacker who phishes or steals the credential to it obtains exactly what an attacker most wants: reach without enforcement and use without attribution. It is also durable — password rotations and policy changes generally do not touch a path that exists specifically to sidestep policy. So the risk statement is not *there is an exception*. It is *there is one credential in this estate whose theft produces unlogged, unenforced access, and its existence is not tracked anywhere the security team reviews*. ## Governing it as a control 1. **One named owner, senior enough to remove it.** Not the team that uses it. An owner who cannot authorise its deletion is a contact, not an owner. 2. **Authentication at least as strong as what it bypasses.** The path that skips the deny is the one most people secure the least. It should be the most strongly authenticated thing you have, ideally requiring a second person for use. 3. **An expiry whose default is deletion.** Renewal must be an action somebody takes deliberately, with a stated reason. If nothing happens, the path goes away. Exceptions that require effort to keep get closed; exceptions that require effort to remove never do. 4. **Use is recorded where the user cannot edit it, and reviewed by someone else.** Every invocation, with who and why, reviewed by a person who did not make the call. This is what converts an untracked hole into a monitored control. 5. **The register is visible.** The bypass belongs on the same exception list as the legacy client and the appliance that cannot carry an agent, with the same review cadence. One list, one owner column, one expiry column. ## The part that actually removes it All of the above manages the risk; none of it removes the path. Removal requires making the enforced path viable under incident conditions: - **Pre-authorised elevation** that an on-call engineer can invoke themselves, without waiting for an approver who is asleep. - **A path that does not depend on the systems most likely to be down** — if elevation requires the identity provider and the identity provider is the outage, you have designed the bypass back into existence. - **Rehearsal.** If the enforced emergency path has never been exercised, it does not work, whatever the document says. Practise it in a scheduled drill and measure how long it takes against the bypass. Only when the enforced path is measurably as fast do you remove the bypass. Removing it first is the classic failure: the path reappears within one incident, this time built quietly by someone who now knows the security team disapproves, which costs you the record as well as the control. ## The conversation with the people who hold it This is a negotiation with a team who are right about their own constraint. The productive framing is not *your bypass is a risk* but *what does the enforced path have to do for you to give this up*, followed by actually funding that. The answer is usually speed, autonomy at unsociable hours, and independence from a system that might be part of the incident. Those are buildable. The alternative framing produces a signed risk acceptance and no change, which is a worse outcome than an honest exception with an owner and an expiry. ## What good looks like in an answer Name the bypass as a control, govern it with an owner and a default-delete expiry, put its use under someone else's eyes, and then say plainly that the only real fix is an enforced emergency path that works under pressure — and that you would not remove the bypass until you had measured that it does.
- The platform team refuses to give up the bypass. What do you do?Stop arguing about risk and ask what the enforced path must do to be acceptable — usually speed, self-service elevation at unsociable hours, and independence from systems that may themselves be down. Fund that, rehearse it, measure both paths under drill conditions, then remove the bypass. If they still refuse, the outcome is a documented exception with a named senior owner and an expiry, which is honest and reviewable.
- What makes a standing bypass more dangerous than the enforced path it sidesteps?It concentrates three properties an attacker wants: reach without a deny, rights that are usually broad, and recording that is usually thin because it was built under time pressure. It is also durable, since routine credential and policy hygiene tends not to touch a path defined by being outside policy. Stealing one credential yields unenforced and largely unattributable access.
- How do you stop an exception list from growing without limit?Make renewal, not removal, the action that costs effort: every entry carries an expiry whose default outcome is deletion, and a named owner who must state a reason to keep it. Review the whole list on a fixed cadence with that owner present. Entries with advocates survive and entries nobody will defend disappear, which is the correct filter.
A fire door that is propped open because the badge reader is slow. The problem is not the prop; it is that the door was never fast enough to use, and taking the prop away just gets a window opened instead.
saying these in an interview costs you the question
- Proposes removing the bypass before the enforced path is rehearsed
- Assigns the bypass to the team that uses it as its owner
- Sets an expiry that auto-renews unless someone objects
- Treats the standing bypass as an acceptable risk with no owner named
- Calls it a process problem rather than a design failure of the enforced path