Nobody wants to interrupt customer orders to investigate a connection that appears to be working. Production deadlines always win that argument. When orders keep arriving, the system delivering them can run for years without anyone asking who owns it, what it can access or what happens when it fails.
Manufacturers are investing heavily in smarter operations. In a 2025 survey of 600 executives at large manufacturers with U.S. headquarters or operations, 78 percent allocated more than 20 percent of their improvement budgets to smart manufacturing. That investment can improve speed and efficiency, but it does not eliminate older dependencies. A modern factory still relies on the connections that tell it what the customer ordered, when to produce it and where the finished product needs to go.
The Connection Works, but Nobody Owns It
Electronic data interchange, or EDI, lets trading partners exchange standardized business documents without someone retyping every purchase order. It is useful infrastructure, and manufacturers have good reasons to keep reliable integrations running. The trouble starts when reliability becomes a reason to stop looking.
Consider a connection established for a customer several years ago. The employee who configured it leaves. A business system changes, and someone introduces a workaround to keep orders flowing. The documentation never catches up. Eventually, the company has an active integration that nobody can fully explain.
That is what makes an integration “orphaned.” It still has a business purpose, but responsibility for looking after it has become unclear.
IT may maintain the server without knowing what the customer needs. The employee handling orders may know exactly what happens when a transaction fails but have no authority to change account permissions. An outside provider may operate the transfer service while assuming the manufacturer handles security monitoring. These arrangements can leave important work undone without anyone deliberately neglecting it.
Disrupting a Factory Without Touching Its Equipment
File-transfer attacks show what happens when a business-critical connection is treated as background infrastructure. In 2023, attackers exploited MOVEit Transfer to steal data. By December 2024, a vulnerability affecting Cleo products was also confirmed to be under active exploitation.
These incidents do not prove that EDI itself is insecure. They prove that the software and access pathways supporting data exchange require the same ownership, patching and monitoring discipline as any other critical system.
For a manufacturer, the business impact depends on the connection. A compromised account might expose customer pricing. Excessive permissions could give an attacker access beyond the files needed for that relationship. Even an interruption that prevents shipping notices from reaching a customer can create a backlog that employees must untangle manually.
The machines might be operating normally throughout.
These exchanges belong in every production continuity discussion. If employees cannot reliably receive orders or confirm shipments, functioning equipment solves only part of the problem. A meaningful security review follows the business process far enough to identify every dependency that can stop production or delay fulfillment.
Keeping Connections Running Requires a Working Knowledge
Replacing every older integration is an expensive answer to the wrong question. A well-maintained legacy connection can be perfectly serviceable. A recently deployed platform can still have excessive access or gaps in monitoring.
Start by proving that the company can explain how a critical transaction moves from its trading partner into its business system. If that explanation depends on finding a former employee or searching an old email chain, the connection is not under control. It needs an owner, current documentation and a tested recovery path.
Manufacturers also need to acknowledge why these arrangements persist. Changing a customer integration can require coordination with another company, and nobody wants to discover a compatibility problem during a busy production week. Security teams should work within that reality. Schedule testing with the partner and give operations a say in the change.
Leaving a known exposure indefinitely because the system is difficult to interrupt is a decision that needs an accountable owner.
Choose an exchange the business would struggle to lose and trace one real transaction from receipt through fulfillment. Bring in the employees who resolve order-processing problems, not only the people who maintain the platform. They may know about a secondary account, manual upload or exception process that never appeared in the system diagram. Compare the documented workflow with what actually happens, record every discrepancy and assign an owner to resolve it.
For each connection, name an internal owner who understands its business purpose and has authority to coordinate technical changes. If a provider manages the service, document who applies patches, who reviews alerts, who contacts the trading partner and who has authority to suspend the connection. “The vendor handles it” is not an operating model. When an urgent security advisory arrives, every one of those decisions already needs an owner.
Then examine the access for each connection. An account used to deliver one customer’s documents should not have unnecessary access to unrelated files. Separate partner accounts where practical so the team can suspend one relationship without interrupting every exchange. Remove unused credentials through a controlled process with a named approver. Protect administrative access with multifactor authentication where supported, and assign responsibility for securing and rotating the credentials used by automated transfers.
Monitoring also needs a named owner on the receiving end. An alert about an unfamiliar destination is useful only if that person investigates it and understands the connection well enough to judge what happened. Normal transaction volumes will fluctuate; unusual access deserves scrutiny even when orders are still arriving.
Finally, practice taking a critical connection offline. Determine how orders will be received during the interruption, who will validate them and how queued transactions will be reconciled afterward. Test for duplicate orders, missed acknowledgments and shipment notices that never reached the customer. Restoring the transfer service is only the technical recovery. The exercise is not complete until the business can process the backlog accurately.
This work gives employees a usable plan when something fails and helps security teams contain a problem without unnecessarily stopping unrelated business. It also makes the next system upgrade less uncertain because the dependencies are understood. The fact that yesterday’s order arrived is a good sign, but it does not prove that the underlying connection is understood, controlled or recoverable.
Keep Orders Moving
Manufacturers that do this work can isolate a compromised connection with less disruption, recover orders without leaving employees to improvise and upgrade systems with a clearer understanding of what the business depends on.
The connections carrying customer orders deserve the same care as the equipment fulfilling them. If a failed integration can delay a shipment, it belongs in the factory’s continuity and security plans. Know who owns it, limit what it can access and practice operating without it. Do that before an outage makes those decisions for you.
