Applicability Statement 2, or AS2, is a specification for exchanging business data over the internet using HTTP and digital signatures. It defines how messages are encrypted, signed and returned with delivery receipts, so organisations can move files such as EDI payloads with integrity and non-repudiation controls.
What AS2 Is Used For in Secure Business-to-Business Exchange
AS2 is best understood as a transport and message-protection standard for business partners that need to exchange structured data over the internet without losing integrity, authenticity, or delivery evidence. It is most often used where organisations want a controlled alternative to older file transfer patterns for EDI and similar payloads.
Because AS2 is built around HTTP, digital signatures, encryption, and receipt handling, it solves a practical interoperability problem as much as a security problem. The standard gives trading partners a common way to package, transmit, and confirm receipt of messages while preserving the non-repudiation properties that many B2B workflows require.
How AS2 Protects Message Integrity and Non-Repudiation
The security value of AS2 comes from the way it binds content protection to message exchange. Signing allows the receiver to verify that a message has not been altered in transit and that it came from the expected partner, while encryption protects the payload from exposure during transmission. Delivery receipts add a transaction record that helps prove a message was received by the intended endpoint.
That combination matters because many B2B integrations are not just about moving bytes, but about creating defensible evidence for business events. In practice, AS2 is often chosen when organisations need message-level assurance rather than only channel-level protection, especially when multiple partners, intermediaries, or regulatory obligations make proof of transmission important.
For teams evaluating secure file exchange patterns, the Secure File Transfer Buyers Guide is useful because it frames AS2 alongside other secure transfer options, including protocol choice, partner key handling, logging, and retention.
Where AS2 Fits in Partner Integrations and EDI Flows
AS2 is typically used in structured partner relationships where both ends agree on certificates, signing expectations, endpoint configuration, and receipt handling. It is especially common when a business process depends on predictable exchange of EDI payloads, invoices, orders, or similar records that must survive transit with their meaning and provenance intact.
Unlike ad hoc file sharing, AS2 is usually deployed as part of a deliberate integration agreement. That means the operational focus is not only on the protocol itself, but also on partner onboarding, certificate exchange, endpoint availability, message formats, and the rules for retries, receipts, and exception handling.
This is why AS2 often sits inside broader governance and control discussions, even though it is not itself a governance standard. It creates a repeatable mechanism for trust between organisations, but that trust still depends on how tightly the integration is scoped and how carefully each partner manages credentials, keys, and configuration.
Operational Considerations When Using AS2
AS2 deployments succeed or fail on the quality of the surrounding operating model. Certificates need lifecycle management, endpoints need monitoring, and partner configurations need to be tested before production traffic flows. If any of those controls drift, the result is usually failed deliveries, signature verification issues, or weak assurance around who sent what and when.
Organisations also need to distinguish transport success from business success. A message can traverse the network and still fail downstream processing, so AS2 receipt handling, queue visibility, and exception workflows matter just as much as the cryptographic settings. In mature environments, AS2 is treated as an integration control surface, not just a connectivity protocol.
For governance of the supporting controls, the ISO 27001 Statement of Applicability Template can help teams document why certain transfer, key management, and logging controls are in scope for an AS2 environment.
Implementation and Assurance Choices for AS2
Practitioners usually need to decide how much assurance the AS2 channel must provide, which certificates will be trusted, how long messages and receipts must be retained, and how partner changes will be approved. Those choices affect both interoperability and auditability, so they should be aligned with the sensitivity of the exchanged data and the business consequences of a failed or disputed transfer.
AS2 also works best when paired with disciplined review of surrounding control evidence. If a partner, certificate, or endpoint changes unexpectedly, teams should be able to trace what changed, when it changed, and whether prior receipts still support the business record. That makes AS2 as much about operational discipline as about message security.
For broader control selection and evidence reuse, the ISO 27001 Certification Guide is a practical companion because it places AS2-style exchanges inside the wider context of scope, risk treatment, audit evidence, and control ownership.
Risk and Threat Considerations
AS2 reduces exposure when it is configured well, but it can also create concentrated risk if partners rely on weak certificate governance, stale endpoints, or poor receipt handling. The biggest failure modes are message interception without proper encryption, forged or misbound signatures, and business disruption when trust material or partner settings are changed without coordination.
Failure mechanism: An attacker or misconfigured integration can exploit weak key handling, exposed endpoints, or incomplete validation to impersonate a partner, tamper with payloads, or disrupt delivery and receipt processing.
Impact: The result can be false business records, lost transactions, repudiation disputes, and exposure of sensitive commercial data, especially where AS2 is used for regulated or high-volume EDI flows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identifier and Authentication (Non-Organizational Users) | AS2 partner exchange depends on authenticating external trading partners and their endpoints. |
| SC-8 — Transmission Confidentiality and Integrity | AS2 encrypts and signs messages in transit to preserve confidentiality and integrity. | |
| AU-10 — Non-Repudiation | AS2 receipts and signed messages provide evidence that supports non-repudiation claims. | |
| Recommendation — Use IA-9 to authenticate partner systems and protect cross-organization message exchange. Apply SC-8 to protect AS2 payloads while they traverse untrusted networks. Retain receipt and signature evidence to support non-repudiation for AS2 transactions. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | AS2 relies on signatures and encryption to protect exchanged business messages. |
| A.5.14 — Information transfer | AS2 is an information transfer mechanism between organisations with defined business trust boundaries. | |
| Recommendation — Document cryptographic use for AS2 exchanges and manage certificates under approved policy. Define transfer rules, partner requirements, and approval steps for AS2 exchanges. | ||
Practitioner Guidance
Why practitioners should care: AS2 is only as trustworthy as the certificates, partner agreements, and operational controls around it. Treat onboarding, renewal, revocation, and receipt retention as part of the security design, not as administrative follow-up.
Common misunderstanding: Encryption alone does not make an AS2 exchange reliable or non-repudiable. Teams still need strict partner identity checks, monitored endpoints, and retained evidence for delivery and signature verification.
Practitioner takeaway: The strongest AS2 implementations are those that manage transport security and evidence handling as one control system, not as separate tasks.
Related resources from NHI Mgmt Group
- What do teams get wrong about the statement of applicability?
- How should security teams write an ISO 27001 Statement of Applicability so it stands up in audit and internal review?
- Why does the Statement of Applicability matter so much in an ISO 27001 programme?
- What do organisations get wrong when they complete an ISO 27001 Statement of Applicability?