Who holds the key? You choose.
Most of Takelan is platform-managed. We hold the keys so the service can work for you. For some data, you can hold the key yourself. You do it with takehsm, a key holder you run. This page shows what that changes, what it does not, and what is live today.
Read this first. We use the word zero-knowledge in one narrow way. For one kind of data, Takelan cannot decrypt what it stores, because the key is yours. It does not mean Takelan sees nothing. We still see names, sizes, timing and access patterns. The platform also handles a value when you write or read it. Managed secrets are never zero-knowledge.
Two ways to hold the keys
Pick per secret. You can use both in one account.
Platform-managed (the default)
- Takelan holds the keys that decrypt your data.
- The platform can read a value for an approved caller. That is how access rules, the app, backups and automations work.
- Everything keeps working when you are offline.
- You trust Takelan to protect its master key and its servers.
Customer-held keys (zero-knowledge at rest)
- You hold the key-encryption key in takehsm, on a machine you run.
- Takelan stores scrambled data and wrapped data keys. A database dump plus the master key opens nothing for this class.
- Server-side use works while your holder is online and the request fits your policy.
- If you lose the key everywhere, nobody can recover the data. That includes us.
What zero-knowledge means here, in plain words
Read these before you rely on it. If any of them surprises you, ask us.
It does mean
- For Leased secrets, the key that opens them lives only in your takehsm key holder.
- If someone steals our database, even with our master key, they get scrambled data they cannot open.
- Our platform cannot change your holder’s policy or approvers, or lift its lockdown, without signatures from your approvers.
It does not mean
- That Takelan sees nothing. Names, sizes, times and who asked stay visible.
- That the platform never handles the value. It encrypts it when you write it. It decrypts it for you when you read it. It does not keep the plaintext or the key.
- That a hacked platform is harmless while your holder is online. It can get what your policy allows during a short lease. You get limited exposure, not zero.
- That takehsm is a hardware HSM. It is software. It cannot resist root access on its own machine.
How the key and the data move
See where each key lives, and who has to ask whom.
Where the key lives, and how a Leased secret is opened
What Takelan can and cannot see
Zero-knowledge is about keys. It is not about metadata.
What Takelan can still see, and what it cannot do
Platform-managed or customer-held, one feature at a time
See who holds the keys, what Takelan sees, what you give up, and where each one stands today.
| Capability | Platform-managed | Customer-held (takehsm or your approvers) | If it fails or you lose the key | Status today |
|---|---|---|---|---|
| Secret storage | Managed class. The platform holds the master key that protects every organization key. So it can decrypt a secret for an approved caller. A database dump plus the master key can be read. Not zero-knowledge. | Leased class, with takehsm. The key-encryption key lives only in your key holder. The platform stores scrambled data and data keys wrapped to it. So a dump plus the master key opens nothing for this class. Takelan still sees names, sizes, times and access patterns. It also handles the value when you write or read it. | If you lose the key everywhere (passphrase, second factor, backups and recovery shares), the data is gone. Takelan cannot get it back. | LiveLive. The Windows installer is an unsigned preview. macOS and Linux packages are not released. |
| Use by servers, CI and automations | Always works. Jobs, API keys, CI and rotation can read the value whenever access rules allow. | Works while your holder is online and unlocked, and the request fits your policy. The platform gets the data key as a short lease. The default is five minutes, kept in memory only. While a lease is open, the platform holds that key. This is limited exposure, not zero. | If the holder is offline, locked or in lockdown, new reads fail closed and open leases run out. Managed secrets keep working. With two or three holders for one tenant, another one takes over. | LiveLive. The Windows installer is an unsigned preview. macOS and Linux packages are not released. |
| Automatic rotation | An opt-in timer rotates a secret when it is due. PostgreSQL and MySQL/MariaDB rotators check the new password before they store it. The platform reads the old value and writes the new one. | A Leased secret rotates only while a holder is online and allows non-human callers. Your holder policy still applies. Anything outside it needs a signed grant. The timer never bypasses it. | If a rotation cannot reach your holder, it is skipped and tried again, or marked for manual action. It is never forced. | LiveThe rotation timer is off by default. We are switching it on step by step. The holder side shares the status of Leased secrets. |
| Sealed and Delivered classes | Not applicable. | Design only. Sealed: the platform keeps only scrambled data, and the keys sit on your approvers’ authenticators. A reveal needs a grant approved by M of N approvers. Delivered: the secret is encrypted to one destination agent. Only an approved grant that the agent checks can release it. | Planned trade: no platform job, API key, CI integration or automatic rotation could read these secrets. There is no platform break-glass. | RoadmapNot available. Do not plan around it yet. |
| Backups and recovery | Backups of an organization stay encrypted under platform-held keys. The platform can restore them for you. | Platform database backups hold Leased secrets only as scrambled data with wrapped data keys. Tenant secret backups skip Leased secrets. So no backup gives Takelan a plaintext. Your protection is yours: an encrypted takehsm backup file with its own passphrase, offline recovery shares, an optional escrow copy, and up to three holders. | Takelan cannot restore a Leased secret for you. Keep the backups and recovery shares in separate places. Never send a share through the platform. | LiveLive. The Windows installer is an unsigned preview. macOS and Linux packages are not released. |
| Audit trail | The vault and SSH audit logs are hash chains kept by the platform. A verify call finds the first changed entry. No web route deletes them. | The key holder and the server agent also keep their own hash-chained logs, with no secret data in them. They send the head of the log with their heartbeats. The platform raises an alert if a head rewinds or forks. No log holds secret values. | The log shows tampering. It does not stop it. Keep an outside export if you need strong proof. The platform can still deny service. | LiveHolder logs ship with the key holder. Server agent logs need the 0.3.0 agent. |
| Who can add an SSH key to a server | Tier 1, Standard. A fresh passkey check, at most 5 minutes old, comes before any change that grants or widens access. Then the platform decides and the agent follows. So you trust the platform to add keys honestly. | Tier 2, Protected (your approvers, not takehsm). Keys on a protected server change only through a grant signed by M of N hardware approvers. The agent on the server checks the signatures against approvers set at install. The platform only passes them along and cannot add a key. It still sees server names, accounts, public keys and timing. | If fewer than M approvers remain, no grant can be signed. You recover at the server console by pinning a fingerprint you trust. Root access on the server, or M stolen approver devices, defeats the protection. | LiveTier 1 and Tier 2 are in the app. Tier 2 needs the 0.3.0 server agent. |
| SSH data and certificates | SSH data is sealed with AES-256-GCM under a wrapping key kept as a Managed secret. So the platform can use it. Servers that are not protected can use certificates signed by the platform. Not zero-knowledge. | A protected server is refused platform-managed grants and certificates. Its state carries no keys and no certificate authority. A test fails the build if any code path could sign for it. SSH data itself stays platform-managed at every tier. | Protected servers give up platform shortcuts, such as one-click grants and platform-signed certificates. | LiveNeeds the 0.3.0 server agent. |
| Tier 3, Sovereign | Not applicable. | Planned: Tier 2, plus approvals from a signed local tool instead of the platform page. Also hardware-bound SSH keys, approver-approved agent updates and an optional customer-held certificate authority. | Planned trade: platform-signed certificates stop for those servers. | RoadmapNot available. The API refuses to select it. |
SSH approvals are a different kind of protection
The SSH Access Manager does not store your server data in a zero-knowledge way. Its data is sealed under a key that the platform can use. Tier 2 gives you a different guarantee. The platform cannot add a key to your protected server on its own. The agent on the server accepts a key change only with signatures from your approvers.
So we call Tier 2 customer-verified approvals, not zero-knowledge. It does not need takehsm. The two share the same signed-approval protocol and the same approvers.
See SSH approval tiers in the SSH Access ManagerWhat is live today and what is roadmap
Read this before you plan around any of it.
| Option | Status | Detail |
|---|---|---|
| Leased secret class in the platform | Live | Live in the platform, with the Key holders page in the app. |
| takehsm for Windows | Live | You can get an installer from the Key holders page. It is an unsigned preview. Windows SmartScreen will warn you. We publish a SHA-256 so you can check the file. |
| takehsm for macOS and Linux | Live | The source is open (Apache-2.0). Our pipeline builds packages, but they are not released yet. |
| Several holders, backups, recovery shares | Live | Part of takehsm. They share the status of the holder itself. |
| SSH Tier 1, passkey step-up | Live | In the app. |
| SSH Tier 2, signed grants checked by the agent | Live | In the app. Needs the 0.3.0 server agent. |
| Automatic rotation timer | Live | Built, and off by default. You switch it on when you want it. |
| SSH Tier 3, Sovereign | Roadmap | Design only. |
| Sealed and Delivered secret classes | Roadmap | Design only. |
| Signed local approver tool; rotating the key of a holder group | Roadmap | Not built. |
Where each option lives
Every page has diagrams and a list of limits.
Other client-side options on the platform
These are separate from takehsm. Each page says what is and is not covered.
Glossary
Each word means the same thing on every Takelan page.
- Platform-managed
- Takelan holds the keys that decrypt the data or approve a change. We can read the data for an approved caller. This is the default. It is how the Managed secret class works.
- Customer-held key
- A key-encryption key (KEK) that lives only in a key holder you run. Takelan stores data keys wrapped to it. It cannot unwrap them without asking your holder.
- Zero-knowledge
- Our short name for a customer-held key, at rest. Takelan cannot decrypt what it stores. We use it only for that. It does not hide metadata. It does not cover the moments when the platform handles a value or a lease.
- Key holder (takehsm)
- A small open source app (Apache-2.0) that holds your KEK and enforces your policy. It runs on your machine. It dials out and never listens. It is software, not a hardware HSM.
- Leased secret
- A secret whose data key is wrapped to your holder. To use it, the platform asks your holder. It gets the data key for a short lease. The platform keeps the lease in memory only.
- Lease
- The data key plus a time limit. The default is five minutes, and your policy can cap it. It is dropped at expiry, on revoke and on lockdown.
- Policy
- The rules your holder checks before it answers. They cover allowed operations and names, rate and volume caps, lease length, and optional hours. Changes need a grant.
- Grant and approver
- A grant names one exact action. M of N approvers sign it on their own hardware keys or passkeys. The holder, or the server agent, checks the signatures itself. The platform only passes them along.
- Approval tier
- For SSH access. Tier 1 asks for a fresh passkey check. Tier 2 needs a grant signed by M of N approvers and checked by the agent on the server. Tier 3 is planned.
- Lockdown
- One action that wipes the keys from memory, drops all leases and refuses every request. The platform can ask for it, but only a local unlock lifts it.
- Bounded exposure
- What you get while a holder is online. A hacked platform can get only what your policy allows, within rate, volume and lease limits. It is not zero exposure.
Questions about zero-knowledge and key holders
What does zero-knowledge mean at Takelan?
For one kind of data, Takelan cannot decrypt what it stores, because you hold the key in a takehsm key holder. It does not mean Takelan sees nothing. Names, sizes, timing and access patterns stay visible. The platform also handles a value when you write or read it. Today this applies to Leased secrets.
Can Takelan read my Leased secrets?
Not from storage. A database dump plus the platform master key opens nothing for a Leased secret. The platform handles a value when you write or read it. While a lease is open, it holds the data key in memory. If a hacked platform asks while your holder is online, it can get what your policy allows. Anything outside your policy needs a grant signed by your approvers.
What if my takehsm is offline?
New reads of Leased secrets fail closed once the current lease runs out. Managed secrets keep working. Automations that depend on a Leased secret, including rotation, wait or fail until the holder is back. With two or three holders for one tenant, another holder takes over. Decide which automations depend on a holder before you switch a secret to Leased.
What if I lose the machine?
Restore an encrypted takehsm backup on another machine and rebind it with a new token. Or rebuild from recovery shares you kept offline. The key stays the same, so your wrapped data stays usable. Backup passphrases and shares never go through Takelan.
What if I lose the key everywhere?
Then the Leased data is gone. Say you lose the passphrase, the second factor, every backup and the recovery shares. Nobody can recover it, including Takelan. There is no vendor route back, by design. This is the price of holding your own key.
Can I move a secret between Managed and Leased?
Yes. Moving to Leased runs as a background job and needs an enrolled, online holder. Old database backups and exports still contain the Managed copy, so the move does not erase history. Moving back to Managed goes through your holder.
Is SSH Tier 2 zero-knowledge?
No. Tier 2 is customer-verified approvals. The platform cannot add a key to a protected server without signatures from your approvers. The agent checks them. SSH data itself stays platform-managed. Tier 2 does not need takehsm.
Does it work with rotation, CI and Takelan AI?
Server-side jobs work with Leased secrets only while your holder is online and the request is inside your policy. That includes automatic rotation, CI and AI provider keys. Provider keys for the AI router are Managed by default, so the router can use them at any time.
What do auditors get?
Hash-chained logs on both sides. One is the platform audit log. The other is the holder’s own log, which has metadata only. The platform sees its head with each heartbeat. They show tampering. They do not stop it, so export them if you need strong proof. SOC 1 and SOC 2 work is in progress. Customer-held keys can support your own key-custody controls, but they are not a compliance result on their own.
Does it slow things down?
A first read of a Leased secret needs a round trip to your holder. The holder checks your policy and signs its answer. The platform keeps the lease in memory until it expires, so reads in that window do not ask again. We have not published latency figures.
Which plans include it?
We have not published plan details for customer-held keys on this site. takehsm itself is open source under Apache-2.0. Ask us before you plan around it. See the pricing page for the platform plans.
Is takehsm a hardware HSM?
No. It is software, and the app says so. It cannot protect against root access on its own machine or a phished passphrase. You can add an OS key store or a FIDO2 key as a second factor. There is no TPM binding.
Is the Windows installer signed?
Not yet. The current installer is an unsigned preview, so Windows SmartScreen warns about it. We publish a SHA-256 so you can check the file. Signed builds are in progress, and macOS and Linux packages follow.
Has it been independently reviewed?
takehsm had one independent security review with no critical or high findings, and its medium findings were fixed. We also test it against a hostile platform and against our real one. That is not a certification.
Questions before you start? Talk to us. You can read about the takehsm key holder on the Secrets Manager page, and about every protection in Security at Takelan.