The problem
What today's M2M auth can't deliver in satellites.
Modern constellations are increasingly multi-tenant: a single bus hosts payloads for different customers, coordinates with ground stations operated by different organizations, and serves end consumers who weren't in the original operator trust circle. The existing space-security stack — CCSDS SDLS at the data link, IETF BPSec (RFC 9172) at the bundle layer, DTN (RFC 9171) for intermittent connectivity — authenticates each message on receipt and is mature engineering with deep flight heritage.
What it does not produce is an operator-independent record. SDLS and BPSec verify on receipt; the cryptographic evidence is then consumed, and what gets stored downstream is a regular database record inside the operator's trust boundary. The bus operator's verification log does not prove anything to a payload tenant who doesn't independently trust the bus operator's record-keeping, to a regulator examining a contested handoff three years later, or to an investigator after a mission anomaly. And an SDLS tag from 2026 will not be a useful audit artifact in 2046, after the underlying primitives have migrated.
How EdSSA addresses it
What EdSSA does differently here.
EdSSA Orbit sits above SDLS and BPSec. Every inter-satellite or ground-link authentication event produces — in addition to the link-layer verification — an EdSSA provenance record: anchored, replay-checked, post-quantum-ready (ML-KEM-768 + threshold structure), and independently verifiable against the open EdSSA specification by anyone holding the artifact. State advancement is coupled to physical events the satellite observes locally (perigee passage, eclipse exit, ground-station acquisition), so the record stream stays continuous across multi-orbit gaps without re-bootstrap.
The point is not that EdSSA replaces SDLS or the operator's key-management system. Ground-mediated KMS continues to operate. EdSSA adds the layer none of these produce: an operator-independent, archive-grade record that survives the boundary between trust domains and the eventual migration of underlying crypto primitives.
We are not building space cryptography. The space community has done that. We are building the archival provenance layer that the existing space-security stack does not provide — and that the new generation of multi-tenant, dual-use, long-archive missions increasingly need.
Use cases
Concrete operational scenarios.
- Operator-independent provenance records for optical and RF inter-satellite link authentication events
- Multi-tenant attestation across payload customers, ground-segment partners, and end consumers
- Archive-grade audit records that remain verifiable after crypto migrations and operator turnover
- Constellation-wide swarm-identity attestation for coordinated operations across multi-mission buses
Compliance & standards
Standards and regulatory regimes.
ETSI standards-aligned cryptographic primitives. CCSDS SDLS-compatible — sits above, does not replace. Aligned with the CCSDS Security Working Group post-quantum migration direction. ESA-relevant supply-chain sovereignty posture.
Audit emission
Per-link provenance event records, shippable on next ground-station contact. NIS2-aligned incident-reporting events. Merkle-anchored tamper-evidence suitable for multi-year mission-archive requirements and for verification by parties outside the original operator trust circle.
Customers
Operators in this vertical.
“Inter-satellite link authentication events now produce records any of our payload tenants can verify independently — without trusting our internal logs.”