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 argues that EDI is still a massive, under-modernised supply chain layer, and that modern API-style tooling is changing how teams integrate with it.
Why it matters: It matters to IAM practitioners because partner connectivity, service access, and integration lifecycle now sit at the same control boundary as identity governance, even when the system is not a classic NHI workload.
👉 Read WorkOS's conversation on making EDI less terrible
Context
EDI, or Electronic Data Interchange, is the structured transaction layer that businesses still use for purchase orders, invoices, and shipping notifications. The identity question is not whether EDI is old, but how partner connectivity is governed when integrations outlive the people and systems that created them.
The source article frames EDI as a large but operationally neglected integration surface. That matters for NHI governance because every partner connection, API wrapper, and translation layer creates a credentialed dependency that needs ownership, lifecycle control, and change management.
Key questions
Q: How should teams govern legacy EDI integrations with modern API tooling?
A: Treat each integration as a lifecycle-managed identity dependency, not a one-time technical connection. Assign an owner, document the purpose, tie credentials to explicit expiry or review points, and remove access when the business relationship changes. Modern tooling improves speed, but governance still depends on knowing who can reach what, why that access exists, and when it should end.
Q: What breaks when partner connectivity is modernised without access governance?
A: Speed increases, but accountability often weakens. Teams can end up with more connectors, more credentials, and more exceptions than they can review. The result is integration sprawl, unclear ownership, and partner access that persists after the original need has passed, which is the same lifecycle failure pattern seen in other non-human identity estates.
Q: When does EDI automation create more risk than it reduces?
A: It becomes risky when automation shortens delivery cycles but leaves credential issuance, partner approval, and offboarding manual or inconsistent. In that case, the organisation gains convenience without control. The warning sign is a growing set of live partner connections that no one can quickly explain, review, or revoke.
Q: What should security teams look for in legacy integration reviews?
A: Look for persistent trust relationships, undocumented endpoints, shared credentials, and partner links that survive organisational change. Those are the places where integration becomes a hidden access problem. A clean review should answer who owns the connection, what it can reach, and what event would trigger its removal.
Technical breakdown
Why legacy EDI mappings still behave like brittle identity dependencies
EDI integrations are rarely simple file transfers. They depend on partner-specific mappings, transport expectations, routing rules, and credentialed endpoints that must all remain aligned as trading relationships change. In practice, the identity problem is that these connections often persist longer than the business relationship or the engineering team that understood them. That creates a governance gap similar to long-lived service accounts: access and trust remain in place after the original operational context has gone. The failure mode is not format alone, but unmanaged dependency sprawl across systems that were never designed for rapid turnover.
Practical implication: inventory every partner integration as a governed dependency with named ownership, not just as a data-flow record.
How API-style wrappers change the control plane around supply chain data
Modern EDI platforms try to expose old transaction logic through APIs, webhooks, and better documentation. That changes how teams operate, but it does not eliminate the need for access governance. The control plane moves from one-off manual onboarding to repeatable integration management, which is useful only if authentication, authorisation, and offboarding are defined for each partner connection. Without that, modernisation can hide complexity behind cleaner developer experience while leaving the underlying trust model unchanged. The technical shift is from human-mediated setup to programmable connectivity, which expands the need for policy-driven lifecycle management.
Practical implication: tie every API-facing partner integration to provisioning, review, and revocation workflows before scaling adoption.
Why faster developer expectations expose slower governance models
The article’s core technical tension is between modern engineering expectations and legacy transaction infrastructure. Engineers want self-service docs, quick onboarding, and real-time updates, while many EDI ecosystems still assume months-long change cycles and specialist intermediaries. That mismatch produces shadow workarounds, duplicated connectors, and ad hoc credential handling. From an identity perspective, this is a governance problem because delayed access decisions encourage temporary exceptions that become durable access paths. The architecture is not just harder to build, it is easier to govern badly when speed pressures outpace control design.
Practical implication: measure partner onboarding time and exception rate together, because slow governance is a leading indicator of unmanaged integration risk.
Breaches seen in the wild
- LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Legacy integration is now an identity governance problem, not just a systems-integration problem. The article shows that EDI still carries high-value business transactions, which means every partner link represents a governed access relationship. When those relationships are managed as technical plumbing instead of controlled dependencies, ownership, review, and revocation become opaque. Practitioners should treat integration estates as part of the identity perimeter.
Modern APIs do not remove the lifecycle burden of old partner connections. Cleaner developer tooling improves usability, but it also increases the number of parties that can establish and maintain access paths. That makes onboarding speed a governance signal, not just a delivery metric. The practitioner conclusion is that faster integration demands stronger lifecycle discipline, not lighter oversight.
Implicit trust in long-lived trading relationships creates an access gap that looks like efficiency until it becomes exposure. EDI environments often inherit trust from the business relationship and then leave it in place across reorganisations, system changes, and partner churn. That is a classic lifecycle failure mode for non-human access, even when the traffic itself is not secret-bearing. Security teams should assume every legacy partner path needs explicit expiry, review, and ownership.
Identity blast radius is the right concept for modernising invisible transaction layers. Once EDI is wrapped in APIs and webhooks, the number of credentialed touchpoints increases even when the business process stays the same. That widens the blast radius of a compromised integration or an abandoned partner account. The field implication is clear: modernisation efforts should be measured by the reduction of unmanaged trust edges, not by interface polish alone.
Supply chain integration should be governed as lifecycle infrastructure. The better question is not whether EDI is old, but whether its access relationships are still accountable. NHI governance principles apply here because partner credentials, system-to-system permissions, and revocation timing determine whether the control surface is bounded or drifting. Practitioners should map every persistent integration to an owner, a purpose, and an offboarding path.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
- If you are modernising partner access and secret handling together, see Ultimate Guide to NHIs , Key Research and Survey Results for the broader governance baseline.
What this signals
Identity blast radius: as older integrations are wrapped in APIs, the number of credentialed touchpoints expands even when the business process stays the same. That means integration modernisation should be judged by how much unmanaged trust it removes, not by how clean the interface looks. Teams that do not model partner access as lifecycle-managed identity will keep inheriting hidden exposure paths.
The operational signal to watch is whether onboarding speed is rising faster than review quality. If access is being created in days but ownership, expiry, and revocation are still tracked informally, the programme is accumulating control debt. For teams already managing service accounts and secrets, the same lifecycle discipline should extend to partner integrations and translation layers.
For practitioners
- Map every EDI partner connection as a governed identity relationship Create an inventory of trading partners, transport endpoints, credentials, and owning teams so that each integration has a clear lifecycle record and review owner.
- Define revocation triggers for partner integrations Tie offboarding, contract termination, system replacement, and partner change events to explicit deprovisioning steps for all integration credentials and routing rules.
- Measure onboarding speed against exception growth Track how long it takes to establish a new partner connection and how often teams bypass standard controls to meet delivery dates; rising exceptions usually signal governance strain.
- Treat API wrappers as access surfaces Review every webhook, gateway, and translation layer for authentication, authorisation, logging, and expiry, because a cleaner interface can still hide persistent trust.
- Align partner access reviews with business ownership Ensure each EDI integration is reviewed by the business owner who can answer why the connection still exists and what would justify removing it.
Key takeaways
- EDI modernisation is an identity governance issue because every partner connection is a trust relationship with an access lifecycle.
- Cleaner API wrappers reduce friction, but they do not remove the need for ownership, review, and revocation of integration credentials.
- The practical control target is reduced identity blast radius across partner connections, not just faster onboarding or better developer experience.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Persistent partner credentials and revocation gaps map to non-human identity lifecycle control. |
| NIST CSF 2.0 | PR.AC-1 | Partner connections need controlled, bounded access aligned to business purpose. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero trust applies to machine-to-machine partner links that should never be implicitly trusted. |
Review each EDI integration for credential expiry, ownership, and offboarding before it becomes a standing trust path.
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.
- Identity Blast Radius: Identity blast radius is the amount of access, systems, and data exposed when a credentialed relationship is abused or left unmanaged. For non-human and partner integrations, it measures how far a compromised or forgotten connection can reach before controls contain it.
- Integration Lifecycle Governance: Integration lifecycle governance is the practice of assigning ownership, approving purpose, reviewing access, and revoking connections when they are no longer needed. It applies to service accounts, partner links, and API-facing systems where access can persist long after the original business need has changed.
Deepen your knowledge
EDI integration lifecycle and partner access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are modernising long-lived supply chain connections, it is worth exploring.
This post draws on content published by WorkOS: Stedi is making EDI less terrible, a conversation with Zack Kanter. Read the original.
Published by the NHIMG editorial team on 2026-01-14.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org