By NHI Mgmt Group Editorial TeamBased on WorkOS: “Stedi is making EDI less terrible” (January 14, 2026)

TL;DR: Legacy EDI still moves trillions of dollars in supply chain transactions, yet it remains invisible, slow to change, and built on 1970s-era formats that many modern engineering teams find hard to integrate with, according to WorkOS’s conversation with Stedi CEO Zack Kanter. The governance lesson is that integration speed now shapes operational resilience, and older access and partner models need to be treated as lifecycle problems, not just interface problems.


At a glance

What this is: This conversation frames EDI as the original API for supply chains and argues that its legacy operating model no longer matches how modern teams build and scale partner integrations.

Why it matters: IAM and integration teams need to treat partner connectivity, onboarding, and lifecycle change as governed access problems, because slow integration models can delay operational resilience across supply chains.


Context

Electronic Data Interchange, or EDI, is the long-standing format used to exchange purchase orders, invoices, shipping notices, and other structured supply-chain messages. The article argues that this legacy layer remains central to commerce even though it is often invisible to the teams that depend on it.

The governance gap is not that EDI exists, but that many organisations still manage partner connectivity as a slow interface project rather than a living lifecycle. For IAM, NHI, and integration teams, that means each new partner link, format change, and operational handoff has access-like implications even when no human user is involved.


Key questions

Q: How should security teams govern EDI partner integrations across supply chains?

A: Security teams should treat EDI partner links as governed access relationships, not just transport plumbing. That means every connection needs an owner, a defined message scope, documented onboarding, and a clean offboarding path. The goal is to prevent unmanaged growth as suppliers, marketplaces, and distributors add more integration points over time.

Q: Why do legacy EDI workflows create operational risk for modern teams?

A: Legacy EDI workflows create risk because they were built for slow, manual change, while modern businesses expect API-like speed and frequent partner updates. When change cycles are long, teams accumulate exceptions, custom mappings, and hidden dependencies that are hard to review or retire. That is a governance problem as much as an engineering one.

Q: What are the signs that supply chain integrations need lifecycle governance?

A: The warning signs are long onboarding lead times, undocumented partner connections, repeated manual edits, and uncertainty about who owns a live integration. When those conditions exist, the organisation cannot reliably answer which connections are still needed, which are duplicated, or which can be removed safely.

Q: What is the difference between EDI modernisation and partner governance?

A: EDI modernisation focuses on improving the technology layer, such as APIs, webhooks, and developer experience. Partner governance focuses on ownership, approval, scope, review, and retirement of each trading relationship. The first makes integrations easier to build, while the second makes them easier to control across their full lifecycle.


Technical breakdown

Why EDI behaves like legacy machine identity infrastructure

EDI functions like a partner-to-partner data plane rather than a user-facing application. Each connection carries structured business messages between systems that need predictable authentication, authorisation, and change control, even if the article focuses more on developer experience than protocol mechanics. The practical problem is that many EDI estates were built for slow manual change, not for continuous delivery, so every new integration inherits operational drag. When teams modernise, they are really replacing brittle connection governance with something closer to managed workload identity and lifecycle control.

Practical implication: map EDI partner connections to the same governance model you would use for high-risk workload access.

What modern APIs change in EDI integration workflows

The article contrasts 1970s-era EDI formats with modern expectations shaped by APIs, webhooks, and faster documentation-driven onboarding. That shift matters because integration speed is now part of the control surface: if onboarding takes months, the business accumulates shadow processes, manual exceptions, and unmanaged partner paths. In identity terms, slow provisioning creates standing relationships that are hard to review, hard to revoke, and hard to standardise. Modern tooling does not eliminate governance, but it changes where the governance sits: at provisioning, documentation, and lifecycle automation rather than at the point of every transaction.

Practical implication: move partner onboarding controls earlier in the lifecycle so integration speed does not create unmanaged access paths.

Where supply chain integration becomes a governance issue

The article’s central point is that commerce fragmentation increases the number of EDI connections, especially as brands sell direct-to-consumer while also supporting marketplaces and retail partners. That expands the governance footprint across both technical and commercial relationships. Each additional partner can introduce a new message format, a new handoff, and a new failure domain. For identity practitioners, the lesson is that external connectivity is not just an integration backlog item; it is an access, ownership, and offboarding problem that grows with partner count and business complexity.

Practical implication: treat each new supply chain connection as a governed lifecycle object with ownership, review, and exit criteria.


NHI Mgmt Group analysis

EDI modernisation is really a lifecycle governance problem: the article shows that supply-chain connectivity becomes brittle when organisations treat partner integrations as one-off technical projects. Once partner onboarding, format changes, and decommissioning are handled ad hoc, the control plane disappears behind custom scripts and manual exceptions. The practitioner takeaway is that integration governance must be designed as a repeatable lifecycle, not a collection of one-time connections.

Modern APIs do not remove governance debt, they relocate it: faster onboarding and better documentation reduce friction, but they also make it easier for teams to create more partner relationships than they can govern. That changes the failure mode from slow implementation to unmanaged growth. The right lens is not whether a connection is API-based or EDI-based, but whether the organisation can inventory, review, and retire it cleanly.

Supply chain connectivity now behaves like identity sprawl: every retailer, distributor, and marketplace link adds another privileged business relationship that can persist long after its original purpose changes. This is the same structural problem NHIMG sees in other lifecycle-heavy environments: if ownership is unclear, revocation is delayed and visibility degrades. The practitioner conclusion is to manage partner connectivity as governed access, not just transport.

Stedi’s interview surfaces a named concept that matters for practitioners: integration lifecycle debt: the longer an organisation keeps legacy partner links alive without standardised onboarding and offboarding, the more operational fragility it accumulates. That debt does not always show up as a security incident, but it does surface as slow change, hidden dependencies, and weak accountability. Teams should treat integration lifecycle debt as a measurable governance signal.

The broader market signal is that infrastructure expectations are now part of identity governance: engineers expect API-like speed, but supply chains still run on rules and relationships that require controlled change. The mismatch forces IAM and integration teams to collaborate on partner access, ownership, and retirement. Practitioners should assume that modernisation projects will fail if lifecycle governance is left behind.

From our research library:

What this signals

Integration lifecycle debt: when supply chain connections are created faster than they can be reviewed, organisations accumulate hidden operational fragility that looks like inconvenience until a partner changes, leaves, or expands scope. Teams should watch for rising exception counts, undocumented mappings, and unclear offboarding paths.

EDI modernisation will increasingly converge with identity governance because partner ecosystems now change too quickly for manual control to keep up. The practical shift is to govern every live connection as an owned relationship with reviewable scope, not as an engineering shortcut that can be left in place indefinitely.


For practitioners

  • Map EDI partner connections as governed access objects Create an inventory of every supplier, retailer, marketplace, and translator relationship, including business owner, technical owner, message scope, and retirement path.
  • Standardise onboarding and offboarding for integrations Define the minimum approval, documentation, and revocation steps required before a new EDI connection can go live or be removed.
  • Measure integration change latency Track how long it takes to add, modify, or retire a trading partner connection, then use that metric to find hidden manual work and brittle dependencies.
  • Assign explicit ownership for partner connectivity Tie each live integration to a named business owner and a named operational owner so no connection survives without accountability.

Key takeaways

  • EDI remains essential to supply chains, but its legacy operating model does not fit how modern teams manage partner relationships and change.
  • The main risk is governance drift: as integrations multiply, visibility, ownership, and retirement discipline weaken unless they are designed in from the start.
  • Practitioners should manage each EDI connection as a lifecycle object with explicit ownership, scope, and offboarding criteria.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-5 — Account ManagementEDI partner links behave like managed external accounts that need ownership and retirement.
Recommendation — Apply CIS-5 to inventory, approve, review, and retire each trading partner connection.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsPartner integrations need scoped permissions and traceable authorisation boundaries.
Recommendation — Use PR.AA-05 to define and review the permissions behind each EDI connection.
CSA Cloud Controls MatrixIAM — Identity and Access ManagementCloud-hosted integration platforms still need governance over partner identity and access scope.
Recommendation — Use IAM domain controls to manage who can create, modify, and revoke trading partner access.

Key terms

  • Electronic Data Interchange: Electronic Data Interchange is a structured format for exchanging business documents between organisations, such as purchase orders and invoices. In security terms, it is a long-lived partner integration layer that often depends on stable credentials, fixed mappings, and trusted endpoints that must be governed across their full lifecycle.
  • Integration Lifecycle Debt: The operational and governance burden created when integrations are added faster than they can be reviewed, owned, updated, or retired. It shows up as brittle mappings, undocumented dependencies, and slow change, and it becomes more severe as partner ecosystems scale.
  • Partner Connectivity Governance: The discipline of assigning ownership, scope, approval, review, and offboarding to external business connections. It treats every trading relationship as a managed object with a lifecycle, which is essential when supply chain integration changes affect both operations and accountability.
  • Managed External Relationship: A business-to-business connection that requires control over who can exchange data, what they can exchange, and when the relationship ends. The concept is useful for EDI because the risk often lies less in the message format and more in unmanaged persistence of the relationship.

Deepen your knowledge

NHI governance, identity lifecycle, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org