The pattern
An agency runs a procurement, selects a well-regarded commercial privileged access platform, and eighteen months later is running it in a degraded configuration that satisfies neither the vendor nor the auditor. The session brokering works. What did not survive contact with the environment is the set of assumptions the product was built on.
Assumption 1 — The control plane can reach the vendor
Many modern platforms keep policy, licensing, or the management interface in the vendor's cloud, with a connector inside the customer network. It is a sound commercial design. On a network with no egress, it does not run at all; on a network with controlled egress, it becomes a permanent exception in the firewall ruleset, documented as a compensating control and re-argued at every assessment.
The deeper problem is the dependency direction. If enforcement needs an outbound connection, then the vendor's availability and the vendor's security posture are inside your control boundary whether or not that appears in the risk register.
Assumption 2 — Identity lives in a cloud directory
Products increasingly assume a cloud identity provider for authentication and MFA. Defense and law enforcement networks frequently run on-premises directories, smart-card or CAC/PIV authentication, and identity that is bound to clearance and posting rather than to employment. Retrofitting that onto a product designed around a cloud IdP produces a second, parallel identity path — which is exactly the bypass an assessor will find.
Assumption 3 — The vendor can log in to fix it
Commercial support models assume screen sharing, remote diagnostics, and log upload. In a government deployment, support staff may need citizenship, clearance, or escort; logs may not leave the facility; and the vendor may never see the running system. A product whose operational model depends on vendor remote access will be run without vendor support, which is worse than a product designed for it.
Assumption 4 — Updates flow on the vendor’s cadence
Fast release cycles are a commercial virtue. On a mission network, an update is a change-controlled event with testing, an approval board, and a rollback plan, and the gateway carrying every administrative session is the last thing anyone wants changing quietly. Products that assume frequent, low-ceremony updates accumulate version debt in these environments until an upgrade becomes a project rather than a task.
Assumption 5 — Multi-tenancy and data residency are commercial questions
Session recordings from a law enforcement network are evidence. Recordings from a defense enclave may be classified by aggregation even when no individual session is. Storage location, tenancy, key custody, and who can compel disclosure are not procurement footnotes in that context — they are the reason a technically superior product gets rejected.
What the alternative looks like
| Assumption | Mission-network requirement |
|---|---|
| Cloud control plane | Policy, vault, ledger and enforcement entirely inside the boundary |
| Cloud identity provider | Works with on-premises directories and smart-card authentication, with no parallel path |
| Vendor remote support | Diagnosable and recoverable by local staff with documentation alone |
| Continuous updates | Deliberate, offline-installable, change-controlled, reversible |
| Vendor-managed storage | Recordings and keys held by the agency, retained on the agency’s schedule |
None of this is exotic engineering. It is a set of choices that costs a commercial vendor more than it gains, which is why the products that make those choices tend to be the ones built for this sector deliberately.