Your IoT Devices Will Outlive Your Cryptography

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.