Anonymous View
No DevOps · No sales call · Production in 5 minutes

Sign & Certify anything.
Quantum-resistant.

Post-quantum signing and certificates as a service. No infrastructure to manage, no sales call, no contract. Get an API key, call /sign for tokens or /ca/issue for certificates — JSON (PQCert) or X.509 — protected by ML-DSA-65 (NIST FIPS 204) in minutes.

Start for free →
$ npm install fipsign-sdk
$ pip install fipsign-sdk
10,000 free tokens/month — no credit card
No infrastructure · No DevOps · No sales call
ML-DSA-65 (NIST FIPS 204)
JS/TS SDK · Python SDK · MCP for Claude
Use cases

Not just auth.
Sign anything.

The only required field is sub — any string identifying the entity you want to sign. Everything else is up to you.

👤
User sessions
Sign login tokens with quantum-resistant signatures. Verify on every request without a database round-trip.
sub: "user_123"
🧾
Orders & payments
Sign payment intents and order confirmations. Prove a transaction was authorized at a specific moment — tamper-proof.
sub: "order_456"
📄
Documents
Certify contracts, reports, and audit trails with a cryptographic signature that survives quantum computing.
sub: "doc_789"
📡
IoT & devices
Authenticate firmware updates and device telemetry. Each message signed and verifiable without shared secrets.
sub: "device_iot_001"
🔗
API access tokens
Issue scoped, expiring tokens for your own API. Revoke instantly — future verify calls reject them even if the signature is valid.
sub: "api_client_xyz"
🏛️
Compliance & audit
Prove data integrity for regulatory audits. NIST FIPS 204 compliance out of the box — no cryptography expertise required.
sub: "audit_event_001"
The problem

Classical signatures
have an expiry date

Every signature made with ECDSA or RSA today can be forged by a quantum computer running Shor's algorithm. The NIST already published the replacements in 2024.

⚠️
ECDSA & RSA are broken
JWT (RS256/ES256), OAuth tokens, TLS certificates — all rely on algorithms that Shor's algorithm can break efficiently on a sufficiently powerful quantum computer.
VULNERABLE
🎯
Harvest now, decrypt later
Nation-state actors are already recording signed traffic today to forge or decrypt it once quantum computers are available. Your signatures are at risk right now.
ACTIVE THREAT
📅
Migration takes years
Cryptographically relevant quantum computers are 10–20 years away — but migrating production systems takes years. The NIST finalized post-quantum standards in August 2024. The developers who migrate now become the compliance story later — when the audit comes, they're already done.
ACT NOW
The solution

One API. Any entity.
Quantum-resistant.

Create an account, get an API key, call /sign. That's it. ML-DSA-65 handles the cryptography.

BEFORE — Classical, quantum-vulnerable
sign.js ECDSA / RS256 
// Classical JWT — vulnerable to Shor's algorithm
import jwt from 'jsonwebtoken'

const token = jwt.sign(
  { sub: user.id, role: 'admin' },
  SECRET_KEY,
  { algorithm: 'RS256' } // ← breakable by quantum
)

const payload = jwt.verify(token, PUBLIC_KEY)
AFTER — ML-DSA-65, quantum-resistant
sign.js ML-DSA-65 
// FIPSign — ML-DSA-65, NIST FIPS 204
import { PQAuth } from 'fipsign-sdk'

const pq = new PQAuth('pqa_your_api_key')

// Sign any entity — user, order, document, device
const { token } = await pq.sign({
  sub: order.id, amount: 299.99, currency: 'USD'
})

const { valid, payload } = await pq.verify(token)
SIGN ANYTHING — sub is the only required field
examples.js 
const pq = new PQAuth('pqa_your_api_key')

// User session
const { token: userToken } = await pq.sign({ sub: 'user_123', role: 'admin', expiresInSeconds: 3600 })

// Payment intent
const { token: orderToken } = await pq.sign({ sub: 'order_456', amount: 1500.00, currency: 'USD' })

// Document certification
const { token: docToken } = await pq.sign({ sub: 'doc_789', hash: 'sha256:abc...', signedBy: 'alice' })

// Verify — never throws, returns { valid, payload } or { valid: false, error }
const { valid, payload } = await pq.verify(userToken)

// Revoke instantly — future verify() calls reject it even if signature is valid
await pq.revoke(orderToken, 'order cancelled')
Get started

Up and running
in 5 minutes

01
Create your account
Sign up with your email. Verify the OTP. No credit card, no sales call, no contract. 10,000 free tokens per 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 anything
Pass any object with a sub field. Get back a quantum-resistant signed token. No infrastructure to run, no keys to manage — we handle the cryptography.
pq.sign({ sub: entityId })
Why FIPSign

Simple API.
No infrastructure needed.

Other post-quantum solutions require servers, DevOps, and a sales call to get started. FIPSign works in 5 minutes.

Other PQ solutions
✕Self-host your own server (MongoDB + Redis + Docker)
✕Contact sales for managed hosting — custom pricing, no self-service
✕Managed PQ signing requires sales engagement — no public pricing, no self-service
✕Complex OAuth flows, PKCE, grant types, and token exchange just to sign a payload
✕Days or weeks to go from zero to production
✕Per-project isolation requires multiple accounts or enterprise plans
FIPSign
✓No infrastructure — fully managed on Cloudflare Edge (300+ locations)
✓Self-service — create an account, get an API key, start signing in minutes
✓10,000 free tokens/month — no credit card, no contract, no sales call
✓JS/TS SDK, Python SDK, and REST API — any language, any stack
✓Production-ready in 5 minutes — one install command + one API call
✓Unlimited projects and API keys — isolate environments, clients, or services from one account
Pricing

Start free.
Pay as you grow.

Every account gets 10,000 free tokens per month. 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. 10,000 tokens reset on the 1st of each month.
Each sign, verify, or revoke operation costs 1 token.
  • 10,000 tokens / month — free, always
  • ML-DSA-65 signing & verification
  • Token revocation
  • Offline verification (~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 / Fastify middleware
  • Private CA — one per project, ML-DSA-65 certificates for devices, services & agents
  • X.509 Certificate Support — standard PEM format, compatible with OpenSSL 3.5+, Java keystores, nginx
  • Email support — [email protected]
Get started free →
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
$9
25,000 tokens
$0.36 / 1K tokens
MOST POPULAR
Pro
$29
100,000 tokens
$0.29 / 1K tokens
Scale
$99
500,000 tokens
$0.198 / 1K tokens
Pack tokens never expire · Accumulate across purchases
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 a signing API. The difference shows up the moment you try to make your first signature.

This is FIPSign
FIPSign
fipsign.dev
AWS KMS
+ ML-DSA
Google Cloud KMS
ML-DSA preview
Time to first signature
FIPSign: register, get API key, call /sign. AWS/GCP: create account, set up IAM, configure key ring, write SDK boilerplate.
✓
~5 minutes
✗
~1–2 hours
✗
~1–2 hours
What you're calling
/sign and /verify are the whole product. On KMS, signing is one operation among hundreds.
✓
A signing API
✗
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.
✓
None — pure REST
✗
Locked to AWS
✗
Locked to GCP
Persistent free tier
FIPSign's free tier doesn't expire. AWS and GCP free tiers are time-limited onboarding offers.
✓
10,000 tokens/month
✗
90-day trial only
✗
GCP credits (expire)
Dedicated JS/TS SDK
A focused signing SDK — sign, verify, revoke, CA certificates, webhooks. 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 tracks every signature and lets you invalidate it.
✓
Native — /revoke endpoint
✗
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
Native MCP for Claude
Use FIPSign directly from Claude Desktop and Claude Code via MCP — sign tokens, issue certificates, and manage webhooks through natural language. AWS KMS and GCP KMS have no MCP integration.
✓
@fipsign/mcp · fipsign-mcp
✗
No MCP support
✗
No MCP support
Ready?

Post-quantum signing.
No sales call required.

10,000 free tokens/month. No credit card, no contract, no infrastructure. Just an API key.

Create free account → Developer guide →
Just shipped

Private CA · X.509 · MCP
all live.

Built in public. No sales call required — now or ever.

Now available
🏛️
Private CA
Issue and revoke ML-DSA-65 certificates for devices, services, and agents. One CA per project — created from the dashboard in seconds. No PKI expertise required.
📡 IoT & devices
🚛 Fleet & logistics
🏥 Healthcare
🤖 AI agents
Just shipped
🔐
X.509 Certificate Support
Issue ML-DSA-65 certificates in standard X.509 PEM format — compatible with existing PKI infrastructure. No changes to your stack required.
OpenSSL 3.5+
Java keystores
nginx / HAProxy
Enterprise PKI
Just shipped
🤖
MCP Servers
Use FIPSign directly from Claude — sign tokens, issue certificates, and manage webhooks through natural language. Works in Claude Desktop and Claude Code.
npx @fipsign/mcp
uvx fipsign-mcp
Claude Desktop
Claude Code
Building something that needs PQ certificates? Tell us about your use case →
FAQ

Common questions
from developers

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

Do you store my token payloads? +
No. Signing is stateless — we receive your payload, sign it with ML-DSA-65, and return the token. Nothing is persisted. For revocation, we store only a SHA-256 hash of the signature as a lookup key, never the payload itself.
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. The only operations that require the API are signing new tokens, remote verification (which checks revocation), and revocation itself.
Why ML-DSA-65 and not ML-DSA-44 or ML-DSA-87? +
ML-DSA-65 hits the right balance for API use cases — NIST security level 3, reasonable signature size, and fast enough for production throughput. ML-DSA-44 is faster but lower security. ML-DSA-87 is higher security but produces larger signatures with no practical benefit for most applications. Level 3 is what we'd 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-65 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 full feature parity with the JS SDK. 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, a widely audited implementation of ML-DSA-65 that you can verify independently.
Why SaaS and not a self-hosted library? +
Key management and revocation. Running ML-DSA-65 yourself means generating and storing keys securely, handling key rotation, and building a revocation system from scratch. FIPSign handles all of that. If you need the public key to verify tokens on your own infrastructure without any API call, it's available at /public-key at no cost.
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 webhooks from Claude Desktop or Claude Code through natural language. All 15 API operations are exposed as MCP tools. 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. Lightweight (~4KB), 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 compatible with OpenSSL 3.5+, Java keystores, nginx, and existing PKI infrastructure. Larger (~7.5KB PEM) but works with any tool that understands X.509. Best for enterprise environments where certificates need to integrate with existing systems.

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.
Is there an on-premise option? +
Coming soon. FIPSign On-Premise will run entirely on your infrastructure — no outbound calls, no shared keys, full control. Distributed as a native binary (Linux x64/arm64, macOS) or Docker image. The same JS/TS SDK, Python SDK, and REST API work unchanged — just point baseUrl to your instance.

If you have a use case that requires on-premise today, contact us — we're working with early partners on the initial deployment.
Do you have a status page? +
Yes — status.fipsign.dev 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] →