When MCP servers accept inbound connections in brownfield OT or hybrid IT and OT environments, they become a reachable attack surface. That creates exposure for uptime, intellectual property, and safety, even if application-layer authorization exists. A stronger pattern is to remove direct network reachability and allow only authenticated, policy-authorized sessions from outbound-connected services.
Why direct reachability is the first thing that breaks
When an mcp server is reachable from the network, the trust boundary moves from a controlled caller path to any host that can open a connection. In manufacturing, that often means the server is no longer just a tool broker, it is a reachable exposure point for production-dependent systems, even if the application itself expects authorization later in the flow.
That changes the operational posture immediately. A directly reachable server can be scanned, probed, rate-limited, misused, or integrated into an attacker’s foothold path, and in brownfield OT that matters because availability usually has higher practical value than feature completeness. The network path itself becomes part of the risk, not just the app logic.
Manufacturing environments amplify that effect because legacy segmentation, shared services, and fragile dependencies make “open but authenticated” a weaker position than it looks on paper. A service that should have been callable only from a narrow outbound-controlled path now behaves like an exposed control-plane component.
What availability, safety, and IP exposure actually means here
The first broken assumption is uptime. If the server is directly reachable, any fault, flood, malformed request pattern, or routine misconfiguration can turn into an operations event, and production teams often feel that before the security team does. In OT, even short-lived interruption can cascade into missed batches, manual fallback, or locked workflows.
The second broken assumption is that authorization alone contains the risk. If the network can reach the listener, then the defender is relying on every upstream control, every policy decision, and every tool implementation staying correct under stress. That is a much narrower safety margin than keeping the service behind an outbound-only mediator or gateway.
The third broken assumption is confidentiality around industrial knowledge. In manufacturing, exposed orchestration and tool endpoints can reveal process names, asset relationships, vendor integrations, or internal commands that help an attacker understand where to pivot next. The issue is not just command execution, it is the accumulation of operational intelligence.
For a broader control view of OT exposure, NIST SP 800-82 Rev 3 is the most direct reference in the supplied set, because it frames the segmentation and boundary conditions that keep industrial systems from becoming easy reachability targets.
Why outbound-connected access patterns are safer than exposed listeners
A better pattern is to make the server a private service behind an outbound-connected broker, connector, or session initiator. That preserves the useful function of MCP while keeping the production-side asset from accepting arbitrary inbound traffic. In practice, this means the calling path is established from a controlled system outward, rather than from an uncertain source inward.
This matters because authenticated, policy-authorized sessions are only strong when the session establishment itself is constrained. If the server is directly exposed, the first question becomes whether the request should be allowed at all, which is a worse place to be than only allowing known, controlled sessions to exist in the first place.
For the MCP-specific model, the MCP authorization specification is relevant because it treats servers as protected resources and avoids token passthrough assumptions that become dangerous when a server is simply left open on the network.
That is also why the MCP Security Guide and OWASP Agentic Applications Top 10 are useful companion reads: one focuses on the deployment and authorization patterns, the other on the abuse paths that appear when tool access and identity boundaries are too loose.
Risk and Threat Considerations
Directly reachable MCP servers in manufacturing create a predictable attack surface: discovery, probing, abuse of exposed tool endpoints, and escalation through the production control plane. The practical risk is not limited to malicious use, because even a benign integration mistake can produce the same uptime and safety impact when the listener is open to networks it should never trust.
Failure mechanism: An attacker or faulty client reaches the server before the control path is narrowed, then uses the exposed interface to enumerate tools, trigger expensive operations, or exploit weak session handling and trust assumptions.
Impact: The result can be process interruption, unsafe command propagation, disclosure of sensitive industrial context, or a wider foothold into adjacent IT and OT services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Directly addresses controlling inbound exposure and trusted session paths. |
| SC-7 — Boundary Protection | Manufacturing reachability risk is fundamentally a boundary protection problem. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | MCP sessions depend on external callers being strongly authenticated before access. | |
| Recommendation — Enforce flow restrictions so MCP servers are reachable only from approved mediation paths. Segment MCP servers behind boundary controls and block direct inbound access. Require strong authentication for any external session that reaches the MCP service. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Direct exposure of a service that should be hidden is a deployment misconfiguration pattern. |
| Recommendation — Remove direct exposure and publish MCP services only through approved access paths. | ||
Practitioner Guidance
What to prioritise: Treat network reachability as the primary design decision, not an implementation detail. If an MCP server can be reached inbound from a plant, vendor, or hybrid network segment, redesign the path so the server only accepts sessions that originate from an explicitly trusted outbound connector or gateway.
What to verify: Confirm that the exposed listener is not directly addressable from production-adjacent subnets, jump hosts, partner networks, or remote admin paths. Verify that authentication is paired with network restriction, not used as the only barrier.
Decision rule: If removing the inbound path would not break the intended use case, remove it. If it would break the use case, the architecture is probably depending on an exposure that should be redesigned rather than accepted.
Practitioner takeaway: For manufacturing, the right question is not whether an MCP server is authenticated, it is whether it should be reachable at all. If it is directly reachable, you have already widened the blast radius before the first policy check runs.
