# M2M and certificate management

### Why our processes do not depend on certificates — and how you can keep yours after quantum

**Our security concept does not rest on certificates.** For processes we use our machine-to-machine protocol, M2M. A business process binds to an M2M session — hardware identity, fresh keys per session, end-to-end encryption inside the transport, continuous attestation — never to a transport certificate. For the higher classifications one transaction-process executes exactly one transaction and then disappears. Certificates serve transport and host authentication only, as housekeeping of the administration tier: they can change at any moment without a process noticing.

**Quantum-ready M2M, five pillars.** *Tiered mesh*: every endpoint passes a five-stage pipeline of isolated uploaders; only the last touches the core data. *Dual ingress*: people enter with a hardware-bound FIDO2 WorkPermit, field devices through a separate path with keys that live about an hour. *In-memory execution*: workloads are streamed into RAM and vanish at power-off. *Ephemeral sessions*: accounts and access rights exist per session only — no shared static credential anywhere. *In-flight attestation*: the protocol keeps asking "am I still me?" and terminates on the first wrong answer. Underneath, defence in depth: outer TLS 1.3 transport plus inner end-to-end payload encryption, with key exchange on a hybrid post-quantum path.

**Your certificates after quantum — the x.y multi-CA farm.** Organisations will keep certificates for web servers, mail signing and smart cards. Our secure-workplace specification makes them short-lived, frequently swapped and cheap: *x* organisation-owned certificate authorities; every server holds *y* pre-staged valid certificates from distinct CAs, one active.

| Tier | Use | CAs (x) | Pre-staged per server (y) |
|---|---|---|---|
| 5.3 | Internal and confidential systems | 5 | 3, one active |
| 8.5 | Public-facing ingress and edge services | 8 | 5, one active |
| 12.8 | Sensitive and top-secret / critical systems | 12 | 8, one active |

The active certificate is swapped every few minutes, and a certificate lives at most 12 hours in operation — the standard caps it at 24 — so a stolen or broken one loses its active status at the next swap and expires within hours. The ratio is tuned to your risk profile.

**What it costs, what it survives.** The CAs are in-house, each with automated grant and revoke services: no per-seat or per-certificate fees, a marginal cost near zero — which is what makes frequent swapping affordable. If a CA is corrupted, an automated four-step recovery — switch to a healthy certificate, revoke the chain fleet-wide, re-provision, regenerate the CA — is designed to complete in under five minutes without service interruption. Where a regulator demands it, an external enterprise PKI or managed HSM root remains the approved fallback.

**In one line.** Certificates become disposable housekeeping; M2M carries the trust.

*Wols CA — security architecture for sensitive and top-secret assets. Quantum-ready: designed for the post-quantum era.*