EDI flows security 2026: defense-in-depth landscape

The security of an EDI flow never reduces to choosing AS2 versus SFTP. The modern answer rests on five layers that reinforce each other: transport, application signature, rest, audit, and post-quantum preparation. This page frames the invariants.

Principle: defence in depth

Defence in depth multiplies control layers so that no isolated failure compromises confidentiality, integrity or availability of the flow. For an EDI exchange, the principle unfolds in five layers:

• Transport security (TLS, AS2, AS4, OFTP2 over TCP/IP).
• Application payload signature and encryption.
• Data-at-rest security (disk encryption, legal archival).
• Audit and traceability (who did what, when, on which order).
• Post-quantum cryptographic preparation.

None of the five suffices in isolation. A TLS transmission of an unsigned payload allows an attacker internal to the recipient to inject an invoice. A payload signature without legal archival fails in litigation. Analysis must be systemic.

Transport layer

The transport layer is now standardised. The main options in 2026:

• AS2 (RFC 4130) — HTTP/HTTPS with S/MIME for signature and encryption. The signed MDN (Message Disposition Notification) provides non-repudiation-of-receipt (NRR) proof that does not exist in plain HTTP.
• AS4 (OASIS ebMS 3.0) — SOAP Web Services with WS-Security. Recommended for PEPPOL eDelivery and more modern than AS2.
• OFTP2 (RFC 5024) — still dominant in European automotive, relies on TLS for transport and offers native signature and compression.
• SFTP (SSH File Transfer Protocol) — robust, simple, massively used; but provides no default message-level cryptographic non-repudiation. Pair with payload signature.
• HTTPS REST — usable for modern EDI APIs and webhooks, provided a mutual authentication layer is added (mTLS, OAuth 2.0 + signed JWT) plus an application non-repudiation mechanism.

For TLS, the 2026 recommendations (based on ANSSI, NIST and BSI guides) converge on TLS 1.3 mandatory for new configurations, TLS 1.2 tolerated until 2027 for legacy partners, and strict disabling of SSLv3, TLS 1.0 and TLS 1.1.

Payload signature and encryption

Payload signature (independently of transport) guarantees end-to-end integrity and sender authentication. In practice:

• S/MIME for AS2 and more broadly MIME messages. Signature with the sender's X.509 certificate, encryption with the recipient's certificate. The SHA-256 + AES-256 pair remains recommended in 2026.
• XML-DSig and XML-Encryption for structured XML payloads (UBL, FatturaPA, BIS Billing, CII). Allow detached or enveloped signatures, and element-grained encryption.
• CAdES, XAdES, PAdES — ETSI advanced signature extensions with timestamping (long-term validation, LTV). Mandatory for electronic invoices in several jurisdictions (Italy SdI, Spain Facturae).
• JWS / JWE for JSON payloads in modern APIs. Allows signature and encryption compatible with OAuth 2.0.

Data at rest

Archived payloads are typically the most exposed asset. Relevant practices:

• Transparent disk encryption (LUKS, BitLocker, AWS KMS, Azure Disk Encryption, GCP Customer-Managed Encryption Keys) — minimal layer.
• Application encryption — encrypt the payload with a specific key before storage, and keep the key in an HSM or KMS separate from the storage. Useful for ultra-sensitive data.
• Certified legal archival — for invoices and legal flows, host in a certified digital safe (NF Z42-013 in France, ISO 14641, or national equivalents).
• Retention policy — typically 10 years for European VAT invoices, 7 years for HIPAA claims in the US, more for some sectors (healthcare up to 30 years). Must be documented and auditable.

Audit and traceability

EDI audit rests on three pillars:

• Application event logs — message emit/receive, validation, transformation, delivery. Recommended in structured format (JSON), centralised (ELK, Loki, Splunk), with regulatory retention.
• Archived cryptographic MDN/receipts — non-repudiation-of-receipt (NRR) proof must be stored alongside the emitted message. AS2 archives the message + MDN pair, AS4 the ebMS message + receipt pair.
• Tracked access and modifications — who accessed which message, when, from which IP. Important for post-hoc investigations and GDPR compliance (right of access to access logs).

Post-quantum roadmap

NIST published its three post-quantum cryptography standards in August 2024 (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA). The transition is now underway in cryptographic libraries and at CAs. For EDI flows, the realistic horizon:

• 2026-2027 — inventory of algorithms used in production, identification of libraries, sandbox of PQC implementations.
• 2027-2028 — deployment of hybrid certificates (classical + PQC), test with non-critical partners.
• 2028-2030 — progressive switch to PQ-only, aligned on root CA evolution.

The detailed PQC EDI roadmap is covered in the article Post-quantum cryptography applied to EDI.

Further reading

• EDI protocols — detailed view of transport protocols.
• Post-quantum cryptography applied to EDI — the detailed roadmap.
• Modern AS2, AS4 and OFTP2 — established-protocol comparison.
• AS2 standard — the canonical page of the most deployed protocol.