A hospital must inspect outbound TLS payloads for command-and-control while certificate-pinned patient portals and staff banking apps keep working untouched. Endpoints are domain-joined Windows workstations, and the design must rely only on infrastructure the hospital already owns. Which TLS decryption design meets these requirements?

The correct design selectively decrypts outbound traffic: a do-not-decrypt rule preserves the operation of certificate-pinned portals and regulated banking apps, while other eligible web sessions can be inspected for command-and-control content. Deploying the enterprise root to the domain-joined Windows endpoints lets those clients trust the gateway’s substituted certificates; the design uses infrastructure the hospital already owns. A managed cloud decryption service can provide similar selective inspection and endpoint trust, but it introduces external infrastructure, contrary to the ownership constraint. Limiting decryption to browser traffic is a common way to reduce compatibility risk, but it leaves TLS from other applications outside the inspection scope, so it cannot meet the requirement to inspect outbound payloads generally. Bypassing regulated sites alone is insufficient: certificate-pinned applications reject the gateway’s substituted certificates, so those sessions must also be exempted to remain untouched. Exam caveat: decryption rules do not guarantee visibility into every session; pinning, unsupported protocols, and application-specific behavior can prevent inspection. Practical check: pilot the policy on representative managed workstations, verify that pinned and banking apps connect without decryption, and confirm that an approved test session on an eligible rule is decrypted and logged.