— May 18, 2026 · 9 min read
Zero Trust IAM for B2B flows: 2026 target architecture
The Zero Trust model (NIST SP 800-207, August 2020) has structured the IAM security of internal applications since BeyondCorp (Google 2014). Its transposition to B2B flows — where the "partner" is by definition external — requires a few technical adaptations but remains relevant. Sketch of a 2026 target architecture.
Reminder: Zero Trust principles
NIST SP 800-207 codifies seven principles: (1) every resource is treated as an asset, (2) all communications are secured regardless of location, (3) access to each resource is granted per session, (4) access policy is dynamic and based on identity, application and context attributes, (5) the organisation monitors and measures the integrity of all assets, (6) authentication and authorisation are strictly and dynamically enforced before every access, (7) the organisation collects as much information as possible on asset and communication state to improve posture.
The conceptual break with the perimeter model: there is no longer an "internal" zone of implicit trust. Every call — including between microservices of the same hub — is authenticated, authorised, audited. For B2B flows, the partner has obviously never been in a trust zone; what changes is the consistency of controls with other calls.
mTLS everywhere: the foundation
The first pillar of a Zero Trust B2B IAM is mutual TLS on all communications. AS2 and AS4 already rely on TLS+payload signature; the extension to mTLS to authenticate the partner at transport level has been recommended by OpenPEPPOL since TLS Specification 1.7. mTLS forces the client to present a recognised certificate — the service no longer trusts an identifier carried in the payload but a cryptographically proven identity.
Internally to the hub, mTLS everywhere between microservices is deployed via a service mesh: Istio, Linkerd, Consul Connect. The sidecar handles the handshake and policy enforcement. Always combine mTLS and payload signature — mTLS protects the channel, signature protects content and legal non-repudiation.
SPIFFE/SPIRE for workload identity
SPIFFE (Secure Production Identity Framework For Everyone, CNCF graduated 2022) defines a cryptographic identity standard for workloads: each instance receives an SVID (SPIFFE Verifiable Identity Document) in X.509 or JWT format, attested by a local agent proving "this instance is indeed running on this machine, in this Kubernetes namespace, with this service account".
SPIRE is the reference implementation. For a 2026 EDI hub, SPIFFE gives each internal service a strong identity, automatically rotated (typically every 60 minutes), and directly usable for mTLS and OAuth-MTLS. Adopted in production by Pinterest, Bloomberg, Anthem (see spiffe.io/use-cases).
OAuth-MTLS sender-constrained tokens
For B2B REST APIs (e.g. an EDI hub's extension API used by partner sales-ops), OAuth 2.0 Bearer tokens are vulnerable to theft: whoever presents the token can use it. RFC 8705 — Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (February 2020) introduces sender-constrained tokens: the token is bound to the client's TLS certificate. Without the certificate, the token is useless — far more robust than a plain Bearer.
The current alternative is DPoP — Demonstrating Proof of Possession (RFC 9449, September 2023), which binds the token to an asymmetric key presented by the client on every request. DPoP does not require mTLS and therefore works even behind TLS terminations managed by CDNs — more flexible but trickier to implement correctly.
Policy as code: OPA and Cedar
Zero Trust access policies must be versioned, tested, deployed as code. OPA (Open Policy Agent), CNCF graduated project, is the de facto standard for expressing policies in Rego and evaluating them in microseconds in a sidecar. Amazon Cedar (open source since 2023) offers a more typed alternative, designed to scale and audit more easily.
EDI use case: "partner X may submit INVOIC, but only between 06h and 22h CET, from the declared AS IP range, with a certificate issued by our partner CA, and only for the EAN codes in its contract catalogue". Such a policy is expressed in 20 lines of Rego and is evaluated on every request without any application code change.
Practical case: 2026 target EDI hub
Sketch of a target architecture. At the ingress level (the AS4 endpoint receiving PEPPOL messages): mTLS termination requiring a certificate recognised by the OpenPEPPOL root access point; the partner identity is pulled from the cert's subject DN, verified against the SML/SMP directory. The SBDH payload signature is verified separately for content integrity and non-repudiation.
Inside the hub, each microservice (parser, validator, normalizer, router) has a rotated SPIFFE/SPIRE identity. Inter-service calls go through an Istio sidecar in mTLS, and OPA policies dynamically decide who can read/write what on which Kafka topic. The immutable audit log (compacted Kafka topic, archived on S3 with object lock) traces every policy evaluation for GDPR and SOX compliance.
For external APIs (hub extension used by partner UX or ERP integration), OAuth-MTLS RFC 8705 or DPoP RFC 9449 depending on whether the partner can present a TLS cert or not. Short-lived refresh token (15 min), automatic client rotation.
Conclusion: not a revolution, a convergence
Zero Trust IAM applied to B2B flows is not a rupture. AS2 is 25 years old, AS4 and SBDH signature have always been "zero trust before the term" models for partners. What changes in 2026 is end-to-end consistency: the same rigour of authentication, authorisation and audit applies to internal hub calls as to interactions with external partners. SPIFFE, OAuth-MTLS, OPA and the service mesh tool this consistency without reinventing protocols. To dig further, see our page on EDI flows security 2026.