You now pay for two access paths to one app and the old one still works — what has an attacker actually lost?
answer
- count the doors, not the controls
- attackers price the cheapest path
- posture is a union, not an average
- controls in parallel, not in series
- the old name still resolves
basics
~20 sClose to nothing. An attacker takes whichever path is cheapest, so the application's exposure is the most permissive of the two, not the average. You are now funding two policy sets and getting the weaker one's security.
solid answer
~50 sReachability combines. A control only removes risk for traffic that has no choice but to pass through it, so putting an identity-aware broker in front of an application removes nothing while the old firewall path still reaches the same service. An attacker fingerprints both front doors and uses the one with the older admission test — a source address on a branch network instead of a user, a device and a session. What has changed is the bill: a second control plane to buy, a second policy set to review, a second set of access evidence for audit, and the original circuit contract still running. Honest progress is not "the app is on the new path" — it is "the old path to the app no longer exists". Until then the pilot has proved the pattern works and has moved the risk nowhere.
go deeper
Be ready to say plainly that two ways in means the weaker one decides, and to name a couple of things that keep the old way alive — a name that still resolves, a route that still exists, a permit nobody removed.
An interviewer expects you to explain why parallel controls do not stack: each one only judges traffic that reaches it, so permits combine across paths. Be able to list the client types that keep using the old endpoint after everyone has been told not to.
Show the judgment that progress is measured in paths retired, not applications moved, and that the old path is now the least-watched one because attention followed the new project.
Own the framing with the sponsor: the programme's risk reduction is zero until a path dies, and the interim state costs two subscriptions, two policy reviews and two sets of audit evidence. Decide whether to keep migrating breadth-first or to fund one path's ending.
## The situation A retail chain has 400 shops. Historically every till, back-office PC and stock terminal reached head office over a private circuit, and a border firewall at head office decided what a branch was allowed to talk to. One application — say the stock-adjustment app — has now been moved behind an identity-aware broker, reachable from the shops' consumer broadband, with user identity and device posture checked before a session is brokered. The pilot works. The steering group calls it a security win. It is not one yet, and the reason is worth being precise about. ## Reachability is a union, not an average A network control only removes risk for traffic that has **no alternative** to passing through it. The broker checks identity and device state for sessions that arrive at the broker. It has no opinion at all about a packet that arrives at the application over the old circuit, because it never sees that packet. So the application's admission test is not "broker AND firewall". It is "broker OR firewall" — whichever an attacker chooses. The estate's posture for that app is the **most permissive** of the two paths. Averaging the two, or claiming the stricter one governs, is the classic wrong answer here, and it is a wrong answer that competent people give because in most engineering contexts controls stack in series. These two are in parallel. ## What keeps the old path alive after the new one works The migration is usually declared done at the moment the new path serves users. Several things quietly keep the old door open: - **The internal name still resolves to the legacy front door.** Clients that were never repointed, or that cached, or that hard-code the old hostname, still land there. - **The route still exists.** The circuit is still up, and the branch networks still have a path to the head-office address range that holds the application. - **The firewall permit is still in place**, because nobody removes a permit while a single branch might still need it. - **Clients you cannot see.** Tills, label printers, a stock-count handheld, a vendor's support tunnel, a nightly batch job — anything with an endpoint baked into a config file. - **The disaster-recovery path**, which is deliberately the old one, exercised twice a year. Any one of these is enough. An attacker who lands on a branch network — a compromised shop PC, an unmanaged device on the shop's broadband, a supplier's laptop plugged into the back-office switch — does not need to beat identity and device posture. They need a route and a permit, and both are still there. ## What the attacker actually lost Be fair about it: something did change. If the attacker's foothold is somewhere that only reaches the broker — the open internet, a phished user's home machine — then they now face a stronger test than a source address. And the new path means the application's exposure is no longer purely a function of where you are standing. That is real, and it is why the pilot was worth doing. What they lost is one *class* of position. What they kept is the whole legacy position, and in a branch estate that is the position an attacker is most likely to reach cheaply. ## What you now pay for The price is the honest second half of the answer, and interviewers listen for it: | Cost | Who feels it | | --- | --- | | Subscription for the rented edge | The security budget | | The circuit contract, unchanged | The network budget | | Two policy sets to review and keep consistent | The engineers holding both | | Two sets of access evidence at audit time | Whoever answers the auditor | | Attention drift — the old path is now the boring one | Everyone, invisibly | That last row is the one that bites. Once the new path is the interesting one, the old path stops being monitored, tuned or reviewed with the same energy, so the cheapest way in is also the least watched. ## How to answer well Say the union rule in one sentence, name two or three concrete things that keep the old door open, and then state the measure of progress you would actually report: not applications migrated, but **paths retired**. A programme that has migrated eighty percent of applications and switched off zero paths has removed zero risk and added a bill.
- What metric would you report to the steering group instead of applications migrated?Paths retired, and reachable-path count per application. An application is only improved when no route and no name still deliver traffic to its legacy front door. Report it as a per-application state — dual-path, single-path, retired — so the number moves only when something is switched off. Applications migrated goes up while the risk sits still, which is exactly why it is the number programmes prefer.
- The pilot app still enforces its own login. Doesn't that make the old path safe enough?It makes the application's own authentication the floor for the whole legacy path. That is a single-factor test against a service that was designed to sit behind a network boundary, with no device check, no session context, and often no lockout worth the name. It is also the exact thing the broker was bought to stop being the only control. Treat it as the reason the old path is a finding, not the reason it is acceptable.
- Where would you expect an attacker to stand in a 400-shop estate?On a shop network, because it is the cheapest position to reach and the least supervised — an unmanaged device on the shop broadband, a back-office PC, a supplier's laptop on the stockroom switch. From there the legacy path needs only a route and a permit. The broker path would demand a user, a compliant device and a session, which is a materially harder starting point.
You fitted a biometric lock to the front door and left the side gate on its old latch. The house is as secure as the latch, and you now pay for two locks.
saying these in an interview costs you the question
- Says the stricter of the two paths governs the app
- Treats applications migrated as risk removed
- Assumes decommissioning happens automatically after cutover
- Forgets the old circuit and firewall are still funded
- Claims the app's own login makes the legacy path acceptable