Manufacturing teams should build an inventory that includes internal systems, remote workers, vendors, SaaS platforms, and connected devices. Start by mapping where data flows, who can reach it, and which controls sit at each boundary. In a perimeterless environment, the goal is not one hardened edge. It is layered defense in depth around the assets, processes, and data that matter most.
What “attack surface” means in a manufacturing environment
For manufacturing teams, attack surface is the full set of places an adversary could reach, abuse, or disrupt across plant systems, business systems, suppliers, cloud platforms, and remote access paths. That includes not just obvious production assets, but also engineering workstations, file transfer points, support portals, and the integrations that move data between them.
The practical question is less “what do we own?” and more “what can be touched, by whom, through which path, and with what operational consequence?” In manufacturing, that matters because IT and OT are often tightly coupled, so a weakness in one zone can create exposure in another.
A useful mental model is that attack surface is shaped by connectivity, trust, and privilege. If a vendor can reach a maintenance portal, if a SaaS platform can push data into scheduling systems, or if a remote worker can bridge a privileged path into a plant application, that path belongs in the map even if it is not directly internet-facing.
How to map internal systems, third parties, and cloud services together
Start with a boundary map, then build downward into systems and interfaces. The boundary map should show internal applications, OT and plant-adjacent services, cloud workloads, SaaS dependencies, vendors, outsourced support, and remote users. From there, trace the data flows and control points that connect them, including authentication, administration, file exchange, APIs, remote management, and privileged support channels.
For each connection, capture four things: the asset or service being reached, the identity or role that reaches it, the protocol or integration used, and the control that limits misuse. That can mean network segmentation, MFA, conditional access, restricted API scopes, jump hosts, allowlists, logging, or vendor-access approval. The point is to document the path and the constraint together, not as separate inventories.
Cloud services and third parties deserve the same treatment as internal systems because they often expand the effective perimeter. A SaaS app may not own plant equipment, but if it can influence scheduling, quality records, or maintenance tickets, it can still affect production outcomes. For OT-heavy environments, NIST SP 800-82 Rev 3 is a strong reference for segmenting operational technology and understanding where trust boundaries should sit.
Manufacturing teams should also map dependencies between business systems and production systems, because the riskiest paths are often indirect. A payroll platform is usually low risk to the plant, but a shared identity provider, remote support tool, patching platform, or data integration service can create a common failure point across environments. That is where a boundary map becomes a resilience tool as well as a security artifact.
What to include so the map is actually usable
A usable attack-surface map needs enough detail to support decisions, not just awareness. At minimum, each element should show ownership, environment, business criticality, exposure type, and the controls that reduce blast radius. If the team cannot tell whether a path is internet-exposed, vendor-exposed, or only reachable internally, the map is not yet operational.
It also helps to record which assets are tied to production continuity, safety, or quality. Manufacturing teams often discover that the highest-risk paths are not the most technologically complex ones, but the ones with the most operational leverage. A backup admin route, a supplier file drop, or a cloud-connected dashboard can have outsized impact if it is weakly controlled.
Where cloud and SaaS are involved, vendor risk and configuration matter as much as system ownership. CSA Cloud Controls Matrix is useful for structuring cloud control questions, while SOC 2 Trust Services Criteria can help when the team needs a vendor assurance lens for availability, confidentiality, and security responsibilities.
Teams should also distinguish between visibility and enforcement. Knowing that a vendor has access is not the same as proving that access is least privilege, time-bound, monitored, and revocable. If the map does not show who can grant access, how access is reviewed, and where logs are retained, it will be hard to use during incident response or audit.
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 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Maps internal, cloud, and third-party assets across the attack surface. |
| AC-20 — Use of External Systems | Covers remote workers and vendor use of non-owned systems and access paths. | |
| CA-3 — System Interconnections | Applies to documented connections between internal systems and external services. | |
| Recommendation — Maintain a current inventory of systems, integrations, and externally reachable assets. Restrict and monitor access from external systems used to reach production resources. Approve and document interconnections between plant, cloud, and third-party systems. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Directly addresses access control across cloud, vendor, and workforce connections. |
| IVS — Infrastructure and Virtualization Security | Fits cloud and hybrid exposure mapping for connected services and workloads. | |
| Recommendation — Enforce least privilege and review access for all cloud and third-party identities. Map cloud-hosted dependencies and harden the trust boundaries around them. | ||
Practitioner Guidance
What to prioritise: Start with the paths that can move from external reachability to production impact, especially remote support, shared identity services, and cloud integrations that bridge IT and OT. Those are the connections most likely to be missed and the hardest to contain if compromised.
What to verify: Verify that each third-party and cloud path has a named owner, a documented reason for access, and a concrete control boundary. If you cannot show how the path is limited, logged, and revoked, treat it as an exposure rather than an accepted dependency.
What good looks like: A strong map lets security, operations, and engineering answer three questions quickly: what is reachable, through which trust path, and what happens if that path fails or is abused. The best maps are living inventories tied to change management, not one-time diagrams.
Practitioner takeaway: In manufacturing, the value of attack-surface mapping is not completeness for its own sake, it is the ability to identify every path that can translate a foothold into operational impact and then narrow, monitor, or remove that path.
Related resources from NHI Mgmt Group
- How should security teams approach data protection across the full lifecycle when information is shared with third parties, stored in cloud services, or accessed from personal devices?
- How should security teams operationalise AI governance across internal and third-party systems?
- How should public-sector teams govern access across legacy systems and cloud services?
- How should security teams build an AI-BOM for cloud AI systems that use managed models, retrieval data, and third-party services?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
