ROOSTby Axowl

No keys.
Nothing to steal.

Roost is a hardware security module that signs only what was approved. Three chips from three manufacturers must agree, and the root key is never stored anywhere.

Request a demo See how it works
3 chips
from three different manufacturers
2 of 3
must agree before anything is signed
0
root keys stored on disk or flash
Instant
erase when the enclosure is opened

Why Roost

Built so that a stolen box, a rogue server or a single bad chip cannot sign for you.

No approval, no signature

Sensitive keys sign only when the request carries a passkey approval from the right people, bound to the exact content.

Nothing to steal

Each chip rebuilds its root from its own physical fingerprint at power-up. Keys exist only as pieces that are useless outside their chip.

Two of three must agree

Every signature needs two chips from different manufacturers to agree. One compromised or failed chip cannot sign alone.

AI agents, governed

Agents get their own identity, short-lived credentials, usage limits and human approval for risky actions. Every action is recorded.

In practice

Your build server is compromised. Your code signing key is still safe.

A conventional HSM protects the key but signs whatever an authenticated server sends. Roost checks who approved the release before it signs.

01
Build server
Sends a signing request for a release artifact.
02
Roost checks approval
Is there a passkey approval for this exact artifact hash?
NO APPROVAL
Refused, with the reason
Logged and alerted. The attacker gets nothing.
APPROVED
Signed by 2 of 3 chips
Recorded with who approved which build.

Use cases

One box for the keys that matter most.

Code signing
Only approved releases get signed.
Documents and e-signatures
From approval to signed PDF in one flow.
Certificate authority keys
Issue certificates under quorum and approval.
Data encryption
Envelope encryption with every unwrap recorded.
TLS keys
Server identity that never leaves the box.
AI agents
Delegated signing with limits and approvals.
Robots and IoT
A trust anchor for machines in the field.
Cloud keys
Hold your own key for data in the cloud.

Management console

One console for keys, approvals, devices and records.

Each product has a tile with live counts. Every sensitive action waits in one approvals inbox for passkey seals. Every refusal says why.

See the console
axowl.com/dashboard/acme/roost
AxowlacmeRoostM

Products

Code signing12 signed today · 1 awaiting approval
Documents38 signed today
Certificate authority2 issued this week
Data encryption1,204 unwraps today
TLS keys3 keys · pair OK
AI agents4 agents · 2 limits hit
Sealed receipts89,261 total
App connectionsPKCS#11 · Java · gateway
Cloud keys3 clouds · 11 keys
CI/CD2 runs active · 0 keys left behind
ROOST-26-0001 · ROOST-26-0002 · pair OK · 3/3 voters · armed
Console home: one tile per product, with live counts.

Why security teams trust it

Claims you can check, not promises.

Verifiable by anyone

Signatures meant for third parties are public-key signatures. Anyone with the public key verifies them, without trusting Axowl or the box. Internal seals are confirmed by the chips themselves.

No vendor door

Axowl holds no key, no PIN and no way to sign on your behalf. Nothing on a box changes without your owners' passkeys, and every such action is a sealed record.

No outbound connection

Roost runs on your network and never calls home. Air-gapped sites run on signed files alone.

Refuses by default

No quorum, no approval, a wrong purpose, a clock outside policy or an opened enclosure: Roost refuses, says why, and records it.

Replay cannot happen

Every seal includes a counter that only moves forward, so an old signature cannot be presented as a new one.

Secrets never in logs

Records carry who, what and when with correlation ids. Key material and credentials never appear in a log, a report or an error.

Deployment

Where Roost runs.

In your rack

Roost runs inside your network with no outbound connection: your server room, your plant, your vault floor.

Air-gapped

A box that never talks to the server runs the same steps as files carried by USB or QR. Status, usage and enrollment all travel as signed files.

As a pair

Roost is sold in pairs. The second box holds pieces of the same keys, so a failed box is replaced without a service break and never repaired on site.

Cloud-managed or not

Manage boxes from the Axowl console, or keep everything on site. The box signs its own status reports either way.

Developers

Standard interfaces. Nothing heavy to install.

Use Roost from Java, from any PKCS#11 client, or with a plain HTTPS call. Try everything first on the simulator, which runs the same policy code as the device.

Read the docs Try the simulator
// Java: sign through Roost
var provider = new RoostProvider(gateway);
var sig = Signature.getInstance(
    RoostProvider.ALGORITHM, provider);
sig.initSign(provider.signingKey("release-ledger"));
sig.update(message);
byte[] receipt = sig.sign();

Compare

Roost and a conventional HSM

Conventional HSM Roost
Before signingChecks that the client is logged inChecks who approved this exact content
Root keyStored in protected memoryRebuilt from the chip's physical fingerprint, never stored
Who signsOne device2 of 3 chips from different manufacturers
Backup domainA domain secret carried by peoplePieces held by chips, shared only with multi-person approval
AI agentsUse an application's credentialsOwn identity, limits and approvals
Audit evidenceLogs you export and assembleSealed records and signed reports, ready for auditors

Learn

See it, read it, try it.

Video
Roost in 35 seconds
The box, the chips and the quorum.
Technical paper
Layered integrity sealing
For security engineers. Sign-in required.
Docs
Quick start
From simulator to first signature.

See Roost refuse an unapproved signature.

A 30-minute live demo with our engineers.

Request a demo