How Takelan protects your data
Six layers of protection. Each one still holds if the one before it fails. See what each layer does, where to find it, and what we do not claim.
Read this first. We are working on SOC 1 and SOC 2, but no report is out yet. This page shows how we build and test the product. It is not an audit result. In the standard Managed class, the platform can read a secret for an approved caller. So it is not zero-knowledge. The Leased class moves the key to you. Takelan still sees names, sizes and timing. It also handles the value when you write or read it. Customer-held keys are rolling out. See the status on each row below.
Six protections
Each layer still works if the one before it fails.
Encryption by default
Each secret gets its own random key and is locked with AES-256-GCM, a strong encryption method. That key is wrapped by a key made just for your organization, using PBKDF2-SHA256 at 600,000 rounds. Backups and exports of secrets stay scrambled.
See how the Secrets Manager encryptsCustomer-held keys
takehsm is an open source key holder. You run it on your own machine. For Leased secrets, the key never leaves it. So a database dump plus the platform master key opens nothing. Takelan still sees names, sizes and timing. It is software, not a hardware HSM.
See what zero-knowledge means here and what is liveApprovals the platform cannot fake
Changes that grant access need a fresh passkey check. On protected servers they also need a grant signed by M of N hardware approvers. The agent on your server checks the signatures. The platform only passes them along.
See SSH approval tiers in the SSH Access ManagerAudit you can verify
The vault and SSH audit logs are hash chains. A verify call finds the first entry that was changed or removed. No web route deletes them. The key holder and the server agent keep their own chained logs too.
See the vault audit logTenant isolation, tested
Your tenant comes from your signed token. Every route names a permission. Before each release, we scan every route. We also run a live test with two real tenants. Then we fix what we find.
See how sign-in and roles work in Takelan SSOReview and testing
takehsm had one independent security review. It found no critical or high issues. We test it against a hostile platform and against the real one. We also run our own read-only reviews of recent changes and fix what they find.
See how takehsm was testedSee how it holds
See what stops five common failures. See how we keep tenants apart.
What stands in the way
How tenants are kept apart
Who holds the key: platform-managed or customer-held
See where our keys protect your data and where yours do. See 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. |
| 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. |
| 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. |
What the words mean, what Takelan can still see, and the questions people ask: Zero-knowledge options explained.
Where each protection lives
Pick the product you use. Each page has diagrams and an honest list of limits.
What we do not claim
This list is part of our promise.
- No audit report is out yet. SOC 1 and SOC 2 work is in progress.
- The platform can read Managed secrets for an approved caller. Only Leased secrets move the key to you. Sealed and Delivered classes are still in design.
- takehsm is software, not a hardware HSM. Root access or malware on its machine defeats it. For now, the Windows installer is unsigned.
- While a holder is online, a hacked platform can get what your policy allows during a short lease.
- Audit logs show tampering. They do not stop it. Keep an outside copy if you need strong proof.
- Root access on a server defeats the SSH agent. The first install trusts the platform once, unless you compare the approver fingerprint.
- SSH Tier 3 (Sovereign) is on the roadmap. SSH Tier 2 uses approvals you verify. It is not zero-knowledge. It needs the 0.3.0 server agent.
- The public connection address for takehsm is not live yet. The Windows installer is an unsigned preview. macOS and Linux packages are not released.
- Our isolation scan and live test are our own testing, not an outside audit.
Questions about security
Where are SOC 1 and SOC 2?
That work is in progress and no report is out yet. This page shows how we build and test the product.
Can Takelan read my secrets?
For Managed secrets, yes, for an approved caller. The platform holds the master key. For Leased secrets, not on its own. The key lives in your takehsm key holder, and a database dump plus the master key opens nothing. While your holder is online, a hacked platform can still get what your policy allows during a short lease.
What does zero-knowledge mean at Takelan?
For one kind of data, Takelan cannot unlock what it stores, because you hold the key in a takehsm key holder. It does not mean Takelan sees nothing. Names, sizes and timing stay visible. Today it applies to Leased secrets, and the feature is live. The Zero-knowledge options page has details and a glossary.
Can Takelan add an SSH key to my server by itself?
Not on a Tier 2 protected server. The agent accepts a key change only with valid signatures from the approvers set at install. The signatures must match that exact request and time window.
How do you keep one customer from seeing another customer's data?
Your tenant comes from your signed token. Every route names a permission. Data access is limited to your tenant. Before each release, we scan every route and run a live test with two real tenants.
Has the product been independently reviewed?
takehsm had one independent security review with no critical or high findings. The rest of the platform has our own reviews and tests. Those are not an outside audit.
Can the audit log be changed?
Entries are chained by hash, so a verify call detects a change. No web route deletes the log. It shows tampering. It does not stop it.
Questions before you start? Talk to us. See our standards work: Compliance Center.