Lowering the barrier to owning cryptographic identity infrastructure.
A program of work that begins with small organizations needing internal trust they currently cannot afford to deploy properly, extends to individuals with high-stakes identity requirements such as elected officials and business-critical approvers, and aims eventually at broader personal use as the tooling matures.
For most of the digital era, real cryptographic identity has been infrastructure that only large institutions could deploy properly. The tooling assumed enterprise budgets, specialist staff, and operational discipline that smaller organizations could not match. Individuals rarely entered the picture at all, beyond receiving certificates issued by others.
This is starting to change. Hardware secure enclaves that hold private keys without exposing them have become inexpensive. Cryptographic standards have stabilized to the point where the remaining work is integration and usability rather than research. The result is that a complete trust system, owned end to end by the entity using it, is now within reach of populations that were previously locked out.
This project is about making that reachable in practice, not just possible in principle.
Trust Zones is designed in stages. Each stage addresses the next population that can adopt the technology.
This is the current focus and the bulk of what this document describes. Small organizations have the operational maturity to follow a key generation ceremony, the resources to protect the hardware that anchors their trust, and the regulatory or architectural pressure to need real cryptographic identity. They have no good options today.
Elected officials. Business-critical approvers such as CFOs authorizing wire transfers, CEOs signing contracts, board members voting on resolutions. Lawyers, doctors, and journalists whose work depends on verifying who they are talking to or proving who they are speaking as, often across jurisdictions and devices.
These individuals need cryptographic identity that travels with them rather than being tied to a specific device, organization, or location. They have the personal resources or institutional support to manage the hardware that anchors it. Stage two extends the architecture to fit their workflow.
As the tooling becomes cheaper and easier to operate, and as the cryptographic recovery problem matures elsewhere in the industry, personal use becomes practical for a wider audience. Stage three is a longer-term direction rather than a near-term commitment. The architecture is designed so it can be reached without restructuring.
The rest of this document focuses on stage one. Stages two and three are revisited in the Forward Thinking section.
Inside most small organizations, the question of how one system proves its identity to another has never had a real answer.
When two services on the same internal network talk to each other, they often do so over plain HTTP. The reasoning is reasonable on its face. Setting up internal PKI is complex, certificate management is a burden no one wants to own, and the network is the organization's own. The result is internal infrastructure where any service can impersonate any other, where credentials get passed in clear text, and where the audit story is "we trust our network."
When two systems across organizations need to talk, the options are worse. Some pay a commercial certificate authority per certificate, per year. Others rely on shared secrets sent over email. Many simply do not authenticate at all, falling back on IP allowlists and the hope that nothing routes the wrong way.
Between an organization and its remote administrators, the situation is similar. SSH keys distributed by hand, sometimes shared between people, rarely rotated, hard to revoke when someone leaves.
None of this is an accident. It is what happens when the only available identity infrastructure is either too cheap to be trusted or too expensive to deploy.
There is a middle path that should exist but does not.
A small organization should be able to own a complete internal trust system, where:
The private keys never sit on a server or in a file. They live in hardware that cannot leak them.
The organization, not a vendor, decides who is trusted.
A competent technical person can set it up in an afternoon, not over a six month consulting engagement.
The result uses the same standards as the rest of the internet, so existing tools work with it.
The configuration stands up to a regulator's review.
This kind of system exists for large enterprises. It costs hundreds of thousands of dollars per year to operate and requires specialists on staff. For everyone else, it does not exist.
That gap is what stage one of this project addresses.
A small dedicated piece of hardware for the rare, high value operations like generating the organization's root key. This hardware has no network connection by physical design. It is something the organization either owns or visits at a trusted location.
A small hardware key for each server, each administrator, and each service that needs to prove an identity. Private keys are generated on these keys and never leave them. If a server is compromised, the attacker takes the data on the server but cannot extract the key.
Open software that ties this together. Configuration that an administrator can read. Integration with the systems the organization already uses.
The result is a trust system the organization owns end to end. It can authenticate services to each other over any kind of connection, including mTLS, message queues, application protocols, and connections yet to be invented. It can identify administrators connecting to internal tools. It can prove that a partner system is genuinely the partner system. It can survive a compliance review.
Most large enterprises operate internal PKI that is far from ideal. The complexity is real. Root keys live in HSMs that few people understand. Intermediate signing requires opening tickets across teams. Certificate rotations are scheduled events that involve change windows. Audit teams find gaps every cycle. The system is expensive, brittle, and hard to reason about from end to end.
A small organization adopting this approach can move ahead of that. The hardware constrains the design. Each key is hardware backed by construction. Each operation is observable. The setup is simple enough that everyone involved understands it. Configurations can be reviewed in an afternoon.
Done right, a small team can have internal identity infrastructure that is structurally sounder than what their enterprise customers and partners run on.
Hardware keys that hold private keys without ever exposing them have become inexpensive. The same hardware certified for use by governments is available to anyone for the price of a nice meal.
The standards have been stable for years. There is no research project here. The contribution is in integration and usability.
The open source ecosystem can carry the integration layer without depending on a commercial vendor.
This does not replace the certificate authorities that secure the public web. Those continue to do what they do well.
This is not a cryptographic innovation. The math is settled.
This is not a managed service. The whole point is that no external party holds the organization's keys.
The trajectory described above is genuine. Each stage requires real engineering and design work, but the underlying architecture supports all of them. A brief look at what lies beyond stage one.
The same hardware that anchors a small organization's trust zone can anchor an individual's. The cryptographic architecture is identical. What changes is the workflow around it.
A high-stakes individual user typically needs to authorize actions or assert identity from different devices, in different locations, sometimes outside their home jurisdiction. The chip in their pocket becomes the constant. Whatever device they happen to be using, the chip is what signs the wire transfer approval, the contract acceptance, the formal statement, or the secure message. The device is incidental. The hardware is the identity.
Stage two work focuses on the protocols and UX around this workflow. Verifying that a request is genuine, presenting it on the chip's own trusted surface where possible, integrating with the platforms these users already rely on. The cryptography needs no changes.
Personal use at broader scale runs into a question that small organizations and high-stakes individuals can answer through operational practice but ordinary users typically cannot: what happens when the chip is lost.
The broader cryptographic recovery problem is being actively worked on outside this project. Shamir-style secret splitting, social recovery patterns, and multi-party computation approaches are mature areas of research and practice, particularly in the blockchain space where not losing access to a hardware-rooted identity has been a first-class design constraint for years. By the time stage three becomes the natural focus, the available techniques should be much further along, and the right ones can be selected rather than invented.
A dedicated document will explore personal use and the relevant recovery models when the project is ready for that step.
Independent trust zones can recognize each other through cross-signing. This is standard cross-certification and the cryptography is well understood. The v1 design focuses on single zones to keep the surface area manageable for the first generation of tooling. Federation can be added later without disturbing v1 deployments, and becomes more important as stage two takes shape, since individuals will need to be recognized across the organizations they are affiliated with.
The conceptual framework is in CONCEPT.md. The technical specification is in TECHNICAL.md. Both are open for review.
The project is at an early stage. The most valuable contributions right now are critique of the approach, identification of prior art, and validation of the threat model.