The question we get asked first
Prospective customers outside defense and public safety ask a reasonable question: the technology is protocol-level access brokering, so why not sell it everywhere? The honest answer is that we tried to imagine a product that serves both markets well, and could not. The two sets of requirements pull the architecture in opposite directions, and every compromise lands on the customer who can least afford it.
Consequence is not a slider
Every organisation says its systems are critical. What separates a mission-critical network is not how much the outage costs, but whether the damage can be undone.
A retailer that loses its order system for six hours loses revenue and goodwill, both of which recover. A dispatch centre that loses CAD for six hours has calls it cannot route, and there is no version of the next morning in which those six hours are recovered. An evidence management system with an unexplained administrative login has a chain of custody problem that follows every case that system touched, potentially for years, in front of a defence attorney whose entire job is to find exactly that.
Systems designed against recoverable consequences make sensible trade-offs that become indefensible when the consequence is irreversible. Convenience features that shave thirty seconds off an administrator's day are worth it when the downside is a chargeback. They are not worth it when the downside is an inadmissible case or an unavailable dispatch floor.
What follows from the decision
Choosing one class of customer is only meaningful if it changes what gets built. In our case it decided four architectural questions before they were asked:
- No cloud control plane. The gateway, the vault, the ledger, and the policy engine run inside your boundary. A design where enforcement depends on reaching a vendor's service is unavailable to a classified enclave and unacceptable to most agencies even when it is technically possible.
- Air-gapped operation is the baseline case, not an edition. Licensing, updates, time, and notification are all designed to work with no egress at all, because a product that degrades when disconnected is a product that fails during exactly the events it was bought for.
- Recording is built as evidence. Sessions are sealed with a SHA-256 digest and written into an append-only hash-chained ledger, because a recording that the administrator being investigated could have edited answers nothing.
- Deployment assumes someone else’s facility and someone else’s rules. Installation, support, and upgrade all have to work when our engineers cannot see the system, cannot dial in, and in some cases cannot enter the room.
Each of those is a poor trade in a commercial deployment. Cloud control planes are easier to operate. Vendor remote support resolves incidents faster. Evidence-grade sealing adds work nobody asks about when the auditor is an internal team. Building for the mission means accepting the harder option every time.
What we give up
The obvious cost is market size. The less obvious cost is a set of features that are genuinely good and that we will not build: self-service tenant onboarding, marketplace integrations that call outward, telemetry that improves the product by phoning home, and the fast release cadence that comes with being able to fix things in production yourself. Agencies do not want a gateway that changes underneath them, and no amount of engineering enthusiasm makes that a good idea on a network where the change window is a formal process.
Who that includes
The focus is narrower than "government" and wider than "the military". It is the set of environments where an unexplained administrative login is a serious event in its own right:
| Environment | What an unexplained login threatens |
|---|---|
| Military and defense commands | Enclave separation, coalition compartmentation, operational security |
| Police and law enforcement | CJIS obligations, digital evidence integrity, informant and case confidentiality |
| Fire, EMS and 911 centres | Dispatch availability, station alerting, records that are called in litigation |
| Emergency management | EOC systems that must work during the event, with staff who do not normally hold access |
| Critical infrastructure | The IT/OT boundary, where a bad change is a physical event |
| Defense industrial base | Programme separation and contractor access to the above |
What this is not
It is not a claim that commercial privileged access products are badly built. Several are excellent at the problem they chose, which is scale and speed across a large, connected, cloud-first estate. It is a claim that the two problems are different, and that a vendor pointed at both will resolve every tie in favour of the larger market.
It is also not a claim that we can do things others cannot. It is a statement about what we optimise for when the requirements conflict — which, on these networks, is most of the time.