A transit gate denies all travel when the entitlement service is down — how do you weigh fail-open against fail-closed?

## Reading the design One service sits on the path of every gate decision. If it is unreachable, nobody travels. That is a denial-of-service entry in the model on its own merits, before any adversary appears: threat modeling asks what could go wrong, and *the entitlement service is unavailable* is a complete answer. Adding an adversary only makes it cheaper — a single component whose loss denies service to every user is the most attractive target in the architecture, so it concentrates risk rather than spreading it. The asset at stake is availability of a public service and the fare revenue attached to it, with a safety dimension: a station whose gates all deny entry at rush hour is a crowding problem, not merely an inconvenience. That framing is what makes the naive answer wrong. ## Why fail-closed is not automatically correct The reflex — *when in doubt, deny* — is right when the cost of a wrong allow dominates. Denying a wire transfer, a privilege grant or a key release while the authorisation service is down is defensible, because a wrongly allowed action is unrecoverable and the denied user can wait. At a transit gate the arithmetic inverts. A wrongly allowed passenger costs one fare, which is small, sometimes recoverable, and statistically bounded by how long the outage lasts. A denied station costs every fare for the duration plus a crowd-management incident. So *fail-closed is secure* is only true if availability is not a security property — and in STRIDE it plainly is. Choosing fail-closed is choosing to accept a denial-of-service threat in order to close a spoofing or elevation one. That is a legitimate trade, but it must be made as a trade, with both sides named. ## Do the structural work first Before arguing about the fallback, attack the single point: - **Push the decision local.** Issue short-lived, signed entitlements that the gate can verify offline against a public key it already holds. Now the common case involves no network call at all, and the central service becomes an issuer and a revocation feed rather than a synchronous dependency. - **Cache with a defined staleness.** A gate holding recent entitlement state can serve most travellers correctly through a short outage. Say explicitly how stale is acceptable, because that number *is* the residual fraud window. - **Remove correlated failure.** Redundant instances that share one database, one network path or one certificate authority are one component wearing three hats. Ask what a single expiring credential or one bad configuration push would take down at once. - **Distinguish reachability from health.** A gate that cannot reach the service is a different case from a service that answers *deny* — treating a timeout as a denial is exactly how one network blip becomes a system-wide refusal. Fail-open is only what you do when all of that has already failed. ## Split the decision, do not flip a global switch One binary for the whole system is a design smell. Different actions have different costs when wrong: | Action | Sensible degraded behaviour | |---|---| | Ordinary single entry | Allow, record, reconcile later | | Entry on a card flagged as lost or blocked | Deny — the local revocation list is small and cacheable | | Refund, balance transfer, high-value product | Deny — a wrong allow here is real money and hard to unwind | | Staff or maintenance access | Deny, with an out-of-band manual procedure | This is the move that separates a principal answer from a senior one: the question is not *open or closed* but *which decisions may degrade, by how much, and for how long*. ## Bound the degraded mode An unbounded fallback is a permanent hole that nobody remembers. Constrain it: - **Time**: offline tokens with short validity, and a hard limit after which the mode escalates rather than continuing silently. - **Record**: every allowed action written locally, signed or tamper-evident, and reconciled when connectivity returns. Allowing without recording is the version of fail-open that gets an organisation into trouble, because the loss is then unmeasurable. - **Visibility**: an alert when degraded mode is entered, and a continuing signal while it persists. Degraded mode must never be a quiet steady state. - **Rehearsal**: exercise the fallback on a schedule. A fallback path that has never run is a second untested system that will be discovered during the incident. ## Who decides Not the engineer at three in the morning. The choice is a business risk decision — expected fare loss and fraud exposure versus denied travel, crowd safety and reputational cost — so the product and risk owners set the default in advance, the design encodes it, and on-call may move only within pre-agreed bounds. Writing that default down, with the reasoning, is what turns a design-time argument into an operational policy that survives staff turnover. It also gives the threat model something to point at: the D threat is not *unmitigated*, it is *accepted, bounded and owned*, with a named residual.