Free tier · No sales call · API key ready in 5 minutes

Post-quantum security
for every developer.
Build on it.

Signing, certificates and agent authorization in one API. Start free: account, project, CA and API key ready in 5 minutes, no sales call.

Start for free → Try sandbox →
$ npm install fipsign-sdk
$ pip install fipsign-sdk
Free tier every month — no credit card
No infrastructure · No DevOps · No sales call
ML-DSA-44/65/87 (NIST FIPS 204)
JS/TS SDK · Python SDK · MCP for Claude
Use cases

Sign it. Certify it.
Authorize it.

Sign tokens, issue certificates, or authorize agents — each with its own minimal payload. No infrastructure to run, no signing keys to store.

👤
User sessions
Sign login tokens with quantum-resistant signatures. Verify each request in memory in ~1ms with the JS SDK, or remotely when you need revocation.
sub: "user_123"
🧾
Orders & payments
Sign payment intents and order confirmations. Prove a transaction was authorized at a specific moment — tamper-evident.
sub: "order_456"
🪪
Device identity
Create your own Private CA and issue a verifiable ML-DSA certificate per device — the identity layer for a fleet you control end to end.
ca.issue({ subject: "device_00123" })
🔐
Service-to-service auth
Issue X.509 or PQCert certificates your services present to each other — your own private CA, with no PKI servers to run.
ca.issue({ subject: "svc-billing" })
🤖
AI agent authorization
Give each agent a credential with scope and budget, then narrow, suspend, or revoke it in real time as it acts.
mandate.emit({ agentId, scope, budgetTotal })
📡
Fleet & IoT control
Authorize thousands of devices under one bounded credential per unit — control what each one can still do without touching firmware.
mandate.emit({ agentId: "device_iot_001" })
Sign

Sign any claim or document hash.
Verifiable, revocable, quantum-resistant.

RSA and elliptic-curve signatures — the ones behind JWTs (RS256/ES256), TLS certificates and code signing — can be broken by Shor's algorithm on a large enough quantum computer. Sign replaces them with ML-DSA (NIST FIPS 204): send a subject plus your own fields — or the SHA-256 hash of a document — and get back a signed, verifiable, revocable token.

How it works
01
Sign
Send a subject and your own fields — a user session, an order, or the hash of a document. Get back a signed ML-DSA token.
02
Verify
Verify locally in memory (JS SDK, ~1ms, no API call) or remotely from any language — remote verify also checks revocation.
03
Revoke
Invalidate a token instantly. Every future remote verify rejects it, even if the signature is still valid.
04
Integrate
JS/TS SDK, Python SDK, REST API, and MCP servers for Claude Desktop & Claude Code.
Private Certificate Authority

Your own CA.
Certificates you issue and control.

One ML-DSA-65 certificate authority per project, created from the dashboard in seconds. Issue and revoke certificates for devices, services, or agents — no PKI expertise required, no infrastructure to run yourself.

PQCert — native JSON format
→Native JSON, verified offline in ~1ms with ca.verifyCert()
→Simple JSON — no PEM parsing, no OpenSSL dependency
→Right for: IoT devices, AI agents, systems where you control both ends
X.509 — standard PEM format
→Standard X.509 v3 PEM, parseable with OpenSSL 3.5+ (RFC 9881)
→Larger (~7.5KB PEM), readable by any tool that supports ML-DSA X.509 certificates
→Right for: enterprise environments integrating with existing systems
How it works
01
Create
One-time setup from the dashboard — choose PQCert or X.509. Save the root certificate, shown only once.
02
Issue
Call POST /ca/issue at runtime with a subject and public key. Get back a signed certificate.
03
Verify
Any holder of the root certificate can verify offline — ca.verifyCert() or ca.verifyX509Cert(). No API call needed.
04
Revoke
POST /ca/revoke — immediate. Check status anytime via GET /ca/crl.
Private CA documentation & reference →
Bounded Authorization

Authorize agents & devices.
With limits you control.

Mandate is a PQ-Sign feature that issues signed session credentials for agents, devices, and services — with explicit scope, budget, and real-time control.

POST /sign — single event
→Signs one action or event
→No mutable state — immutable after signing
→Revoke only — no suspend, no scope control
→Right for: audit trails, payments, documents
POST /mandate — session credential
→Authorizes a session with defined scope
→Mutable state — suspend, resume, narrow scope
→Budget enforcement — deduct units per action
→Right for: AI agents, IoT, microservices, delegation
How it works
01
Emit
Call POST /mandate with agentId, scope, budget, and TTL. Get back a signed ML-DSA token.
02
Verify
Your service — or the agent itself, with an agent key — calls POST /mandate/verify before the action. Checks signature + live scope + budget. Granted or denied.
03
Control
PATCH /mandate/:id — narrow scope, suspend, resume, or revoke at any time.
04
Inspect
GET /mandate/:id — check budget consumed, current scope, status, and time remaining.
Mandate documentation & reference →
Get started

Ready to use
in 5 minutes

Account, project, API key and — if you need it — a Private CA: about five minutes from the dashboard. Then install an SDK and make your first call.

01
Create your account and project
Sign up with your email and verify the OTP. Create a project, choose its ML-DSA level, copy your API key and — if you need certificates — create your Private CA. No credit card, no sales call, no contract. Free tokens every month — immediately.
app.fipsign.dev
02
Install the SDK
One command for JS/TS — works in Node.js, Deno, Cloudflare Workers, and the browser. One command for Python — works in any backend, script, or data pipeline. Or use the REST API directly from any language with an HTTP client.
npm install fipsign-sdk pip install fipsign-sdk
03
Sign, certify, or authorize
Sign a token, issue a certificate from your Private CA, or emit a Mandate for an agent. Same API key, same account, no infrastructure to run — we handle the cryptography.
pq.sign({ sub: entityId }) pq.ca.issue({ subject }) pq.mandate.emit({ agentId, scope })
Why FIPSign

Simple API.
No infrastructure needed.

Rolling your own post-quantum signing means servers, key storage, revocation and certificate tooling to build and maintain. FIPSign gives you those primitives, finished, as an API.

Doing it yourself
✕Run and patch your own signing service
✕Generate, store and rotate ML-DSA keys safely
✕Build revocation from scratch
✕Build certificate issuance and agent authorization yourself
✕Keep up as the standards evolve
FIPSign
✓No infrastructure — fully managed on Cloudflare Edge (300+ locations)
✓Self-service — create an account, get an API key, start signing in minutes
✓Free tokens every month — no credit card, no contract, no sales call
✓JS/TS SDK, Python SDK, and REST API — any language, any stack
✓Ready to use in 5 minutes — account, project, CA and API key, all from the dashboard
✓Unlimited projects and API keys — isolate environments, clients, or services from one account
Pricing

Start free.
Pay as you grow.

Every account gets 2,000 free tokens per month — a token is one billable API call. When you need more, buy token packs — they never expire and accumulate across purchases.

FREE TIER — no credit card required
$0 / month
Get started today. 2,000 tokens reset on the 1st of each month.
  • 2,000 tokens / month — free, always
  • ML-DSA signing & verification — choose ML-DSA-44, ML-DSA-65, or ML-DSA-87 per project
  • Token revocation
  • Offline verification in the JS SDK (~1ms, no API call)
  • Usage dashboard & 6-month history
  • Webhook notifications
  • JS/TS SDK — Node.js, Deno, Cloudflare Workers, browser
  • Python SDK — sync + async, Flask & FastAPI middleware
  • MCP servers — use FIPSign directly from Claude Desktop & Claude Code
  • Express middleware (Fastify via @fastify/express)
  • Private CA — one per project, ML-DSA-65 certificates for devices, services & agents
  • Mandate — bounded authorization for agents, IoT & microservices with scope, budget & real-time control
  • Zero-Exposure Signing — hash locally, sign the digest. Your sensitive data never reaches the API.
  • X.509 Certificate Support — standard PEM format, parseable with OpenSSL 3.5+ (RFC 9881)
  • Email support — [email protected]
Get started free →
Try without signing up →
One account. No limits.
Unlimited projects. Unlimited API keys per project. Per-project token usage stats. One CA per project — choose PQCert (JSON) for simplicity or X.509 (PEM) for enterprise PKI compatibility. Issue, verify, and revoke ML-DSA-65 certificates for devices, services, and agents.
Isolate clients, environments, or microservices — no extra cost, no enterprise plan required.
Need more tokens? — Buy a pack
Lite
$19
25,000 tokens
$0.76 / 1K tokens
MOST POPULAR
Pro
$49
100,000 tokens
$0.49 / 1K tokens
Scale
$149
500,000 tokens
$0.298 / 1K tokens
Pack tokens never expire · Accumulate across purchases
1 token: sign · verify · revoke · issue or revoke a certificate
2 tokens: Mandate emit · granted Mandate verify (denials are free)
Free: reads (CA, mandates, usage, public key) · Mandate control (suspend, resume, narrow, revoke)
Need more? Contact us →
vs the alternatives

AWS and Google have ML-DSA.
That's not the same thing.

AWS KMS and Google Cloud KMS are key management services. FIPSign is signing, certificates, and agent authorization in one API. The difference shows up before your first signature: in the setup.

This is FIPSign
FIPSign
fipsign.dev
AWS KMS
+ ML-DSA
Google Cloud KMS
ML-DSA GA
Setup time
FIPSign: register, create a project, copy your API key — and create a CA from the dashboard if you need one. AWS/GCP: create an account, set up billing and IAM, then create a key (and a key ring on Google Cloud) before the first call.
✓
~5 minutes
✗
Account, billing, IAM and key setup first
✗
Account, billing, IAM and key setup first
What you're calling
/sign, /ca/issue, and /mandate are the whole product. On KMS, signing is one operation among hundreds — certificates and agent authorization aren't a concept at all.
✓
Sign, CA, Mandate
✗
A key management service
✗
A key management service
Cloud account required
FIPSign works standalone. AWS and GCP require an account, billing setup, and IAM configuration before any signing happens.
✓
No
✗
Yes — AWS account
✗
Yes — GCP account
Platform dependency
FIPSign is HTTP. Move to any stack, any cloud, any language without re-architecting.
✓
No cloud lock-in — pure REST
✗
Locked to AWS
✗
Locked to GCP
Persistent free tier
FIPSign's free tier doesn't expire. AWS KMS's always-free requests exclude asymmetric Sign and Verify, and new-account credits on AWS and Google Cloud are time-limited.
✓
2,000 tokens/month
✗
6-month credits (up to $200)
✗
New-customer credits (expire)
Dedicated JS/TS SDK
A focused signing SDK — sign, verify, revoke, CA certificates, Mandate, Zero-Exposure Signing. AWS and GCP SDKs expose the entire cloud API surface with hundreds of unrelated operations.
✓
fipsign-sdk on npm
✗
Generic AWS SDK
✗
Generic GCP SDK
Dedicated Python SDK
A focused SDK vs a generic cloud SDK that happens to include signing.
✓
fipsign-sdk on PyPI
✗
boto3 (generic)
✗
google-cloud-kms
Token revocation
KMS signs bytes. It has no concept of tokens, sessions, or revocation. FIPSign lets you revoke any token it issued, and remote verification checks the revocation list.
✓
Native — /revoke endpoint
✗
Not a concept
✗
Not a concept
Bounded authorization for AI agents
KMS signs bytes with a key — it has no concept of a session, a spending budget, or a scope that narrows over time. FIPSign's Mandate issues a credential with all three, controllable in real time.
✓
Mandate — scope, budget, TTL
✗
Not a concept
✗
Not a concept
Private Certificate Authority
FIPSign: create a CA from the dashboard in seconds, no cloud account needed. AWS Private CA and Google CAS require full cloud account setup, IAM, and per-certificate billing.
✓
Self-service — dashboard
✗
Requires AWS account + IAM
✗
Requires GCP account + IAM
MCP for Claude
FIPSign ships dedicated MCP servers, so Claude Desktop and Claude Code can sign tokens, issue certificates and manage revocation through natural language. AWS offers general-purpose API servers that can reach KMS; Google Cloud's MCP list has no Cloud KMS server.
✓
@fipsign/mcp · fipsign-mcp
✗
Generic AWS API server
✗
No Cloud KMS server listed

Competitor details checked on 1 October 2026: AWS KMS pricing · AWS Free Tier · AWS MCP servers · Google Cloud KMS ML-DSA · Google Cloud MCP products. Spot an error? [email protected]

Ready?

Post-quantum security in minutes.
No sales call required.

Sign tokens, issue certificates, authorize agents. Free tokens every month. No credit card, no contract, no infrastructure to run. Just an API key.

Create free account → Developer guide →
FAQ

Common questions
from developers

Everything you need to know before integrating FIPSign into your stack.

Why sign post-quantum today, if quantum computers cannot break anything yet? +
Because a signature outlives the day it is made. Certificates, contracts, firmware and audit trails stay valid for years, and a signature made with ECDSA or RSA today can be forged on the day a large enough quantum computer exists — anyone could then fake an old record. Nobody knows when that day comes, and migrating production systems takes years. NIST finalized the first post-quantum standards in August 2024 (FIPS 203, 204 and 205), so there is something real to migrate to now. FIPSign signs with ML-DSA (FIPS 204).
Does my data reach your servers, and do you store it? +
In the standard signing flow, yes: your payload travels to our servers under TLS, where it is signed and immediately discarded. Signing is stateless — we sign it with ML-DSA (using your project's configured algorithm) and return the token. The only thing we keep is for revocation: when you revoke a token, we store a SHA-256 hash of its signature as a lookup key, never the payload itself.

If sensitive data must never leave your infrastructure, use Zero-Exposure Signing (ZES): hash your payload locally using SHA-256 and send only the 64-character hex digest to the API. We sign the hash, never the original data. The signed token is cryptographically tied to your data without us ever seeing it.

ZES uses the standard POST /sign and POST /verify endpoints — no extra cost, no configuration required. See the developer guide (REST API tab, section 03b) for the full reference with curl, JavaScript, and Python examples.
What happens if your service goes down? +
Tokens already issued remain verifiable. Enable localVerify: true in the JS SDK and verification runs entirely in memory using the cached public key — no API call, no dependency on our uptime. Anything that creates or changes state needs the API: signing, remote verification (which checks revocation), revocation, certificates and Mandate. Local verification is a JS SDK feature.
Which ML-DSA algorithm should I choose? +
FIPSign supports all three NIST FIPS 204 variants — ML-DSA-44, ML-DSA-65, and ML-DSA-87 — configurable per project at creation time. The algorithm is immutable after creation.

ML-DSA-65 (recommended default) — NIST Security Level 3. The right balance for most API use cases: strong security, reasonable signature size (~3.3 KB), and fast enough for production throughput.

ML-DSA-44 — NIST Security Level 2. Faster and smaller signatures (~2.4 KB). Good choice for high-throughput scenarios or constrained environments where the slightly lower security level is acceptable.

ML-DSA-87 — NIST Security Level 5. Maximum security, larger signatures (~4.6 KB). It is the parameter set NSA's CNSA 2.0 specifies for digital signatures, and the choice when your policy demands the highest level. Using it does not by itself make a system compliant.

When in doubt, use ML-DSA-65 — it is what we would recommend to any team starting fresh today.
How does revocation work? +
When you revoke a token, we store a SHA-256 hash of its ML-DSA signature in a blacklist backed by Cloudflare D1. Every remote /verify call checks that blacklist before returning a result. Revoked entries expire automatically when the original token would have expired — no manual cleanup needed.
Does local verification check revocation? +
No. Local verification runs entirely in memory and checks only the cryptographic signature and token expiry — it never contacts the API. Use remote verification for any operation where revocation matters: payments, admin actions, logout enforcement.
Can I use this from Python, Go, or any non-JS language? +
Yes. There's a native Python SDK (pip install fipsign-sdk) with sync and async clients, Flask and FastAPI middleware, and the same operations as the JS SDK (one difference: Python has no local verification — every verify is a remote call). For Go or any other language, every operation is available via REST API — standard HTTP with JSON. The developer guide covers all three.
Is this open source? +
Both SDKs are fully open source — the JS SDK and the Python SDK — you can read exactly what's being sent to the API. The backend is not open source. The cryptographic operations use @noble/post-quantum, an open-source implementation of ML-DSA (44/65/87). Its author states it has not yet been independently audited and does not claim constant-time execution — a residual risk we have accepted and documented.
Why SaaS and not a self-hosted library? +
Key management and revocation. Running ML-DSA yourself means generating and storing keys securely, handling key rotation, and building a revocation system from scratch. FIPSign handles all of that — including one keypair per project, in the ML-DSA variant you choose. If you need the public key to verify tokens on your own infrastructure without any API call, fetch it once via GET /public-key (requires your API key) and cache it locally.
What is the Private CA and when do I need it? +
The Private CA lets you issue post-quantum certificates for devices, agents, or services — not just sign tokens. If you're building IoT, embedded systems, AI agents, or any scenario where an entity needs a verifiable identity with an expiry date, the CA is the right tool. Each project gets one CA root, created from the dashboard in seconds. Certificate issuance and revocation happen via API key at runtime.
Where is the CA private key stored? +
The CA private key never leaves our infrastructure and is never returned to the client. It's stored encrypted in Cloudflare KV using AES-256-GCM, isolated per project. The root certificate (public) is returned once at creation — save it, as it's what you'll use to verify issued certificates offline without any API call.
Can I use FIPSign directly from Claude? +
Yes. FIPSign has native MCP servers for both TypeScript and Python — @fipsign/mcp on npm and fipsign-mcp on PyPI. Once connected, you can sign tokens, issue certificates, and manage revocation from Claude Desktop or Claude Code through natural language. All 11 tools are exposed for use in Claude. See the MCP tab in the developer guide for setup instructions.
What is the difference between PQCert and X.509? +
Both are ML-DSA-65 certificates — the difference is format and compatibility.

PQCert is FIPSign's native JSON format. Simple to work with in code, and verified offline with ca.verifyCert() in ~1ms. Best for IoT devices, AI agents, and any system where you control both ends of the verification.

X.509 is the standard PEM format (X.509 v3), parseable with OpenSSL 3.5+ (RFC 9881). Larger (~7.5KB PEM), but readable by any tool that supports ML-DSA X.509 certificates. Best for environments where certificates need to integrate with existing PKI.

The format is chosen once at CA creation and cannot be changed. If you're not sure, start with PQCert — it's simpler. Switch to X.509 if you have existing PKI infrastructure to integrate with.
What is Mandate and when should I use it? +
Mandate is a PQ-Sign feature that issues a signed ML-DSA session credential for an agent, device, or service — with explicit scope (what it can do), budget (how much it can spend), and a TTL (how long it can operate). Unlike POST /sign which issues a token for a single event, a mandate governs a full session and gives you real-time control over it.

Use Mandate when you need to authorize something that operates autonomously over time: an AI agent executing tasks on behalf of a user, an IoT device reporting for 30 days, a microservice calling another service within a quota, or any delegation scenario where you want hard limits that FIPSign enforces on every verify call.

Three things make Mandate different from a regular signed token:

  • Scope enforcement — define exactly what actions are allowed. Verify denies anything outside the scope, and you can narrow it further at any time without reissuing the mandate.
  • Budget enforcement — define a budget in abstract units. Each POST /mandate/verify call deducts a cost. When the budget is exhausted, further actions are denied automatically.
  • Real-time control — suspend, resume, narrow, or revoke a mandate at any time via PATCH /mandate/:id using only the mandate ID — no need to have the original token.

See the Mandate reference in the developer guide for the full API, examples, and a complete test script.
Is FIPSign certified (FIPS 140-3, SOC 2, ISO 27001)? +
No. FIPS 204 is the NIST standard that defines the ML-DSA algorithm, which FIPSign implements; it is not a certification of FIPSign. FIPSign has not been through FIPS 140-3 module validation or SOC 2 / ISO 27001 audits. We would rather keep the price low and say so than imply a compliance we do not have. If your organization requires one of those certifications, FIPSign is not the right fit today.
Do you have a status page? +
Yes — our status page shows real-time uptime and response times. You can also check the raw health endpoint at api.fipsign.dev/health.
Still have questions? [email protected] →