DEV Community: German

Your IoT Devices Will Outlive Your Cryptography

German — Tue, 09 Jun 2026 13:13:25 +0000

A smart meter installed today has a 15-year service life. A medical device implanted this year may still be transmitting data in 2040. An industrial sensor bolted into a factory floor will be there long after the engineer who commissioned it has moved on.

The certificates you issue to those devices today are signed with ECDSA or RSA. Those algorithms are secure against classical computers. They are not secure against a sufficiently large quantum computer running Shor's algorithm. NIST's own timeline puts cryptographically relevant quantum computers within a 10 to 15 year window — which lands squarely inside the service life of the devices you're deploying right now.

This is not a theoretical concern. It's a lifecycle mismatch.

The attack you're not thinking about

The threat model for most IoT security discussions is an attacker who breaks in today. Patch fast, rotate keys, monitor traffic. Classical defenses.

The threat model that matters for long-lived devices is different: an attacker who captures encrypted traffic today and decrypts it later, once quantum hardware is available. This is called harvest-now-decrypt-later, and it's already happening at the nation-state level. Governments and well-resourced adversaries are archiving encrypted data now, waiting.

For a medical device transmitting patient vitals, for a smart meter reporting energy consumption, for an industrial sensor logging process data — the data being transmitted today has value in 2035. The signature on the certificate authenticating that device has to be trustworthy in 2035.

ECDSA won't be.

What the migration looks like if you wait

The case for doing this now rather than later is not about fear. It's about cost.

Every IoT integration you build today on classical cryptography is technical debt with a known expiration date. The migration cost compounds with every device you deploy, every certificate you issue, every integration you build on top of RSA or ECDSA. Migrating a fleet of 10,000 devices in the field is a different problem than migrating a fleet of 100. Migrating when you're under regulatory pressure is a different problem than migrating on your own timeline.

NIST finalized ML-DSA-65 (FIPS 204) in August 2024. The standard exists. The implementations exist. The only missing piece is production integrations — systems where post-quantum signing is actually running, not in a proof of concept but in a real device fleet with real data.

What post-quantum device identity looks like in practice

The pattern for device identity in IoT is well-established: each device gets a certificate issued by a CA the organization controls. The certificate encodes the device's public key, its identity, and its authorized scope. When the device communicates, the certificate proves it belongs to your fleet. When a device is compromised or decommissioned, you revoke its certificate and the revocation propagates.

This pattern doesn't change with post-quantum cryptography. What changes is the algorithm underneath — ML-DSA-65 instead of ECDSA, with key sizes and signature sizes that reflect the difference in security model.

ML-DSA-65 public keys are 1952 bytes. Signatures are 3309 bytes. X.509 certificates come out around 5.5KB DER. These are larger than classical equivalents — worth accounting for in constrained environments, but not prohibitive for most IoT backends and gateways.

A concrete integration with FIPSign

FIPSign is a post-quantum signing API built on ML-DSA-65 (NIST FIPS 204). It runs a private CA per project — you issue certificates to your devices, verify them, and revoke them via REST API or SDK. No infrastructure to manage.

There are two distinct guarantees you can establish for an IoT device:

CA certificates answer the question "does this device belong to my fleet?" — identity at the device level, established once at provisioning time.
Signed tokens answer the question "was this specific reading transmitted by this device, at this exact time, unaltered?" — data integrity at the transmission level, established on every message.

For many systems, the certificate alone is sufficient. For systems where individual data points have legal, billing, or compliance consequences — smart meters, medical devices, industrial sensors — you want both. The certificate proves the device is legitimate. The signature on each transmission creates a tamper-proof audit trail of every data point it ever sent.

Here's what that looks like in practice:

Step 1 — Generate a key pair at provisioning time

import { PQAuth, generateKeyPair } from 'fipsign-sdk'

const fipsign = new PQAuth(process.env.FIPSIGN_API_KEY)

// Generate ML-DSA-65 key pair
// The secret key stays on the device — never sent to the server
const { publicKey, secretKey } = await generateKeyPair()

Step 2 — Issue a certificate from your CA

Your provisioning backend receives the device's public key and issues a certificate that encodes its identity and authorized scope:

// Provisioning backend — not the device itself
const { certificate, meta } = await fipsign.ca.issue({
  subject:          'device-serial-00123',
  publicKey:        devicePublicKey,
  expiresInSeconds: 5 * 365 * 24 * 60 * 60,  // 5 years
  meta: {
    deviceType:      'smart-meter',
    firmwareVersion: '2.1.4',
    location:        'grid-zone-7',
  }
})

// Store meta.certId — needed for revocation

The certificate is signed by your CA with ML-DSA-65. Any backend in your infrastructure can verify it offline against the CA root — no network call required.

Step 3 — The device signs each transmission

When the device sends a reading, it signs the payload. Each signature is cryptographic proof that this specific value was transmitted by this specific device at this specific time:

// On the device, at transmission time
const { token } = await fipsign.sign({
  sub:          'device-serial-00123',
  reading:      { value: 47.3, unit: 'kWh' },
  timestamp:    Date.now(),
  firmwareHash: '8f4a...',
})

// token travels with the transmission

This is where the two mechanisms work together. The certificate establishes that device-serial-00123 belongs to your fleet. The signed token establishes that this 47.3 kWh reading came from that device unaltered. If there is ever a billing dispute or a regulatory audit, you can produce both: proof of device identity and proof of data integrity, cryptographically bound, resistant to tampering even with quantum hardware.

Step 4 — Your backend verifies the transmission

// Data ingestion pipeline
const { valid, payload } = await fipsign.verify(token)

if (!valid) {
  // Reject — signature failed or token was tampered
  return
}

// payload.sub is the device ID
// payload contains the original reading, unmodified

Step 5 — Revoke when needed

A device is stolen, decommissioned, or shows anomalous behavior:

await fipsign.ca.revokeCert(meta.certId, 'device-reported-stolen')

From this point the device's certificate is invalid. Its identity is revoked across your entire fleet. Any future verification against that certificate returns revoked status immediately.

Note that if you only need data integrity without fleet identity — simpler deployments, internal systems, early-stage integrations — sign() and verify() alone are sufficient. The CA is the layer you add when you need a verifiable chain of custody from device identity down to individual data points.

The CA feature and X.509 compatibility

FIPSign's private CA supports two certificate formats:

PQCert — a JSON certificate format native to FIPSign. Compact, easy to parse, embeds arbitrary metadata fields. Good for systems you control end-to-end.

X.509 — standard DER/PEM format with ML-DSA-65 as the signature algorithm. Compatible with existing PKI tooling that can handle the algorithm. Good for systems that need to interoperate with broader infrastructure.

Both formats use ML-DSA-65. The choice depends on whether you need X.509 interoperability or prefer the simplicity of JSON.

The lifecycle question

The hardest part of post-quantum IoT is not the cryptography — it's the lifecycle math.

A certificate issued today with a 5-year expiry will still be in use in 2031. The devices holding that certificate may still be in the field in 2040. The data those devices signed in 2026 may be relevant in an audit in 2035.

Every one of those dates falls inside the window where classical cryptography becomes a liability. ML-DSA-65 certificates issued today are designed to remain trustworthy across that window.

The migration cost of getting this right now is an afternoon of integration work. The migration cost of getting it wrong later is measured in device fleets, field operations, and regulatory timelines.

Getting started

FIPSign has a free tier — 10,000 tokens per month, no credit card. The private CA is available on all plans. The JS/TS and Python SDKs are on npm and PyPI. There's also an MCP server if you want to prototype the integration directly from Claude.

Start at fipsign.dev. The guide walks through the CA setup and the first certificate issuance end-to-end.

The devices you deploy this year will still be running your certificates in a decade. Make sure those certificates are still trustworthy when they get there.

Your AI agent's audit trail is not evidence. Here's what makes it one.

German — Sun, 07 Jun 2026 17:56:49 +0000

This post builds on a conversation that started in Ian Johnson's harness stack thread and the research being published by @zep1997 in the Self-Correcting Systems series. The problem is real and I've been building in this space.

CLAIM-24 tested whether an agent checks a grant against current source conditions, not just the clock.

CLAIM-25 tested whether a signed response is both authentic and fresh — signed-AND-fresh, not just signed.

CLAIM-26 tests what happens after the action is taken: can an auditor reconstruct exactly what authority justified it?

The finding: a log that says ALLOW is not evidence. An authority event written after the action, even with matching hashes, is reconstruction — not prior authorization. The gap between a SeparateWriteGate (5/7) and a PairedAuthorityActionGate (7/7) is two failure modes that look clean but aren't: post_hoc and audit_gap.

That's the structural boundary. But there's a layer below it that the CLAIM-26 findings leave open:

What makes the authority event itself tamper-proof? is_immutable: true in a JSON field is self-assertion.

The missing piece: cryptographic weight

The minimum audit-safe shape from CLAIM-26 looks like this:

{
  "authority_event_id": "auth-001",
  "grant_id": "grant-abc",
  "decision": "ALLOW",
  "snapshot_hash": "sha256:policy_v21_sequence_42",
  "source_sequence": 42,
  "is_immutable": true,
  "written_at": "2026-06-06T12:00:01Z"
}

The is_immutable: true field tells you nothing. Any system can write that field. Any system can modify the record and rewrite it. The audit trail is internally consistent — and externally unverifiable.

What closes this: a cryptographic signature over the authority event, issued by an external authority the agent cannot write to.

Not just any signature. For audit trails that need to survive regulatory scrutiny years from now — or more concretely, the harvest-now-decrypt-later threat where adversaries are recording signed traffic today — ECDSA and RSA signatures have a known expiry date. Shor's algorithm breaks both. The NIST finalized the replacements in August 2024: ML-DSA-65, NIST FIPS 204.

What this looks like in practice

The conversation in Ian's thread landed on a three-layer architecture:

L1: Memory carries authority metadata — governs.action_types, verification_required, resource_sensitivity. This is the schema zep1997 is building: structured claims about what a memory is authorized to govern.
L2: Actions are signed against a certificate. Each agent action produces a signed token — sub: "agent_id", scoped to the specific operation, short TTL, revocable.
L3: A CA issues certificates per agent, fleet-wide. Not just a token for the action, but a certificate that encodes what action classes this agent is authorized to perform.

The certificate doesn't replace the L1 schema. It becomes the issuing authority for it. governs.action_types: ["execute", "write"] is a claim. The certificate makes that claim verifiable and gives it a revocation path.

Here's what that looks like with actual code:

import { PQAuth, generateKeyPair } from 'fipsign-sdk'

const fipsign = new PQAuth('pqa_your_api_key')

// At agent provisioning time: issue a certificate that encodes
// what action classes this agent is authorized to perform
const { publicKey, secretKey } = await generateKeyPair()

const { certificate, meta } = await fipsign.ca.issue({
  subject:          'agent_summarizer_v2',
  publicKey,
  expiresInSeconds: 30 * 24 * 60 * 60, // 30 days
  meta: {
    action_types:         ['read', 'summarize'],
    resource_sensitivity: 'low',
    verification_required: false,
  },
})

// Store certificate and secretKey on the agent
// meta.certId is what you use for revocation
console.log(meta.certId) // cert_...

At runtime, when the agent takes an action, it signs the action event:

// Agent signs the authority event before taking the action
const { token } = await fipsign.sign({
  sub:              'agent_summarizer_v2',
  action:           'document:summarize',
  authority_cert:   meta.certId,
  snapshot_hash:    'sha256:policy_v21_sequence_42',
  source_sequence:  42,
  grant_id:         'grant-abc',
  expiresInSeconds: 300, // short TTL — this is evidence of this specific action
})

// token is the authority_event with a quantum-resistant signature
// Store it alongside the action record — this is what CLAIM-26 calls for

The authority event is now:

{
  "authority_event_id": "auth-001",
  "grant_id": "grant-abc",
  "decision": "ALLOW",
  "snapshot_hash": "sha256:policy_v21_sequence_42",
  "source_sequence": 42,
  "token": {
    "payload": "eyJzdWIiOiJhZ2...",
    "signature": "oi5UKsTn...",
    "algorithm": "ML-DSA-65",
    "issuedAt": 1749254401
  }
}

is_immutable: true is gone. The signature is the immutability guarantee. Any modification to the payload — snapshot_hash, source_sequence, grant_id — invalidates the signature. An auditor verifying this event doesn't need to trust the storage system. They verify the signature against the public key, which they can fetch independently.

The revocation piece

CLAIM-26 notes that write order matters: authority written before or atomically with the action, not after.

The signing model gives you something stronger: the token has a issuedAt timestamp that's part of the signed payload. You cannot backdate a signature. If the authority event was signed at 12:00:01 and the action record shows 12:00:02, you have cryptographic proof of the ordering — not just a timestamp field that any process could have written.

But what if the agent is compromised mid-session? zep1997 and I worked through the lazy/eager revocation split in the thread:

Lazy revocation — the certificate remains valid but the gate checks it against the CRL before authorizing each action. If the certificate has been revoked, the action is blocked. No out-of-band channel needed — the next gate check catches it.

// Before any action: check the CRL
const { crl } = await fipsign.ca.getCrl()

if (fipsign.ca.isCertRevoked(meta.certId, crl)) {
  throw new Error('Agent certificate has been revoked — action blocked')
}

// Then sign the action
const { token } = await fipsign.sign({
  sub:    'agent_summarizer_v2',
  action: 'document:summarize',
  // ...
})

Eager revocation — required when the agent has long sessions and the revoked scope covers high-sensitivity action classes. The window between "certificate revoked" and "next gate check" is too large to accept. In this case, the agent controller needs to be notified out-of-band and flush the agent context immediately. This requires a separate notification mechanism in your own infrastructure — a message queue, an internal event bus, or a polling loop against ca.getCert() for real-time status.

// Real-time status check for a specific certificate (free, no token cost)
const { status } = await fipsign.ca.getCert(meta.certId)

if (status.revoked) {
  // Flush agent context immediately — eager path
  flushAgentContext(agentId)
}

Lazy is sufficient for most cases. Eager becomes necessary when session length and action sensitivity combine to create a window too large to accept.

The governs field maps to certificate scope

The insight from the thread: governs.action_types in the memory schema is exactly the field a certificate would sign over. The certificate doesn't replace that schema — it verifies it.

A memory that self-asserts action_types: ["execute", "write"] without external verification is what CLAIM-22 flagged: 3/3 false-certainty errors on mislabeled scenarios. The metadata is the authority and the assertion simultaneously.

Certificate-scoped retrieval changes the architecture: before ranking by relevance, the retriever filters by certificate scope. The question becomes not "which memory is most relevant to this query" but "which memories are authorized for this action class, and of those, which is most relevant." Relevance becomes a tiebreaker within an authorized set.

The missing verification layer — what moves from self-asserted to externally verifiable — is the certificate. And for that certificate to mean anything a decade from now, the signing algorithm needs to be post-quantum.

What this is and isn't

This is not a production trust model. It's the layer that closes the gap between "the log says ALLOW" and "the log proves it was authorized before it happened, by an agent that was authorized to perform that action class, with a signature that cannot be forged."

The open questions from CLAIM-26 remain open at this layer too:

What storage substrate holds the high-water mark for replay protection?
What canonicalization scheme covers the full authority event?
How does multi-source authority work when the action depends on multiple policy registries?

Those are next layers. The claim here is narrower: is_immutable: true is self-description. A quantum-resistant signature over the authority event is evidence.

The CA and signing API used in this post is FIPSign — ML-DSA-65, NIST FIPS 204, free tier. The JS/TS SDK (fipsign-sdk on npm) and Python SDK (fipsign-sdk on PyPI) implement the full lifecycle shown above. If you're building in this space and want to run the packet against a real external source — which is what CLAIM-24 was waiting on — drop a note here or open an issue on the Keystone repo.

Your AI agents are authorized by vibes. Here's how to fix that.

German — Tue, 02 Jun 2026 18:58:26 +0000

The AI agent security community has been converging on a problem. A researcher recently ran an experiment — feeding a memory-retrieval framework 10 scenarios involving certificate operations: signing, issuing, revoking, delegating. The system retrieved the right memory 8 out of 10 times. It matched the external authorization gate 7 out of 10.

The conclusion: metadata per item isn't enough. You need a separate authorization gate over the proposed operation.

That conclusion is correct. But I want to show what that gate actually looks like when you build it — because the primitive already exists, and it's older than LLMs.

The problem is authorization, not retrieval

Most agent frameworks today invest in memory and observability. The agent can recall what it did before. You can see what tools it called. Logs, traces, dashboards.

What they don't have is a cryptographically enforced answer to the question: was this agent authorized to do this, before it did it?

Those are different problems. Retrieval tells you what the agent remembers about its permissions. Authorization tells you what it was actually granted — signed, tamper-proof, at dispatch time.

An agent that retrieves "I have revocation permissions" from memory and then revokes a certificate it shouldn't touch is not an authorization failure at the retrieval layer. It's an authorization failure at the gate layer — because there was no gate.

Certificates are that gate

A certificate is a signed declaration of what an entity is authorized to do. Issued once, verifiable offline in ~1ms, revocable instantly. We've used them for TLS, for IoT devices, for code signing. The same primitive works for agents.

The model is simple:

Orchestrator issues a certificate at dispatch time
The certificate carries the agent's identity and its exact scope in meta
Every tool call goes through a gate that verifies the certificate offline
On completion — or abort, or timeout — the orchestrator revokes it

// Orchestrator — dispatch
const { certificate, meta } = await pq.ca.issue({
  subject:          `agent_payment_processor_run_${runId}`,
  publicKey:        agentPublicKey,
  expiresInSeconds: 3600,
  meta: {
    action_types:         ["execute", "write"],
    resource_scope:       "payments:process",
    resource_sensitivity: "high",
    verification_required: false,
    max_amount_usd:       1000,
    environment:          "production",
  },
})

The certificate is signed with ML-DSA-65. Any attempt to modify meta after issuance invalidates the signature. The agent cannot promote its own scope.

The gate — offline, zero tokens, ~1ms

function verifyAgentScope(certificate, requiredScope) {
  // Signature + expiry — offline, no API call
  const { valid, error, cert } = pq.ca.verifyCert(certificate, rootCert)
  if (!valid) throw new Error(`Gate: ${error}`)

  const meta = cert.meta ?? {}

  // Action type check
  if (!meta.action_types?.includes(requiredScope.action)) {
    throw new Error(
      `Gate: action "${requiredScope.action}" not in scope [${meta.action_types}]`
    )
  }

  // Sensitivity ceiling
  const LEVELS = { low: 0, medium: 1, high: 2, critical: 3 }
  if (LEVELS[requiredScope.sensitivity] > LEVELS[meta.resource_sensitivity]) {
    throw new Error(`Gate: sensitivity ceiling exceeded`)
  }

  return meta
}

Every tool call, before execution:

async function processPendingPayments(certificate) {
  verifyAgentScope(certificate, {
    action:      "execute",
    sensitivity: "high",
  })

  // Gate passed — proceed
  return await paymentService.processNext()
}

If the certificate doesn't authorize this action, the gate throws before any external call is made. Not after. Not in the logs.

Revocation closes the window

Short-lived certificates handle the happy path. Eager revocation handles everything else.

async function runAgent(task, scope) {
  const { certificate, certId } = await dispatchAgent(task, scope)

  try {
    return await agent.run(task, certificate)
  } finally {
    // Always — success, exception, or timeout
    await pq.ca.revokeCert(certId, "run complete").catch(() => {})
  }
}

The finally block is not optional. If the agent is compromised mid-run, the orchestrator can call revokeCert() immediately — the next gate check on the compromised agent fails instantly.

This is what the memory-retrieval approach can't do. You can't retroactively un-retrieve a memory. You can revoke a certificate.

What this solves from the packet experiment

Going back to the experiment that opened this post — the 4 cases that didn't match the external gate:

Excessive delegation — a delegate_depth field in meta, decremented on each sub-agent issue. When it reaches 0, the gate blocks delegation. The agent cannot grant itself deeper delegation than it was given.

Issue without verification — verification_required: true in meta. The gate blocks execution until a human approves. The approval request carries the certificate ID, the scope, and the expiry — everything needed to make an informed decision.

Ambiguous batch — the gate runs once per operation, not once per batch. Each item in the batch hits the same gate. No ambiguity about whether the scope covers "some items" or "all items."

Revocation by project — resource_scope: "certs:own" vs "certs:*". The gate checks the scope string. An agent with certs:own cannot revoke a certificate it didn't issue, regardless of what it retrieves from memory.

In every case, the fix is the same: enforce at the gate, not at the retrieval layer.

The post-quantum angle

The signing infrastructure matters here. If you build this on RSA or ECDSA, you're building on algorithms that quantum computers will break. NIST finalized ML-DSA-65 (FIPS 204) in August 2024 — the certificate signatures in the examples above use that standard.

Building the authorization layer now means building it on algorithms that hold when the threat materializes. The migration cost later is significantly higher than doing it right today.

FIPSign is the API I built for this — post-quantum certificates, signing, and revocation as a service. The Private CA feature is what powers the agent authorization model above. JS/TS and Python SDKs available. The gate itself costs zero tokens — only issuance and revocation are charged.

The authorization gap in agent systems is a solvable problem with existing primitives. If you're working on agent security and want to discuss the architecture — especially the delegation chain problem — drop a comment.

The Missing Layer in AI Agent Security: Auditability Is Not Observability

German — Tue, 02 Jun 2026 12:47:06 +0000

The other day someone proposed a taxonomy for AI agent configuration — five layers, from the model itself to fleet orchestration. It was the cleanest framing I'd seen of how agents are structured. But something was missing from every layer.

Nobody had named it yet.

Observability tells you what happened. Auditability tells you it's true.

Most agent frameworks today have observability. You can see what the agent did, what tools it called, what outputs it produced. Logs, traces, dashboards.

What they don't have is auditability — a cryptographic guarantee that the record is authentic and was not altered after the fact.

These are not the same thing. And the difference matters more than most teams realize.

The scenario that makes it concrete

Imagine an agent that handles financial operations. It reads account data, evaluates conditions, and approves or rejects transfers automatically.

Your observability stack tells you the agent approved a $47,000 transfer at 3:42 AM. The log is right there.

But can you prove it?

Can you prove that log wasn't written after the fact? Can you prove the agent that approved it was the agent you deployed — and not a compromised version running with altered instructions? Can you prove the action wasn't injected by a malicious prompt that slipped through your guardrails?

Observability says "this happened." Auditability says "this happened, here is the cryptographic proof, and it cannot be disputed."

In financial systems, healthcare, legal workflows, or anywhere agent outputs have real consequences — the difference between those two statements is the difference between a log and evidence.

Why this gap exists

Agent frameworks are built around capability and reliability. Can the agent do the task? Does it do it consistently? Those are the questions that dominate the design space right now.

Security is treated as a layer you add on top. And auditability — the ability to prove what happened — isn't even in the conversation yet.

Researchers working on agent memory authorization are running into the same root problem from a different angle. Their question is whether the memory the agent retrieved was authorized to govern the action it took. My question is whether the action the agent took can be proven authentic after the fact. Both gaps share the same absence: no authority chain attached to the action.

The agent acted. But nothing signed for it.

What auditability actually looks like

The model is straightforward. Every agent action produces a signed token:

const { token } = await pq.sign({
  sub:       "agent_payment_processor",
  action:    "approve_transfer",
  amount:    47000,
  accountId: "acct_8821",
  expiresInSeconds: 300
})

The token is cryptographic proof that this specific agent performed this specific action at this specific time. If the token verifies, the action is authentic. If it doesn't verify, something was tampered with or the agent was compromised.

Revocation is the other half. If the agent is compromised, you revoke its credentials instantly — not wait for tokens to expire. Every subsequent verify call rejects immediately.

This gives you two things observability cannot:

Tamper-evident records — the action log cannot be altered after the fact without breaking the signatures.

Instant credential revocation — when something looks wrong, you pull the agent's credentials and it stops being trusted immediately, not in five minutes when the token expires.

The post-quantum angle

The signing infrastructure matters. If you build agent auditability on RSA or ECDSA today, you're building on algorithms that quantum computers will break within this decade. NIST finalized post-quantum standards in August 2024 — ML-DSA-65 (FIPS 204) is the signing standard.

Building auditability now means building it on algorithms that will still hold when the threat materializes. The migration cost later is much higher than doing it right today.

FIPSign is the API I built for exactly this — post-quantum signing, verification, and revocation as a service. An agent is just another sub. No changes to your existing architecture. The auditability layer sits on top of whatever you're already running. JS/TS and Python SDKs available.

The question worth asking

Most teams deploying agents in production today can answer "what did the agent do?"

Fewer can answer "can you prove it?"

If your agents are making decisions with real consequences — financial, legal, medical, operational — that second question is coming. The teams that answer it now will have the compliance story when the audit arrives. The teams that don't will be rebuilding their auditability layer under pressure.

The infrastructure exists today. The threat model is real. The migration is cheap now and expensive later.

If you're thinking about agent auditability in your stack, I'd genuinely like to hear how you're approaching it. Drop a comment — especially if you've run into the detection latency problem that makes revocation timing tricky.

Why token revocation matters — and why JWT can't do it

German — Sat, 30 May 2026 13:50:13 +0000

JWT has a design problem that most developers don't think about until it bites them.

Once you issue a JWT, you can't take it back.

The token is valid until it expires. There's no built-in mechanism to say "this token is no longer valid, reject it." The signature is cryptographically correct, the expiry hasn't passed — and yet you need it to stop working right now.

This isn't a bug. It's a deliberate tradeoff in JWT's stateless design. But it's a tradeoff with real consequences.

The scenarios where this actually hurts

User logs out. The client discards the token, but the token is still cryptographically valid. If someone intercepted it — through a compromised device, a browser extension, a network log — they can still use it until it expires. You have no way to stop them.

Order cancelled. You signed a payment intent with a 5-minute expiry. The user cancels before paying, but the token is still valid for the next 4 minutes and 50 seconds. Anyone holding that token can still attempt to complete the transaction.

Employee offboarded. You revoke their account in your database, but they still have a valid JWT in their API client. Depending on your expiry policy, they might have hours or days of continued access.

Account compromised. You detect suspicious activity and want to lock down the account immediately. You can update a flag in your database, but if you're doing stateless JWT verification, you're not hitting the database on every request — that's the whole point of stateless tokens.

The workarounds developers use (and their problems)

Short-lived tokens with refresh tokens. Set expiry to 15 minutes. Issue a refresh token to get a new access token. This limits the blast radius — a stolen token is only valid for 15 minutes. But it doesn't solve the problem, it just shrinks the window. And it adds complexity: you now have two token types, a refresh endpoint, rotation logic, and a client that needs to handle token refresh transparently.

Token blacklist in Redis or a database. On every verify, check if the token's JTI (JWT ID) is in a blocklist. This works, but you've now reintroduced the stateful system you were trying to avoid. Every verify call hits Redis. You need to manage Redis availability, replication, and eviction policies. You've essentially built your own revocation system on top of a stateless protocol.

Very short expiry without refresh. Set expiry to 60 seconds. Forces frequent re-authentication. Users hate it. The UX is terrible. Only viable for specific use cases like single-use links.

None of these are wrong — they're widely used in production. But they're all workarounds for a missing primitive.

What proper revocation looks like

Revocation should be:

Immediate — once revoked, the token is rejected on the next verify call, not eventually
Cryptographically tied — the revocation entry must be tied to the specific token, not just the user or a JTI that can be forged
Automatic cleanup — revocation entries should expire when the original token would have expired, with no manual cleanup needed
Idempotent — revoking a token twice should return success without double-charging or erroring
Rejection of expired tokens — a token that's already expired shouldn't be revokable — that would be revoking something that's already invalid

How FIPSign handles revocation

FIPSign is built on ML-DSA-65 (NIST FIPS 204) — the post-quantum digital signature standard. The token structure includes a payload (base64 JSON), a signature (ML-DSA-65 over the payload), and metadata.

When you revoke a token, the server:

Verifies the ML-DSA-65 signature — confirms the token is genuine and hasn't expired
Computes SHA-256 of the full signature and stores it in a revocation table
Returns the revocation timestamp, the token's sub, and the original expiry

const result = await pq.revoke(token, 'user logged out')
// result.success   → true
// result.revokedAt → Unix timestamp
// result.sub       → "user_123"
// result.expiresAt → original token expiry

On every subsequent verify() call, the server checks the revocation table before returning a result:

const { valid, error } = await pq.verify(token)
// valid: false
// error: "Token has been revoked"

A few properties worth noting:

Cryptographically bound. The revocation entry is keyed on a SHA-256 hash of the ML-DSA-65 signature — not a JTI that could be replicated, not the user ID. Two tokens for the same user with the same payload will have different signatures and different revocation entries.

Automatic expiry. Revocation entries are stored with a TTL equal to the remaining lifetime of the original token. When the token would have expired anyway, the revocation entry is cleaned up. No manual maintenance.

Idempotent. Revoking an already-revoked token returns { success: true, message: "Token was already revoked" } without consuming an extra token or throwing an error.

Expired tokens can't be revoked. If a token has already expired, revoke() returns a 400 error. There's no point in revoking something that's already invalid — and accepting expired tokens for revocation would open a vector for abuse.

The cost model

Signing costs 1 token. Verifying costs 1 token. Revoking costs 1 token. There's no separate revocation infrastructure to run — it's the same API.

With 10,000 free tokens per month, a typical session lifecycle — sign on login, verify on each protected request, revoke on logout — is well within the free tier for most applications.

Revocation isn't optional

The pattern of "issue a JWT, let it expire naturally" works in many cases. But any application that handles sessions, financial operations, access control, or sensitive data needs a way to say "this token is no longer valid" — and mean it immediately.

JWT's stateless design makes that genuinely hard. Every workaround has tradeoffs.

Revocation built into the signing primitive — tied to the cryptographic signature itself, with automatic cleanup and no separate infrastructure — is a better model.

That's what we built into FIPSign from day one, not as an add-on, but as a first-class operation alongside sign and verify.

If you want to try it: fipsign.dev — 10,000 free tokens per month, no credit card. SDK for JS/TS and Python, REST API for everything else.

How to secure AI agents with post-quantum signatures

German — Wed, 27 May 2026 12:45:49 +0000

Everyone is building AI agents. Most are not thinking about how to secure them.

An agent that sends emails, executes trades, controls infrastructure, or manages files is not just a chatbot. It's a system that takes real actions with real consequences. And when something goes wrong — a compromised agent, a replayed action, a forged instruction — the question isn't just "what happened?" It's "can you prove it, and can you stop it?"

This post covers three practical problems in agent security and how to solve them with ML-DSA-65 (NIST FIPS 204) signatures.

The problem with agent actions

When an agent executes an action, you need to answer three questions:

Was this action actually authorized? Not just "did the agent do it" but "was the agent authorized to do it at this specific moment?"
Can you invalidate it? If the agent is compromised mid-session, can you stop future actions without waiting for a token to expire?
How do you verify identity at scale? When you have dozens of agents communicating with each other, how does Agent B know it's actually talking to Agent A and not an impersonator?

JWT with RS256 answers none of these well. It has no revocation. Its signatures are vulnerable to Shor's algorithm. And there's no concept of agent identity — a token proves a session, not an entity.

Part 1 — Sign every action

The simplest and most useful pattern: every action an agent takes gets a signed token before execution.

import { PQAuth } from 'fipsign-sdk'

const pq = new PQAuth(process.env.FIPSIGN_API_KEY)

// Agent is about to send an email
const { token } = await pq.sign({
  sub:              'agent_email_sender',
  action:           'send_email',
  to:               'user@example.com',
  subject:          'Your weekly report',
  authorizedBy:     'workflow_xyz',
  expiresInSeconds: 300,  // this action is valid for 5 minutes
})

// Execute the action — pass the token along
await emailService.send({ token, ...emailData })

// On the receiving side — verify before executing
const { valid, payload } = await pq.verify(token)
if (!valid) throw new Error('Unauthorized agent action')

console.log(payload.sub)        // 'agent_email_sender'
console.log(payload.action)     // 'send_email'
console.log(payload.authorizedBy) // 'workflow_xyz'

Same pattern in Python:

from fipsign import PQAuth

pq = PQAuth(os.environ["FIPSIGN_API_KEY"])

result = pq.sign(
    "agent_email_sender",
    action="send_email",
    to="user@example.com",
    authorized_by="workflow_xyz",
    expires_in_seconds=300,
)
token = result.token

# Verify before executing
result = pq.verify(token)
if not result.valid:
    raise PermissionError("Unauthorized agent action")

What you gain: every action has a cryptographic proof of authorization. The signature is ML-DSA-65 — no known quantum attack. The payload is tamper-proof. If someone intercepts and modifies action: "delete_files" from action: "send_email", verification fails.

Part 2 — Revoke immediately when an agent is compromised

This is where JWT breaks down completely.

With JWT, if an agent is compromised, you can't invalidate its tokens. You wait for expiry. For a token with a 1-hour TTL, that's up to 60 minutes of a compromised agent still passing authentication.

With FIPSign, revocation is immediate and permanent:

// Agent_X is compromised at 14:32
// Revoke its active token immediately
await pq.revoke(agentToken, 'agent compromised — security incident')

// Any subsequent verify() call returns valid: false
const { valid, error } = await pq.verify(agentToken)
console.log(valid)  // false
console.log(error)  // 'Token has been revoked'

The revocation is backed by a blacklist in Cloudflare D1. Every remote verify() call checks it before returning a result. There's no TTL to wait out.

The failure mode @valentin_monteiro mentioned — agents failing in production — almost always involves a window of time where a compromised agent keeps operating because nothing invalidated its credentials. Revocation closes that window to zero.

Part 2.5 — Closing the detection gap

Revocation is immediate — but only from the moment you call pq.revoke(). The real problem is the window between when an agent is compromised and when someone detects it and triggers the revoke. That gap can be minutes, hours, or days depending on your setup.

Three mechanisms to close it:

1. Short TTL as a damage ceiling

TTL isn't a substitute for revocation — it's a limit on how much damage can happen if detection is slow. A compromised agent signing actions with a 5-minute TTL has at most 5 minutes of undetected exposure per token. Keep high-risk actions under 5 minutes. Keep low-risk actions under 60 minutes. Never use TTLs over a few hours for agent tokens.

This is already in the checklist above — but the reasoning matters: short TTL is your last line of defense when everything else fails.

2. Wire `token.rejected` to automatic revocation

FIPSign emits a token.rejected webhook every time a verification fails. A compromised agent that starts replaying tokens, sending malformed payloads, or operating outside its expected scope will generate rejections. You can wire that signal directly to an auto-revoke:

// Your webhook handler
app.post('/fipsign-webhook', verifyWebhookSignature, async (req) => {
  const { event, data } = req.body

  if (event === 'token.rejected') {
    const { reason, projectId } = data

    // A project generating repeated rejections is a signal worth acting on
    if (activeTokensByProject[projectId]) {
      await pq.revoke(activeTokensByProject[projectId], 'auto-revoked: anomaly detected')
      await alertSecurityTeam({ projectId, reason })
    }
  }
})

This closes the detection gap to seconds — no human in the loop required. FIPSign provides the signal. Your system decides what to do with it.

3. Use `limit.warning` as an indirect signal

A compromised agent that starts spamming actions will consume tokens faster than expected. FIPSign emits a limit.warning webhook when usage reaches 80% of your monthly limit. It's not a security signal by design — but if you're nowhere near your normal consumption and limit.warning fires unexpectedly, something is wrong.

if (event === 'limit.warning') {
  // Unexpected spike — investigate
  await alertSecurityTeam({
    message: 'Unusual token consumption spike',
    freeRemaining: data.freeRemaining,
    month: data.month,
  })
}

Not a substitute for proper anomaly detection — but it's a signal you already have for free.

The model: FIPSign provides the cryptographic primitives and the signals. Your system provides the context and the response logic. Neither layer can do the other's job — and they shouldn't try.

Part 3 — Agent identity with Private CA

For simple agents, signed action tokens are enough. But when you have persistent agents — a fleet of IoT devices, a set of microservices, a group of agents that communicate with each other — you need something more durable than a session token.

That's where a Private CA comes in.

The model: each agent gets an ML-DSA-65 certificate issued by your project's CA. The certificate contains the agent's public key, its identity, and its expiry. It's signed by the CA's private key — which never leaves the server.

import { PQAuth, generateKeyPair } from 'fipsign-sdk'

const pq = new PQAuth(process.env.FIPSIGN_API_KEY)

// At agent provisioning time: generate a key pair for the agent
const { publicKey, secretKey } = await generateKeyPair()
// secretKey stays on the agent — never transmitted

// Issue a certificate for this agent
const { certificate } = await pq.ca.issue({
  subject:          'agent-data-processor-001',
  publicKey,
  expiresInSeconds: 30 * 24 * 60 * 60,  // 30 days
  meta: {
    role:    'data_processor',
    team:    'analytics',
    version: '2.1.0',
  },
})

// Store certificate on the agent
// certificate.id, certificate.publicKey, certificate.signature, certificate.expiresAt

Now when Agent B receives a message from Agent A, it can verify Agent A's identity offline:

import rootCert from './root-cert.json' assert { type: 'json' }

// No API call — purely local ML-DSA-65 verification
const result = pq.ca.verifyCert(agentACertificate, rootCert)

if (!result.valid) {
  console.error(result.error)  // 'Invalid certificate signature', 'CERT_EXPIRED', etc.
  return reject('Agent not authorized')
}

console.log(result.cert.subject)   // 'agent-data-processor-001'
console.log(result.cert.expiresAt) // Unix timestamp

And if Agent A is decommissioned or compromised:

// Revoke the certificate immediately
await pq.ca.revokeCert(certificate.id, 'agent decommissioned')

// Check revocation before trusting
const { crl } = await pq.ca.getCrl()
if (pq.ca.isCertRevoked(agentACertificate, crl)) {
  return reject('Agent certificate revoked')
}

The full security model for agents

Putting it together:

Concern	Solution
Was this action authorized?	Sign every action with `/sign`
Can I stop a compromised agent?	Revoke with `/revoke` — immediate, permanent
How do agents identify themselves?	Private CA — one certificate per agent
How do agents verify each other?	`verifyCert()` offline — no API call needed
Is the agent's identity still valid?	Check CRL with `getCrl()` + `isCertRevoked()`
Are signatures quantum-resistant?	ML-DSA-65 — NIST FIPS 204

Security checklist for agents

Before deploying an agent that takes real actions:

[ ] Every action produces a signed token before execution
[ ] Token expiry is short — 5 minutes maximum for high-risk actions
[ ] Revocation is wired in — if the agent is compromised, you can stop it in seconds
[ ] Persistent agents have certificates, not just session tokens
[ ] Agents verify each other's certificates before trusting inter-agent messages
[ ] CRL is checked periodically — don't rely on certificate expiry alone
[ ] Signatures use ML-DSA-65 — not RS256, not ES256

Why post-quantum matters for agents specifically

Most of the "harvest now, decrypt later" discussion focuses on data encryption. But signatures are equally at risk.

An attacker recording your agents' signed actions today can — once quantum computers are available — forge signatures for actions that never happened. That means fabricated audit trails, forged authorizations, and retroactive tampering with your agent's history.

ML-DSA-65 has no known quantum attack. Migrating now, while your agent system is being built, costs one install command. Migrating later, after you've deployed thousands of agents with RS256-signed credentials, costs months.

Get started

npm install fipsign-sdk
# or
pip install fipsign-sdk

Free tier: 10,000 tokens/month, no credit card. Private CA included — create one from the dashboard in seconds.

fipsign.dev · Developer guide

If you're building agents and hitting security questions I didn't cover — drop them in the comments. Happy to go deeper on specific failure modes.

How to migrate from JWT to post-quantum tokens without breaking your API

German — Tue, 26 May 2026 11:22:45 +0000

You've read about ML-DSA-65. You understand why RS256 and ES256 are on borrowed time. Now the question is practical: how do you actually migrate a production API without taking everything down or breaking clients that already have tokens in the wild?

This is a step-by-step guide. By the end you'll have a working migration — login, logout, protected routes, and a transition strategy that lets old JWT tokens and new post-quantum tokens coexist during the rollout.

What we're starting from

A typical Express API with JWT looks like this:

import jwt from 'jsonwebtoken'
import express from 'express'

const app = express()
app.use(express.json())

// Login — sign a JWT
app.post('/login', async (req, res) => {
  const user = await db.users.findByEmail(req.body.email)
  if (!user || !checkPassword(req.body.password, user.passwordHash)) {
    return res.status(401).json({ error: 'Invalid credentials' })
  }

  const token = jwt.sign(
    { sub: user.id, email: user.email, role: user.role },
    process.env.JWT_SECRET,
    { algorithm: 'RS256', expiresIn: '1h' }
  )

  res.json({ token })
})

// Middleware — verify JWT on every protected route
function requireAuth(req, res, next) {
  const header = req.headers['authorization'] ?? ''
  if (!header.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Unauthorized' })
  }
  try {
    req.user = jwt.verify(header.slice(7), process.env.JWT_PUBLIC_KEY)
    next()
  } catch {
    res.status(401).json({ error: 'Invalid token' })
  }
}

app.get('/api/profile', requireAuth, (req, res) => {
  res.json({ user: req.user })
})

This works. But the signature is RS256 — vulnerable to Shor's algorithm. The migration replaces that signature scheme with ML-DSA-65, which has no known quantum attack.

The transition strategy

The hardest part of any cryptographic migration isn't the new code — it's the existing tokens in the wild. Users that logged in yesterday have a JWT in their browser or mobile app. You can't invalidate all of them at once without forcing everyone to log out.

The approach that works:

Deploy the new signing scheme — new logins get ML-DSA-65 tokens
Keep the old verification — during the transition period, verify both JWT and ML-DSA-65 tokens
Set a deprecation date — after N days (typically the max token lifetime), all old JWTs will have expired naturally
Remove the old path — once the deprecation date passes, drop JWT verification entirely

This means zero forced logouts and zero downtime. Clients migrate automatically as their old tokens expire.

Step 1 — Install the SDK

npm install fipsign-sdk

Get a free API key at app.fipsign.dev — no credit card required. Create a project, create an API key inside that project. Store it as an environment variable.

FIPSIGN_API_KEY=pqa_your_api_key

Step 2 — Replace login

The new login signs the same payload with ML-DSA-65 instead of RS256. The token object returned by sign() is a JSON object — encode it to base64 before sending it to the client so it fits cleanly in an Authorization header.

import { PQAuth } from 'fipsign-sdk'

const pq = new PQAuth(process.env.FIPSIGN_API_KEY)

app.post('/login', async (req, res) => {
  const user = await db.users.findByEmail(req.body.email)
  if (!user || !checkPassword(req.body.password, user.passwordHash)) {
    return res.status(401).json({ error: 'Invalid credentials' })
  }

  const { token } = await pq.sign({
    sub:              user.id,
    email:            user.email,
    role:             user.role,
    expiresInSeconds: 3600,
  })

  // Encode to base64 — this is what the client sends in Authorization: Bearer <token>
  // (JSON objects with special characters can break header parsing)
  const encoded = Buffer.from(JSON.stringify(token)).toString('base64')
  res.json({ token: encoded })
})

The payload structure is identical to what you had in JWT — sub, email, role. Clients don't need to change anything about how they store or send the token.

Step 3 — Add logout with revocation

This is where ML-DSA-65 tokens improve on JWT. With JWT, you can't revoke a token — once issued, it's valid until expiry. With FIPSign, revoke() immediately invalidates the token. Any future verify() call rejects it even if the signature is valid and the token hasn't expired.

app.post('/logout', async (req, res) => {
  const header = req.headers['authorization'] ?? ''
  if (header.startsWith('Bearer ')) {
    try {
      const token = JSON.parse(Buffer.from(header.slice(7), 'base64').toString('utf8'))
      await pq.revoke(token, 'user logged out')
    } catch { /* ignore malformed token */ }
  }
  res.json({ success: true })
})

Step 4 — Replace the middleware (with transition support)

During the transition period, the middleware needs to handle both token formats. The simplest way is to try ML-DSA-65 first, and fall back to JWT verification for old tokens.

import { PQAuthError } from 'fipsign-sdk'

async function requireAuth(req, res, next) {
  const header = req.headers['authorization'] ?? ''
  if (!header.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Unauthorized' })
  }

  const raw = header.slice(7)

  // Try ML-DSA-65 first
  try {
    const token = JSON.parse(Buffer.from(raw, 'base64').toString('utf8'))
    const result = await pq.verify(token)
    if (result.valid) {
      req.user = result.payload
      return next()
    }
    return res.status(401).json({ error: result.error ?? 'Invalid token' })
  } catch {
    // Not a base64 JSON token — try JWT fallback
  }

  // JWT fallback — remove this block after your deprecation date
  try {
    req.user = jwt.verify(raw, process.env.JWT_PUBLIC_KEY)
    return next()
  } catch {
    return res.status(401).json({ error: 'Invalid token' })
  }
}

app.get('/api/profile', requireAuth, (req, res) => {
  res.json({ user: req.user })
})

Once your JWT deprecation date passes and all old tokens have expired, remove the JWT fallback block. The middleware becomes purely ML-DSA-65.

Step 5 — Use the built-in middleware (optional)

If you don't need the transition period, FIPSign ships an Express middleware that handles everything automatically:

// Protect all routes under /api
app.use('/api', pq.middleware())

// req.user is the verified payload — sub, email, role, exp, iat
app.get('/api/profile', (req, res) => {
  res.json({ user: req.user })
})

The middleware reads Authorization: Bearer <base64(token)>, verifies it, and attaches the decoded payload to req.user. Returns 401 automatically on invalid tokens.

Python — FastAPI example

If you're running a Python backend, the migration looks the same. Install the SDK:

pip install fipsign-sdk

from fastapi import FastAPI, Depends
from fipsign import PQAuth, fastapi_middleware

app          = FastAPI()
pq           = PQAuth("pqa_your_api_key")
require_auth = fastapi_middleware(pq)

@app.post("/login")
async def login(body: LoginRequest):
    user = await db.find_by_email(body.email)
    if not user or not check_password(body.password, user.password_hash):
        raise HTTPException(401, "Invalid credentials")

    result  = pq.sign(user.id, email=user.email, role=user.role, expires_in_seconds=3600)
    encoded = base64.b64encode(json.dumps(result.token.__dict__).encode()).decode()
    return {"token": encoded}

@app.post("/logout")
async def logout(request: Request):
    header = request.headers.get("Authorization", "")
    if header.startswith("Bearer "):
        try:
            token = PQToken(**json.loads(base64.b64decode(header[7:]).decode()))
            pq.revoke(token, "user logged out")
        except: pass
    return {"success": True}

@app.get("/api/profile")
def profile(user=Depends(require_auth)):
    return {"user": user}

Flask works the same way with flask_middleware — the full guide covers both.

Pre-deprecation checklist

Before you remove the JWT fallback:

[ ] Confirm your max JWT lifetime has passed (e.g. if JWTs expire in 24h, wait at least 24h after switching new logins to ML-DSA-65)
[ ] Check your logs — are there still requests hitting the JWT verification path?
[ ] Verify that mobile clients have updated — old app versions might still be sending JWTs
[ ] Revoke any long-lived JWTs that were issued manually (service accounts, API clients)
[ ] Remove JWT_SECRET and JWT_PUBLIC_KEY from your environment variables
[ ] Remove the jsonwebtoken dependency

What you gained

After the migration:

Quantum-resistant signatures — ML-DSA-65, NIST FIPS 204
Revocation — instantly invalidate any token, no blacklist to build yourself
No key management — FIPSign handles key generation, storage, and rotation
Same payload structure — sub, custom fields, expiry — nothing changes for your application logic

The migration is mostly mechanical. The cryptography underneath is fundamentally different.

If you have questions about specific edge cases — long-lived tokens, service-to-service auth, mobile clients — drop them in the comments.

NIST published post-quantum standards in August 2024. Most developers haven't noticed.

German — Sun, 24 May 2026 21:13:46 +0000

In August 2024, the National Institute of Standards and Technology finalized the first post-quantum cryptography standards in history. It was the result of an eight-year selection process involving cryptographers from around the world.

Most developers missed it entirely.

That's not a criticism — it happened quietly, buried under the usual noise of framework releases and AI announcements. But the implications for the code you're shipping today are significant, and the window to act is shorter than most people think.

What NIST actually published

Three standards. The one that matters most for developers building APIs and authentication systems is FIPS 204, which specifies ML-DSA — Module Lattice-based Digital Signature Algorithm.

ML-DSA comes in three variants: ML-DSA-44, ML-DSA-65, and ML-DSA-87. The numbers roughly correspond to security levels. ML-DSA-65 is the sweet spot for most production use cases — NIST security level 3, reasonable signature size, fast enough for high-throughput APIs.

The other two standards cover key encapsulation (ML-KEM, formerly Kyber) and a hash-based signature scheme (SLH-DSA). Important, but less immediately relevant if your primary concern is signing tokens and verifying identity.

Why your current signatures are vulnerable

If you're using JWT today — and most APIs are — you're almost certainly signing with RS256 (RSA) or ES256 (ECDSA). Both of these rely on mathematical problems that are hard for classical computers to solve: integer factorization for RSA, discrete logarithm for ECDSA.

Peter Shor published an algorithm in 1994 that solves both of these problems efficiently on a quantum computer. A sufficiently powerful quantum computer running Shor's algorithm can break RS256 and ES256. Not slowly — efficiently.

The natural response is: "quantum computers aren't powerful enough yet, so why does this matter now?"

Two reasons.

Harvest now, decrypt later. Nation-state actors are already recording encrypted traffic and signed tokens today, storing them for future decryption once quantum hardware is available. If you're signing anything with a long-term security requirement — contracts, compliance records, device certificates, financial transactions — those signatures are already being collected.

Migration takes years. Updating cryptographic primitives across a production system isn't a one-afternoon job. It touches every service that signs or verifies tokens, every client that stores them, every integration that depends on the format. The teams that start now will be ready when quantum computers arrive. The teams that wait will be scrambling.

Estimates for cryptographically relevant quantum computers range from 10 to 20 years. That sounds comfortable until you factor in that large-scale migrations typically take 3 to 7 years.

What "post-quantum resistant" actually means

ML-DSA is based on the hardness of lattice problems — specifically Module Learning With Errors (Module-LWE) and Module Short Integer Solution (Module-SIS). Unlike RSA and ECDSA, no known quantum algorithm provides a significant speedup against these problems.

This doesn't mean ML-DSA is unbreakable. It means that the best known attacks — classical or quantum — require computational effort that scales in a way that makes them infeasible for any realistic adversary. That's the same bar RSA and ECDSA were held to before Shor's algorithm changed the picture.

The signatures are larger than ECDSA signatures — an ML-DSA-65 signature is around 3.3 KB compared to 64 bytes for ES256. For API tokens and document signing, this is a manageable tradeoff. For TLS handshakes at massive scale, it requires more careful consideration.

What this means for your code today

If you're building a new system, there's no good reason to start with RS256 or ES256. The post-quantum alternatives are standardized, implemented in audited libraries, and ready for production.

If you have an existing system, the migration path depends on your architecture. The core change is replacing the signing and verification step — the token format, the payload structure, and everything else can stay the same. The hard part is coordinating the rollout across services that need to verify tokens issued under the old scheme during the transition period.

The practical checklist:

Audit where you're generating signatures today (JWT issuance, document signing, webhook signatures, device authentication)
Identify which of those have long-term security requirements vs. short-lived session tokens
Prioritize migration for anything with long-term requirements
For new projects, start with ML-DSA-65

The tooling gap

Here's the honest state of things: the tooling for post-quantum signing is still catching up.

Most JWT libraries don't support ML-DSA yet. HSMs are adding support gradually — the standard only finalized in August 2024, so hardware vendors are still shipping firmware updates. Key management services from the major cloud providers are on their roadmaps but not universally available.

The clearest path for most developers right now is using an audited implementation of ML-DSA-65 directly — the @noble/post-quantum library is a well-regarded option — or using a managed signing service that handles the key management and infrastructure.

What I built

After going through this migration problem myself, I built FIPSign — a signing API that lets you sign any payload with ML-DSA-65 without managing keys, running infrastructure, or calling sales.

The API is simple: you pass a payload with a sub field identifying the entity, get back a quantum-resistant signed token. Verification checks the ML-DSA-65 signature, token expiry, and a revocation list. Revocation is built in — something JWT alone doesn't give you.

import { PQAuth } from 'fipsign-sdk'

const pq = new PQAuth('pqa_your_api_key')

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

const { valid, payload } = await pq.verify(token)

It's not the only path to ML-DSA-65 in production — but it's the fastest one I know of if you want to start signing with a post-quantum algorithm today without building key management from scratch.

10,000 free tokens per month, no credit card. SDK for JS/TS and Python, REST API for everything else. Full guide at fipsign.dev/guide.

The August 2024 publication was a quiet moment that most developers scrolled past. The cryptographic community has been working toward this for eight years. The standards are finalized, the libraries exist, and the threat — while not immediate — is real enough that waiting is a decision with consequences.

The best time to start was August 2024. The second best time is now.

Why I built a post-quantum signing API (and why JWT is on borrowed time)

German — Fri, 22 May 2026 12:36:31 +0000

JWT with RS256/ES256 is everywhere. It's also going to be broken.

Not today. But the clock is ticking — and the timeline is shorter than most developers think.

NIST published the post-quantum signature standards in August 2024. AWS KMS added ML-DSA support in June 2025. Microsoft shipped it natively to Windows 11 and .NET in November 2025. The migration window is open — and most backend developers haven't started yet.

The problem with classical signatures

Every JWT signed with RS256 or ES256 relies on RSA or ECDSA. These algorithms are vulnerable to Shor's algorithm running on a sufficiently powerful quantum computer. NIST finalized the post-quantum replacements in August 2024 — but most developers haven't started migrating yet.

The threat isn't just future decryption. Nation-state actors are already harvesting signed traffic today to decrypt and forge once quantum computers arrive. "Harvest now, decrypt later" is a real attack pattern.

What I built

I built FIPSign — a signing API built on ML-DSA-65 (NIST FIPS 204). The idea is simple: you call /sign with any payload, get back a quantum-resistant token. No infrastructure to manage, no keys to generate or rotate, no DevOps.

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

const { valid, payload } = await pq.verify(token)

Not just for auth

Most post-quantum signing tools focus only on user authentication. FIPSign lets you sign anything — the only required field is sub, any string identifying the entity:

sub: "user_123" — user sessions
sub: "order_456" — payment intents
sub: "doc_789" — document certification
sub: "device_iot_001" — IoT firmware

How revocation works

Revocation is built in. When you revoke a token, we store a SHA-256 hash of the ML-DSA-65 signature as a blacklist entry in Cloudflare D1. Every remote /verify call checks that blacklist. Entries expire automatically when the original token would have expired.

Local verification (localVerify: true) runs entirely in memory at ~1ms with no API call — but doesn't check revocation. Use remote verification for payments and admin actions.

Why ML-DSA-65 specifically?

ML-DSA-65 is NIST security level 3 — the right balance between security and signature size for API use cases. ML-DSA-44 is faster but lower security. ML-DSA-87 produces larger signatures with no practical benefit for most applications.

The implementation uses @noble/post-quantum — a widely audited library you can verify independently.

One more thing — no subscription

FIPSign doesn't have monthly plans. You get 10,000 free tokens per month automatically. If you need more, you buy a token pack — they never expire and accumulate across purchases.

One account gives you unlimited projects with unlimited API keys per project, each with its own usage stats. Useful if you're managing multiple clients, environments, or microservices from the same account — no enterprise plan required.

Try it

npm install fipsign-sdk

Full guide at fipsign.dev/guide. Free account at app.fipsign.dev — no credit card.

Happy to answer any questions about the cryptography, the architecture, or the migration path from JWT.

DEV Community: German

Your IoT Devices Will Outlive Your Cryptography

The attack you're not thinking about

What the migration looks like if you wait

What post-quantum device identity looks like in practice

A concrete integration with FIPSign

Step 1 — Generate a key pair at provisioning time

Step 2 — Issue a certificate from your CA

Step 3 — The device signs each transmission

Step 4 — Your backend verifies the transmission

Step 5 — Revoke when needed

The CA feature and X.509 compatibility

The lifecycle question

Getting started

Your AI agent's audit trail is not evidence. Here's what makes it one.

The missing piece: cryptographic weight

What this looks like in practice

The revocation piece

The governs field maps to certificate scope

What this is and isn't

Your AI agents are authorized by vibes. Here's how to fix that.

The problem is authorization, not retrieval

Certificates are that gate

The gate — offline, zero tokens, ~1ms

Revocation closes the window

What this solves from the packet experiment

The post-quantum angle

The Missing Layer in AI Agent Security: Auditability Is Not Observability

Observability tells you what happened. Auditability tells you it's true.

The scenario that makes it concrete

Why this gap exists

What auditability actually looks like

The post-quantum angle

The question worth asking

Why token revocation matters — and why JWT can't do it

The scenarios where this actually hurts

The workarounds developers use (and their problems)

What proper revocation looks like

How FIPSign handles revocation

The cost model

Revocation isn't optional

How to secure AI agents with post-quantum signatures

The problem with agent actions

Part 1 — Sign every action

Part 2 — Revoke immediately when an agent is compromised

Part 2.5 — Closing the detection gap

1. Short TTL as a damage ceiling

2. Wire token.rejected to automatic revocation

3. Use limit.warning as an indirect signal

Part 3 — Agent identity with Private CA

The full security model for agents

Security checklist for agents

Why post-quantum matters for agents specifically

Get started

How to migrate from JWT to post-quantum tokens without breaking your API

What we're starting from

The transition strategy

Step 1 — Install the SDK

Step 2 — Replace login

Step 3 — Add logout with revocation

Step 4 — Replace the middleware (with transition support)

Step 5 — Use the built-in middleware (optional)

Python — FastAPI example

Pre-deprecation checklist

What you gained

NIST published post-quantum standards in August 2024. Most developers haven't noticed.

What NIST actually published

Why your current signatures are vulnerable

What "post-quantum resistant" actually means

What this means for your code today

The tooling gap

What I built

Why I built a post-quantum signing API (and why JWT is on borrowed time)

The problem with classical signatures

What I built

Not just for auth

How revocation works

Why ML-DSA-65 specifically?

One more thing — no subscription

Try it

2. Wire `token.rejected` to automatic revocation

3. Use `limit.warning` as an indirect signal