EDI and B2B Integration Security Guide: securing AS2, AS4, OFTP2, VANs and trading partner certificates

Electronic data interchange carries orders, invoices, shipping notices and payment instructions between companies automatically, so a forged, altered or diverted EDI message can move goods or money without a human ever reading it. B2B integration also depends on a web of long-lived trading partner certificates, shared credentials and gateway servers that face the internet and the partners alike. This guide covers the security model of the main B2B transports (AS2, AS4, OFTP2, SFTP and value-added networks), how to manage trading partner certificates and identities, how to protect the gateway and the business documents, and how to detect fraud and tampering in the flows. It is for integration architects, EDI and B2B operations teams and security engineers. Server hardening for file transfer platforms is covered in the Managed File Transfer (MFT) Security Guide; this page focuses on the protocols, partners and documents.

Key takeaways

• Message-level security is the point of B2B protocols. AS2, AS4 and OFTP2 sign and encrypt the business document itself and return signed receipts, which TLS alone cannot provide. Turn those features on and require them.
• Trading partner certificates are identities. Each one authenticates a company to your order or payment process. Inventory them, track expiry and owners, and verify every certificate change out of band.
• The B2B gateway is a tier-one internet edge. File transfer and B2B integration products have been mass-exploited; patch them as you would a VPN gateway and keep their stored partner credentials to the minimum.
• Validate content, not just transport. A correctly signed message can still carry a changed bank account or a fraudulent order. Business rules and anomaly checks catch what cryptography cannot.
• Retire weak defaults. SHA-1 MICs, unsigned receipts, plain FTP and shared passwords still run in many partner links because "the partner only supports that".

The B2B transport landscape

EDI standards such as ANSI ASC X12 and UN/EDIFACT define the document formats; the transport protocol decides how they are secured in flight. Most organisations run several at once because each trading community has its own norm.

Note the IESG caveat on RFC 5024: it is an Informational RFC, not a candidate for Internet Standard, and its security design was not reviewed by the IETF. That does not make OFTP2 weak, but it means you should rely on its TLS and CMS options rather than on the protocol's own claims.

What the protocols protect, and what they do not

AS2

RFC 4130 provides confidentiality and authentication through Cryptographic Message Syntax. The receiver returns a Message Disposition Notification (MDN), which can be signed and contains a Received-content-MIC so the sender can confirm the partner received exactly what was sent. That signed receipt, with the original signed message, is the evidence for non-repudiation of receipt. The RFC says a signed receipt must still be returned when processing fails, that the complete certificate chain must be included, and recommends duplicate detection by Message-Id or business identifiers to deal with replay. Receipts can be synchronous (in the HTTP response) or asynchronous (a later connection to a return URL).

Three practical points follow. First, RFC 4130 dates from 2005 and recommends SHA-1 for the MIC; current AS2 products support SHA-2 algorithms, and you should require them for new partners and negotiate upgrades with existing ones. Second, AS2 allows self-signed certificates, which is common, so trust depends entirely on how you received the partner's certificate. Third, AS2 over plain HTTP still protects the payload if signing and encryption are on, but HTTPS adds protection for headers and makes downgrade harder; use both.

AS4

The OASIS AS4 profile defines conformance profiles of different strength: the full ebHandler profile requires signing and encryption, the Light Client requires signing only, and the Minimal Client sets no security requirements beyond optional pull authorisation. Choose the profile deliberately. The profile recommends, but does not mandate, TLS. Community profiles tighten this: the Peppol AS4 profile (v2.0.3) is push only over port 443, signs with the sending access point's Peppol certificate, encrypts to the receiver's certificate fetched from signed SMP metadata, and forbids certificates not issued by OpenPeppol.

OFTP2

OFTP2 adds TLS, file-level CMS signing and encryption, compression and signed end-to-end receipts to the older OFTP. File encryption protects file content but not protocol commands or virtual file names, so run sessions over TLS as well. Its own authentication is a challenge-response using both parties' X.509 certificates.

What none of them do

• Validate business content: a signed invoice with a changed bank account is still a valid AS2 message.
• Prove the partner is who they claim at onboarding: a self-signed certificate sent by email proves only that someone sent an email.
• Protect the data at rest: once decrypted on the gateway or in the translator, documents are plain files in folders and databases.

Trading partner certificates and identities

Every partner connection involves at least one credential: an AS2 signing and encryption certificate pair, an OFTP2 certificate and Odette ID, an SFTP key or password, a VAN mailbox login or an API client. These are non-human identities with business authority, and they behave like any other: they outlive the people who set them up, they are shared and they expire at the worst moment. See the Machine Identity, PKI and Certificate Lifecycle Guide.

For timing and automation of renewals, see the Certificate Renewal Runbook Template.

Securing the B2B gateway and translator

The B2B gateway terminates partner connections on the internet; the translator converts EDI to internal formats and passes it to ERP and warehouse systems. Both have been prime targets. The CISA Known Exploited Vulnerabilities catalogue lists CVE-2024-50623 and CVE-2024-55956 in Cleo's B2B integration products (added 13 and 17 December 2024) and CVE-2023-34362 in MOVEit Transfer (added 2 June 2023), all with known ransomware use. These map to ATT&CK T1190 Exploit Public-Facing Application.

• Network placement: gateway in a DMZ, translator and ERP connectors inside, with only the needed flows between them. Restrict inbound partner connections by source IP where partners have fixed addresses.
• Patching: treat the gateway as a critical internet edge with an emergency patch route. Subscribe to the vendor's security advisories.
• Administrative access: SSO with phishing-resistant MFA for the admin console, no admin interface on the internet, separate accounts for operations and configuration.
• Stored secrets: partner passwords, VAN logins and API secrets in the platform database are a credential store. Externalise them to a secrets manager where supported. See the Managed file transfer (MFT) integration security guide.
• Data at rest: encrypt archive and work folders, keep retention to what contracts and law require, and purge processed files from inbound and outbound directories.
• Integrity on the inside: the hop from translator to ERP is often a plain file drop or a database insert. Restrict who can write to those locations, because a file placed there bypasses every partner control.

Business content controls and fraud detection

Attackers interested in money target the documents, not the protocols. ATT&CK T1565.002 Transmitted Data Manipulation describes altering data in transit, and T1199 Trusted Relationship describes abusing partner access.

• Remittance and bank details: changes to supplier bank details arriving in EDI vendor master updates or remittance documents must go through the same independent verification as any other channel. See the Invoice Redirection and Supplier Bank Detail Fraud Guide.
• Order and invoice anomalies: flag unusual quantities, new ship-to addresses, price changes outside contract tolerance, duplicate invoice numbers and documents outside a partner's normal schedule.
• Sender binding: check that the EDI interchange sender ID matches the authenticated partner profile, so one partner cannot submit documents as another.
• Duplicate and replay checks: use message IDs and business identifiers, as RFC 4130 recommends, and reject or quarantine repeats.
• Schema and syntax validation: reject malformed interchanges at the gateway rather than passing them to the ERP parser.

Decision guidance

• Choosing a transport for a new partner: use the community's standard (Peppol AS4 for Peppol e-invoicing, OFTP2 for automotive, AS2 for most retail) because interoperability and evidence are worth more than a custom choice. For bilateral links with no standard, AS2 with signing, encryption and signed MDNs, or an API with mutual TLS and signed payloads, gives non-repudiation that plain SFTP does not.
• Direct connections or a VAN: a VAN reduces the number of partner connections you manage and can suit small organisations, but you inherit its security and you lose end-to-end signatures unless partners sign messages themselves. Ask the provider about MFA, mailbox isolation, logging and incident notification. See the IT Service-Level and Operational Supplier Assurance guide.
• Self-signed or CA-issued certificates: self-signed is acceptable for AS2 if fingerprints are verified out of band; community PKIs such as Peppol remove that burden. Public web TLS certificates now have much shorter lifetimes, so avoid using them as long-lived message signing certificates.
• Small organisations: a hosted B2B service with SSO and MFA, a certificate inventory and out-of-band verification of changes covers most of the risk.

Implementation steps

1. Inventory partners and flows: each partner, protocol, document types, direction, credentials, algorithms and endpoints. Mark flows that carry payment or bank data.
2. Patch and isolate the gateway and close any admin interface exposed to the internet.
3. Set a security baseline per protocol: for AS2, signing and encryption required, signed MDN requested, SHA-256 or stronger, HTTPS; for SFTP, keys not passwords, per-partner accounts; for OFTP2, TLS plus file signing.
4. Find non-compliant partners in report mode: list partners sending unsigned messages, weak algorithms or plain FTP. Agree upgrade dates with each.
5. Introduce certificate change verification and the overlap rotation process; test with one friendly partner.
6. Add business content rules for bank detail changes and anomalies, starting in alert-only mode for a month, then quarantining.
7. Enforce the baseline partner by partner, keeping the old profile available for rollback until the first successful exchange.

Detection and measurement

Log at the gateway: connection source, authenticated partner, message ID, signature and decryption result, MDN or receipt status, and configuration changes to partner profiles and certificates. Forward to the SIEM and alert on new or changed partner certificates, failed signature checks, connections from new sources, admin logins outside change windows and spikes in failed messages.

• Signed and encrypted coverage: share of partner flows with message signing and encryption enforced.
• Weak algorithm count: partners still on SHA-1, plain FTP or password-only SFTP.
• Certificate expiry horizon: partner certificates expiring within 60 days without a replacement exchanged.
• Unverified changes: certificate or bank detail changes without recorded out-of-band verification (target zero).
• Gateway patch latency: days from vendor security release to deployment.
• Dormant partners: partner profiles with no traffic in 90 days that are still enabled.

Framework mapping

Common failure patterns

• Certificate swaps by email. A partner "updates" its AS2 certificate by email and the team imports it without checking the fingerprint, letting whoever sent it receive and send documents as that partner.
• Unsigned receipts accepted. MDNs are requested unsigned, so the organisation has no evidence that a partner received a document when a dispute arises.
• Legacy algorithms kept forever. SHA-1 MICs and old cipher suites remain because one large partner never upgraded, and the weakest setting becomes the global default.
• Gateway patched like a back-office server. B2B and MFT gateways were mass-exploited within days of disclosure in 2023 and 2024; a monthly patch cycle is not enough.
• Shared VAN and SFTP credentials. One mailbox password used by several internal teams and scripts, never rotated after staff leave.
• Trusting signed content blindly. Bank detail changes flow straight into the vendor master because the message was "authenticated".

Practitioner checklist

• Keep a partner and credential inventory with protocol, algorithms, fingerprints, expiry and owners.
• Require message signing, encryption and signed receipts for AS2, AS4 and OFTP2 flows; use SHA-256 or stronger.
• Verify every partner certificate or key change out of band with a known contact.
• Rotate certificates with an overlap window and alert 60 days before expiry.
• Place the gateway in a DMZ, keep its admin interface off the internet and patch it on an emergency track.
• Move stored partner secrets to a secrets manager or protected key store; protect private keys from export.
• Bind EDI sender IDs to authenticated partner profiles and check for duplicates.
• Verify bank detail changes independently, whatever channel they arrive through.
• Disable dormant partner profiles and revoke their credentials.
• Forward gateway logs to the SIEM with alerts on certificate changes and signature failures.

Standards and references

• IETF: RFC 4130 AS2, MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP
• OASIS: AS4 Profile of ebMS 3.0 Version 1.0
• IETF: RFC 5024 ODETTE File Transfer Protocol 2
• OpenPeppol: Peppol AS4 Profile
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE ATT&CK: T1565.002 Transmitted Data Manipulation

Related NHI Mgmt Group resources: Managed File Transfer (MFT) Security Guide · mTLS Guide · GoAnywhere MFT Hardening Guide · ISO/IEC 27036 Supplier Relationships Guide