EdSSA · Public-safe whitepaper

Authentication for places authentication can't reach.

Stateless, post-quantum, decentralised machine-to-machine authentication — with evidence a third party can check — for machines that cannot stop to ask.

Version 1.3 · September 2026 · edssa.io

Public-safe document. The deeper protocol specification — bit-level credential format, oracle source curation, parameter calibration, performance benchmarks in absolute time — is shared only under mutual non-disclosure agreement. Request access at edssa.io/talk.

1. The harsh-conditions market

Every machine-to-machine authentication product on the market today was built for a specific operating envelope: services in a cloud, with reliable network reachability to a credential authority, where the per-request latency to fetch or refresh a credential is amortised against a request that will then make four database calls anyway.

That envelope contains a great deal of valuable computing. It does not, however, contain a great deal of the operationally critical computing the world increasingly depends on.

Consider: a drone fleet under jamming. A satellite between ground passes. A pharmaceutical container traversing six handlers across three continents. A wind farm 80 km offshore. A subsea unmanned vehicle on acoustic links. An industrial sensor with a twenty-five-year operational lifetime. A submarine. A pacemaker. A municipality's contractor chain handling citizen records across four sub-processors and three EU regions. An AI agent calling tools on someone's behalf, thousands of times an hour — faster than anyone can approve each call.

These are not edge cases. They are large markets — drone OEMs measured in hundreds, satellite operators in tens, defence and aerospace integrators across every developed economy, pharmaceutical logistics and cold-chain operators globally, central banks on the cusp of wholesale CBDC settlement, industrial-edge platforms across European critical infrastructure, public-sector procurement bodies and regulated enterprises under the post-2024 EU compliance stack, and every organisation now putting AI agents in front of its own systems. What unites them is that the M2M authentication products built for the cloud envelope cannot do the job in their operating environment — or, in the regulated-vertical case, cannot produce evidence the regulator will accept.

Four pressures are converging. First, the post-quantum migration mandate. NIST FIPS 203 standardised post-quantum key encapsulation in 2024. CNSA 2.0 mandates post-quantum cryptography for US national-security systems by 2030. EU regulation (NIS2, CER, the Cyber Resilience Act) is following. Devices deployed today routinely have 15-to-25-year operational lifetimes — well past any realistic horizon for a cryptographically relevant quantum computer. The cryptography a device ships with has to hold for as long as the device does.

Second, the sovereignty pressure. European critical-infrastructure operators — energy, healthcare, transport, defence, finance — increasingly require sovereignty over the cryptographic primitives their authentication systems depend on. Vendor-controlled key infrastructure in foreign jurisdictions is becoming politically and procurementally untenable.

Third, the operational reality. Drones in jamming. Satellites between ground passes. Twenty-five-year deployments. Sub-processor chains where the data controller cannot verify what each link did. None of the existing schemes survive these conditions cleanly.

Fourth, the evidence pressure. Regulators and counterparties increasingly ask for records the operator could not have rewritten: lifetime event logging for high-risk AI systems under the AI Act, the register of ICT third-party arrangements under DORA, incident evidence under NIS2, the sub-processor chain under GDPR Article 28. An application log the operator wrote about itself answers none of them well.

The EdSSA protocol addresses all four pressures with a single architecture.

2. The architecture, in one paragraph

Two parties bootstrap once via a post-quantum handshake. Both sides derive identical state in volatile memory. The bootstrap material is then discarded. From that point forward, each side authenticates the other by computing an ephemeral credential from the shared state and from public ambient inputs, and matching it against the credential the counterparty independently computes. The state advances autonomously over time through one-way functions, requiring no further communication. The verification path is branch-free, allocation-free, and fits in a single CPU cache line. After a single handshake, two computing nodes can keep authenticating each other for years — through link drops, jamming, satellite handoffs, multi-day disconnects, and adversarial conditions — without ever calling home.

That is the protocol family we call EdSSA.

3. The breathing credential — public-safe view

The core mechanism we call the breathing credential. The metaphor is deliberately reductive. The protocol is not literally a respiration cycle. It is, however, a credential that varies continuously, freshly built each request from material that both parties share in common, against a state that evolves on a schedule both parties hold independently.

At the marketing level, the shape is simple:

Bootstrap. Two parties exchange a single handshake using NIST-standardised post-quantum primitives. Both sides derive the same in-memory state from the handshake. The handshake material itself is discarded immediately.
In-memory only. No persistent secret on disk. No certificate to renew. The state lives only where it has to live: in volatile memory at each endpoint.
Ephemeral credential per request. The client builds a credential from the shared state and from public ambient inputs that both parties can observe in their environment. The server independently builds the expected credential. Match? Authenticated. Mismatch? Rejected.
Autonomous ratchet. Both sides advance their state through one-way functions on a schedule that needs no further communication. Years can pass between observations. Authentication still holds.
Resilience absorbs noise. Independent design parameters control security level and operational resilience separately. Transient ratchet ticks, oracle hiccups, schema transitions, and clock drift are absorbed transparently — without weakening the cryptographic guarantee.

The depth — bit-level credential format, oracle source curation, parameter calibration, threshold tuning, replay-defence layering — is L3 specification material, available to evaluating partners under mutual NDA.

4. Properties that fall out of the architecture

Several properties fall out of this architectural shape that are difficult or impossible to obtain from vault-based or PKI-based authentication:

Operates without central authority in the hot path. Once two nodes have shared a single handshake, neither needs to talk to a third party to authenticate the other ever again. This is not a degraded mode; it is the normal mode.

Sub-microsecond verification. The verification path is branch-free, allocation-free, and fits in a single CPU cache line. We do not publish absolute performance numbers in this document; the relative claim is that the verification budget is well below what a network round-trip to a credential authority can match.

Post-quantum from the first handshake. The bootstrap uses ML-KEM-768, the post-quantum key encapsulation NIST standardised as FIPS 203, so recording a handshake today in order to open it with a quantum computer later — the harvest-now, decrypt-later attack — is designed out from the first day. That protection rests on a standardised primitive, not on anything proprietary. After the bootstrap the protocol runs on a symmetric core. The bootstrap material is discarded, and the shared state moves only forward, through one-way functions: a device captured later cannot be made to reproduce the credentials it produced before it was captured. Post-quantum is not an upgrade we offer; it is the architecture.

Stateless across deployment lifecycles. No certificate to renew, no PKI to call back to. A device deployed today does not depend on the existence in 2045 of any authority that exists today.

Operator-independent verifiability. Every authentication event can produce an audit record in a Merkle-anchored chain, and the chain's roots are anchored into an external transparency log the operator does not control — so anyone can verify the integrity and timing of what was recorded without trusting the operator. A party that holds the evidence archive — the data owner, a regulator, a national audit institution, a downstream counterparty — checks it independently and needs nothing further from the operator; the hosted service's archives verify with nothing more than openssl and a shell. This is the property that makes the protocol load-bearing for regulated supply-chain and sub-processor scenarios, not just for harsh-conditions M2M.

Sovereign by design. The protocol is built and operated in the European Union. NIST and ETSI primitives only. No third party controlled binding in the hot path. Aligned with EU NIS2, CER, eIDAS 2.0, and emerging post-quantum mandates.

Adaptive resilience without compromise. Independent design parameters control security level and operational resilience separately. Authentication absorbs transient ratchet ticks, oracle hiccups, schema transitions, and clock drift transparently — without weakening the cryptographic guarantee.

5. The protocol family

The EdSSA protocol family is six tiers. Each tier is shaped to a specific operational reality. Most deployments use two or three tiers together.

EdSSA Nano — the base protocol. Two parties, one bootstrap, forever-after authentication. The foundation every other tier builds on.

EdSSA Fleet — horizontal scale. A single Fleet ID routes the entire client population through a lock-free verification path. Suitable for high-volume IoT, M2M platforms, and smart-meter populations.

EdSSA Swarm — multi-member identity. The swarm authenticates as a swarm. Threshold-based identity that holds even when a fraction of members are jammed, lost, or compromised. Suitable for drone formations, satellite constellations, and any operational unit that is a group of devices rather than a single device.

EdSSA Relay — heterogeneous capability. Role-tiered protocol behaviour, multi-hop attestation, and routing as part of authentication. Suitable for swarms where some nodes have richer connectivity than others.

EdSSA Edge — pass-through validating relay. Validate at the network edge for almost no CPU cost. Forged or expired tokens never reach origin.

EdSSA Orbit — satellite-native time and event coupling. Authentication keyed to physical events — perigee passage, eclipse exit, ground-station acquisition. Hibernation handshakes survive multi-orbit comms gaps without re-bootstrap.

What is built today. Nano, Fleet and Edge run today — on the public demo deployment, and inside the hosted service described in section 10. Swarm, Relay and Orbit have their foundations in the codebase; the rest of each — the threshold agreement between swarm members, relay behaviour across a cluster, and live orbit-event sources — is built out with the first operator who needs it. We would rather say so than let a list of tiers imply more than exists.

6. Where EdSSA wins, where EdSSA does not

EdSSA does not replace cloud-microservice authentication. The vault-based pattern, in its envelope, is the right tool. It will continue to be.

EdSSA addresses what the vault model cannot reach. Our public comparison, at edssa.io/compare-protocol, sets EdSSA against mTLS, OAuth 2.0 and JWT, DPoP, SPIFFE, Vault dynamic secrets, post-quantum hybrid TLS, SCMS and Kerberos across thirteen architectural properties — among them operating without a central authority in the hot path, surviving a multi-day disconnect, post-quantum credential security, sub-microsecond verification, per-request audit emission, and transport independence.

In our own scoring, which anyone can check row by row, EdSSA meets eleven of the thirteen. On the last two — a standardised RFC and a decade of production deployment — the alternatives are ahead. The RFC row is time, not architecture: EdSSA-over-QUIC is written as an Internet-Draft for individual submission in 2027 — timed so the patent filings that underwrite its royalty-free licence are on record first. See /why/standards-track for the full trajectory. The decade-of-production row is time too, and it fills in the same way.

For the harsh-conditions operator and the regulated-vertical operator, those eleven rows are dispositive. For the cloud-microservice operator already inside the vault envelope, the last two are. The boundary is real, and we do not try to argue it away.

7. Patent and standards-track posture

The EdSSA protocol family is the subject of patent application "Decentralised Stateless Structural Authentication", filed at the Finnish Patent and Registration Office (PRH) on 1 May 2026 — a European-jurisdiction filing establishing Paris Convention priority, with PCT international extension planned within the 12-month priority window. The application spans 54 claims and 11 figures across roughly 80 pages. A second application was filed at PRH on 1 September 2026, and further filings are in preparation.

We treat patents as defensive infrastructure, not litigation weapons. Customers receive cryptographic protection from the protocol's security properties, operational protection from our trade-secret implementation knowledge, and commercial protection from the patent portfolio.

The protocol itself is drafted as an open Internet-Draft, to be published and licensed royalty-free for conforming implementations under BCP 79 (IETF IPR Policy). The patents defend the company; the open protocol defends the ecosystem. Both have to be true at the same time. An authentication mechanism for agentic AI, vehicle-to-infrastructure, satellite mesh, sub-processor data-handling chains, and critical infrastructure cannot be the property of a single vendor — the ecosystem will not standardise on something it cannot freely implement, audit, or fork.

Standards-track trajectory: an Internet-Draft as an individual submission in 2027, sequenced after the continuation filings; CFRG review, IETF Hackathon interop and a QUIC working-group approach across 2027–2028; a Standards-Track or Experimental RFC from 2028. The implementation moat lives in engineering excellence and operational depth; protocol exclusivity is not part of the commercial defence. Detailed claim coverage and the standards-track filing posture are available to evaluators under mutual NDA.

8. Sovereignty posture

EdSSA is built in Helsinki, Finland. The company is Finnish. The infrastructure the protocol and the hosted service run on is European. The post-quantum bootstrap uses ML-KEM (NIST FIPS 203); everything after it runs on a symmetric core of standard one-way functions. In a self-operated deployment the cryptographic state lives only at the endpoints — no service we operate holds it. The hosted service in section 10 is the deliberate exception, and it says so.

We are not anti-American. NIST has done excellent work in post-quantum standardisation, and EdSSA uses it. We are pro-sovereignty in the sense that operators who require control over where their cryptographic dependencies live should be able to control it. A sovereign-grade reference for a decentralised authentication layer originating in Helsinki is a structural fit with EU strategic-autonomy goals, and with the supervisory regimes being built under NIS2, CER and DORA.

9. Compliance posture

EdSSA is positioned for the regulatory environment European critical-infrastructure and regulated-vertical operators are moving into:

EU NIS2 and CER directives — sovereignty- and post-quantum-aligned for critical-infrastructure operators; public-administration entities explicitly in scope per Annex I.
EU GDPR Articles 28 + 30 — sub-processor authorisation chain and records-of-processing-activities, with operationally verifiable evidence per data-handling boundary.
EU DORA Articles 28(3) + 30 — ICT third-party register-of-information and key contractual provisions including audit rights at scale for CIF-supporting arrangements.
EU AI Act Articles 12 + 14 — lifetime record-keeping for high-risk AI systems and human-oversight evidence including Art. 14(5) two-person verification for Annex III(1)(a) biometric identification.
EU Cyber Resilience Act — post-quantum from launch, no late-cycle migration burden.
eIDAS 2.0 — architecturally compatible with sovereign-identity requirements.
CNSA 2.0 — post-quantum primitive selection aligned with US national-security cryptographic mandates.
IEC 62443 — industrial-edge and ICS deployments.
ISO 27001 / SOC 2 Type II / Common Criteria — required at the operational maturity level our first real deployments will demand. A SOC 2 Type 1 engagement is scoped for the enterprise general-availability cycle. We will engage further auditors and evaluation labs as that cycle closes.

The audit substrate is a Tier-4 Merkle-anchored chain with a seven-year retention floor, designed for operator-independent verification: every authentication event anchors into a chain that the data owner, the regulator, the national audit institution, or any downstream counterparty can verify without further cooperation from the operator. The chain's roots are published through a public transparency log at edssa.io/transparency. Per-tenant scoping and signed evidence archives ship with the substrate. Vertical-specific positioning is published at /solutions/{satellites, data-supply-chain, public-sector, agentic-ai}, each anchored on the regulatory regime that maps most directly. Example evidence reports for 34 frameworks — NIS2, DORA, GDPR Article 28 and the AI Act among them, alongside SOC 2, ISO 27001, HIPAA, PCI DSS, IEC 62443 and DO-326A — can be downloaded in five formats at edssa.io/why/compliance, with no account.

Operational status, September 2026. The protocol runs on a public demo deployment at demo.edssa.io, and it has run on commodity microcontrollers — among them a five-dollar RISC-V board that authenticated to that deployment over the public internet for weeks. The metering and evidence substrate completed its shadow-mode validation in August 2026, and EdSSA Autopliance, the hosted evidence service, opened for self-serve subscriptions the same month. Pilot deployments are scoped under NDA. Enterprise general availability remains gated on SOC 2 Type 1, an independent cryptographer review, and at least five charter contracts.

We claim no certification we do not hold. Stated intents are stated as intents.

10. EdSSA Autopliance — the hosted way in

Most of this paper describes a protocol you deploy. EdSSA Autopliance is the version you subscribe to. EdSSA runs the verifier and the evidence chain; your own systems ask the service for credentials over HTTP and present them — or, while you evaluate, EdSSA drives the traffic for you — and the service turns the resulting chain into compliance evidence: anchored reports mapped to 34 frameworks, in the five formats an auditor or a GRC pipeline asks for, and signed evidence archives a third party can check without an account.

Three things are worth stating plainly, because they are easy to over-read:

The evidence says whose it is. A verified chain proves the record is intact. It does not, on its own, prove who produced the events — so when the traffic was generated by EdSSA rather than by your systems, the report says so on its face.
Hosted is a trade-off, not the architecture. In a self-operated deployment every secret stays at your endpoints. In the hosted service EdSSA holds the secret of each fleet it runs for you; that is what lets it verify, and mint credentials on your behalf.
Evidence is not certification. The reports are evidence to file against controls. They are not an attestation or a certification, and they say so.

Plans, limits and the free trial are at edssa.io/pricing.

11. Engaging with us

This whitepaper is the public-safe surface. It does not contain L3 specification material — bit-level credential format, oracle source curation, parameter calibration, performance numbers in absolute time — by design.

The hosted service needs no conversation: start at edssa.io/pricing. For evaluating partners, we share the deeper specification under mutual non-disclosure agreement. The path is:

Inquiry. Email tw@edssa.io, or use edssa.io/talk.
NDA call. Initial conversation to scope the deployment context and the operational envelope.
Mutual NDA. Standard mutual NDA, executed in days.
Specification handover. L3 protocol specification, with technical depth appropriate to the evaluation.
Pilot. If the evaluation lands, we scope a pilot deployment in your operating envelope.

We are building EdSSA with the understanding that the partners we win in the early phase are the partners who define the protocol family for a decade afterward. Serious counterparties get serious depth.

12. About EdSSA

Paraproven Oy, trading as EdSSA, is a Helsinki-based deeptech company building post-quantum, decentralised, machine-to-machine authentication — and the evidence layer that comes with it — for harsh-conditions operators and regulated-vertical sub-processor chains. The protocol is patent-pending, with two applications on file at PRH (the first filed 1 May 2026, with 54 claims), and its IETF standards track begins with an Internet-Draft planned for 2027. The architecture is sovereign by design. The team is small, growing, and listed publicly with placeholder discipline — we do not fake people.

Changes in this version

v1.3 · September 2026. Adds what runs today, tier by tier (section 5); EdSSA Autopliance, the hosted evidence service (section 10); the public transparency log; a fourth market pressure, evidence; and the second patent application.

Corrects four statements from v1.2.1. The post-quantum paragraph now describes the protection the design actually has: it rests on the standardised ML-KEM handshake and on state that only moves forward, and v1.2.1 overstated it. The primitives are listed as what EdSSA uses — v1.2.1 also named FIPS 204 and 205, which it does not use. The IETF position is described as a plan rather than as work in progress. And the statement that no service we operate holds customer secrets is now scoped to self-operated deployments, because the hosted service does hold them.