When do you give up the passive mirror position and terminate egress TLS instead, and who signs for it?

## The decision is not a product decision The temptation is to treat payload blindness as a gap and go shopping. The useful reframe is to ask which question the organisation actually needs answered, because two very different questions hide behind *we cannot see inside the traffic*. - *Did data leave, to where, in what volume, and when?* The passive residue already answers this to a defensible standard, and it answers it for every session, including ones you would never be able to decrypt. - *What was in it?* Nothing on the network path answers this without terminating, and terminating answers it only for the sessions you actually terminate. If the driver is the first question, the money belongs in coverage, retention and baselining, not in a decryption programme. ## What the passive position is worth, stated as things you are about to spend A mirror is often described as a compromise. It is worth listing what it buys, because a proposal to leave it should be priced against these: | Property of the passive position | What you give up by terminating | | --- | --- | | A copy: sensor failure loses visibility, never traffic | A device in the path whose failure is an outage or a bypass | | Holds no keys and no plaintext | Custody of the estate's plaintext, and everyone who can query it | | Cannot be a man in the middle by construction | A capability that is itself an insider-risk and audit subject | | Invisible to the adversary | A substituted chain that tells a careful adversary you moved | | No client compatibility surface | Pinning clients that fail closed rather than be read | ## The failure posture is somebody's decision, not yours alone Once a terminating position is in the egress path, someone must answer what happens when it is unhealthy: does traffic stop, or does it flow uninspected? Both answers are defensible and neither is security's alone to pick, because one of them is an outage and the other is a silent loss of the control you just paid for. Getting a named owner for that choice, in writing, before the device is deployed, is most of what separates a survivable rollout from an incident. ## What breaks, and why that is not a bug A client that pins a certificate or public key is asserting that only one chain is acceptable. An interception point that substitutes its own chain is exactly the condition pinning exists to detect, so the client does the correct thing and refuses to connect. Mutual authentication between services fails for a related reason: the far end wants the client's identity, and the interception point is not it. These are not defects to be engineered away; they are the assurance model working, and every one of them is a business flow with an owner who did not ask for this and can refuse. ## The adversary's answer to your investment Assume the programme lands. The implant now has a shorter list of choices, not an empty one: encrypt its own payload inside the session you decrypt, so you read a tunnel and learn nothing; move to a protocol or destination your terminating position does not handle; or move the exfiltration off the path entirely, onto a sanctioned service you already trust. Meanwhile you are decrypting your employees' and workloads' traffic at scale, permanently, to raise the cost for one adversary by a step they can take in an afternoon. That asymmetry is the honest core of the argument and a principal candidate should say it out loud rather than only advocating. ## Where the money often goes instead The common landing zone is: keep the network in the passive position and spend on making the residue better - full coverage of egress paths, per-workload baselining, longer retention of metadata - while buying the payload question at the endpoint for the software you own, and constraining egress structurally so that the set of destinations a workload may reach is small enough that an unfamiliar one is itself the signal. Then, if a specific population genuinely requires content inspection - a regulated flow, a high-risk user group - terminate for *that* population only, with the owners of it signed on, rather than for the estate. ## Who signs Name them in the answer: the availability owner for the in-path failure domain and its failure posture; legal, privacy or the works council for holding plaintext of people's traffic; the owners of the applications whose pinned or mutually authenticated clients will break; finance for a recurring cost that scales with throughput; and your own leadership, because after this the security team holds a capability that must itself be governed. If you cannot get those signatures, you do not have a decryption programme - you have a plan to be blamed for an outage.