AS2 can support a compliant EDI process by providing message signatures, optional encryption, protocol receipts and traceable partner identities. It does not make an organization compliant by itself. Compliance depends on the requirements that apply, how AS2 is configured and whether people can produce reliable evidence that controls operated over time.
If you are looking for a general introduction to AS2 and EDI, start with what an AS2 connection is. This guide focuses specifically on governance, audit trails and control design.
Start with the requirement, not the protocol
“EDI compliance” can refer to contractual partner rules, internal security policy, industry obligations, privacy regulation, financial controls or evidence needed for a dispute. These do not all require the same configuration.
Create a control matrix that maps:
- requirement and source;
- systems and data in scope;
- AS2 or surrounding control that addresses it;
- responsible owner;
- evidence retained;
- test frequency;
- exceptions and remediation.
Do not claim certification or legal compliance merely because AS2 is used. Obtain qualified legal, security or audit advice for the specific regime and jurisdiction.
Identity and authentication evidence
AS2 IDs identify parties inside AS2 headers, while digital signatures validate possession of a corresponding private key trusted for that partner profile. Strong evidence should show:
- configured local and remote AS2 IDs;
- signing certificate fingerprint and validity at message time;
- signature-validation result;
- profile and environment used;
- administrative history for identity changes.
An AS2 ID by itself is not a secret or strong authentication factor. Its value comes from the full profile, signature, network controls and governance around changes.
Integrity and origin
A validated digital signature can demonstrate that the received message was not modified after signing and that it was signed by the private key associated with the trusted certificate.
Retain the result, certificate fingerprint, algorithm, timestamp and relevant message metadata. If evidence must survive beyond certificate expiry, the organization may need additional archival, timestamping or evidentiary controls defined by policy. A certificate expiring later does not automatically erase history, but auditors need enough context to validate what was trusted at the time.
Confidentiality
AS2 message encryption protects the packaged payload for the intended recipient’s private key. HTTPS can separately protect the network session. At rest, decrypted payloads may exist in queues, files, databases, backups or downstream applications.
A complete confidentiality control therefore covers:
- message encryption policy;
- TLS policy;
- private-key protection;
- payload storage encryption;
- least-privilege access;
- secure transfer to downstream systems;
- backup and deletion behavior;
- masking in logs and support tools.
Do not assume message encryption protects a payload after it has been decrypted for processing.
MDNs and delivery evidence
An MDN records the receiving AS2 system’s disposition. A signed MDN with a matching MIC strengthens evidence that the receiver processed the same AS2 message content sent by the originator.
Retain:
- original Message-ID;
- MDN disposition and any modifier;
- signature validation;
- returned and calculated MIC;
- sending and receiving identities;
- timestamps and transmission attempts;
- association with the business document.
An MDN is protocol evidence, not proof of final business acceptance. Link it to any 997, 999, CONTRL or application response. The acknowledgment comparison explains that chain.
Non-repudiation claims
AS2 is frequently associated with non-repudiation of receipt. In practice, the strength of that claim depends on signed messages, signed MDNs, matching MICs, key custody, identity verification, timestamps, retention and the contractual framework between parties.
Use precise wording: describe which evidence is collected and validated. Do not state that any AS2 transmission is automatically legally non-repudiable in every jurisdiction or dispute.
Certificate governance
Certificate controls should include:
- approved creation or procurement process;
- independent fingerprint verification during exchange;
- restricted private-key access;
- inventory by owner, partner, environment and purpose;
- expiry alerts with sufficient partner lead time;
- dual-control or approval for sensitive changes;
- tested renewal and emergency replacement;
- revocation or containment after suspected compromise;
- backup and recovery testing.
Record which partners have loaded a replacement before activation. A global status such as “renewal in progress” is insufficient when one delayed partner can still experience an outage.
Access control and segregation of duties
Separate roles where risk warrants it:
- operators monitor and replay approved messages;
- administrators change partner profiles;
- security owners manage keys and policy;
- auditors read evidence without modifying it;
- business users view their documents without seeing unrelated partners.
Log authentication, profile changes, certificate imports, manual retransmissions, payload access and evidence exports. Protect audit logs from unauthorized modification and synchronize system time.
Change management
AS2 configuration changes can immediately stop or redirect B2B traffic. Apply controlled change to:
- endpoint URLs and IP allowlists;
- AS2 IDs;
- certificates and keys;
- algorithms and MDN mode;
- retry and retention settings;
- downstream routes and webhooks.
Evidence should connect request, approval, test, deployment, validation and rollback. Emergency changes still need retrospective review.
Logging and retention
Define retention by evidence type and requirement rather than keeping everything indefinitely. Possible records include:
- message metadata and identifiers;
- raw headers and protocol dispositions;
- MDN signatures and MIC values;
- certificate fingerprints;
- payloads or encrypted archives;
- EDI acknowledgments;
- administrative audit logs;
- incident and replay history.
Payloads can contain commercially sensitive or personal data. Minimize access, document legal basis and delete according to policy. In some cases, retaining hashes and protocol evidence longer than payload content reduces risk while preserving traceability; validate that design against the actual requirement.
Monitoring controls
Monitor for events that indicate control failure:
- missing or negative MDNs;
- invalid signatures or MIC mismatch;
- decryption failures;
- repeated authentication or AS2-ID errors;
- unusual replay or duplicate rates;
- unauthorized configuration changes;
- certificate expiry;
- queue delays and unprocessed inbound files;
- failure to receive business acknowledgments.
Every alert needs a threshold, owner, response time and runbook. Periodically test that alert delivery and escalation work.
Third-party and cloud AS2 providers
When a provider operates the gateway, clarify shared responsibility:
| Area | Questions to ask |
|---|---|
| Key custody | Who can access, export and recover private keys? |
| Availability | What architecture, SLA and recovery tests support it? |
| Evidence | Can raw MDN, MIC, fingerprints and logs be exported? |
| Data | Where are payloads stored and for how long? |
| Access | Are RBAC, MFA, SSO and audit logs available? |
| Changes | Who can alter partner profiles and how are approvals recorded? |
| Incidents | What notification and investigation support is provided? |
| Exit | Can identities, certificates, configuration and evidence be migrated? |
Review reports and certifications as inputs, not substitutes for assessing your configured service and responsibilities.
Audit evidence pack
For a selected period, be ready to produce:
- current partner inventory and owners;
- approved AS2 security baseline;
- sample profile-change records;
- certificate inventory and renewal evidence;
- sample outbound and inbound message chains;
- MDN signature and MIC validation evidence;
- business acknowledgment correlation;
- access review and administrative audit logs;
- monitoring alerts and resolved incidents;
- backup or recovery test results;
- retention and deletion evidence;
- open exceptions and remediation status.
Select samples using an auditable method and ensure sensitive payloads are handled appropriately during review.
Control self-assessment
- [ ] Applicable obligations and contracts are documented
- [ ] AS2 IDs and certificate ownership are controlled
- [ ] Current signing, encryption and TLS policies are approved
- [ ] Signed MDN and MIC evidence is retained where required
- [ ] Transport and business acceptance are separate states
- [ ] Private keys and cleartext payloads have least-privilege access
- [ ] Partner-profile changes are approved and logged
- [ ] Certificate renewal and compromise response are tested
- [ ] Monitoring thresholds, owners and escalation are active
- [ ] Retention and deletion match policy
- [ ] Provider responsibilities and evidence access are contractual
- [ ] Recovery and evidence export have been tested
For the technical security model, read is AS2 secure?. For a managed deployment, review the AS2Connection hosted AS2 server and confirm your organization-specific control requirements during evaluation.
