A manufacturing SOC can monitor an OT environment without understanding what its security decisions mean for production. That creates a problem additional monitoring cannot solve, because the missing capability is not simply visibility; it is the ability to make a security decision with the right operational information.
IT/OT convergence has made this harder.
A vulnerability may require remediation, while the plant must determine whether patching can occur without interrupting production. A remote access path may create cyber exposure while operations depends on it to maintain equipment.
For years, extending enterprise security into OT appeared logical. It brought production assets into established security governance without requiring organizations to reconsider how that governance was designed.
Those assumptions become difficult to apply when a production asset cannot simply be patched, isolated, restarted, or taken offline without considering equipment dependencies, maintenance schedules, or production conditions.
At Prudent, we see this as an architecture question before it becomes a tooling question. Manufacturing needs a security architecture that governs IT and OT together while recognizing where production requires different controls, information, and decision authority.
The Enterprise Security Architecture No Longer Fits the Factory
Traditional enterprise security architecture assumes security actions can be applied through established processes. Endpoints can be patched, accounts disabled, applications restarted, and systems changed through controlled workflows.
Manufacturing introduces production schedules, maintenance windows, equipment dependencies, and availability requirements that can change the consequences of those actions. A production controller may support a process that cannot simply stop. An engineering workstation may have dependencies on production equipment that enterprise security cannot see.
A control that is routine in IT can therefore become a production decision in OT.
The issue is not that enterprise security practices have no place in manufacturing. They do. The issue is carrying their underlying assumptions into an environment where security actions can affect production.
| Traditional security assumption | Manufacturing reality |
|---|---|
| Systems can be changed when security requires it | Changes depend on production schedules, maintenance windows, and equipment conditions |
| Isolation is primarily a security decision | Isolation can affect production processes and equipment dependencies |
| Asset criticality is primarily technical | Criticality also depends on the production step the asset supports |
| Standard controls can be broadly applied | Controls may need to accommodate equipment and maintenance requirements |
| Visibility supports security decisions | Visibility needs production context to become actionable |
The architectural problem appears when these differences are handled through exceptions rather than reflected in the architecture itself.
A security programme can therefore show strong control coverage while depending on plant knowledge, manual coordination, and recurring workarounds to make those controls workable.
IT/OT Convergence Has Turned Security into an Operational Decision
IT/OT convergence is not only a connectivity change. It changes the consequences of security decisions.
A vulnerability on a corporate endpoint and a vulnerability on a production controller may begin with the same workflow:
- Identify the exposure
- Assess the risk
- Determine remediation
- Close the issue
The decision changes when remediation can affect production.
Security can assess cyber exposure. Engineering can identify equipment and process dependencies. Operations can determine whether patching or isolation is possible during the current production cycle.
Plant leadership may need to approve an action th at could affect output or equipment availability.
The architecture needs to connect these perspectives without expecting one function to make decisions using information it does not own.
Consider remote access. Security may determine that a vendor connection creates unnecessary exposure and recommend restricting it. Operations may depend on that connection to maintain equipment.
The relevant question is whether the architecture establishes how the cyber exposure and maintenance requirement are assessed, who can approve access, and under what conditions it remains available.
The same conflict appears when deciding whether to patch a controller, isolate a compromised workstation, restrict vendor access, or change segmentation around a production cell.
Security therefore needs to move beyond asking what should be protected. It also needs to establish how security actions should be evaluated when they can affect production.
Why More OT Visibility Does Not Solve the Architecture Problem
Manufacturers need OT visibility. Security teams cannot govern assets they cannot identify or investigate activity they cannot observe.
But visibility answers only part of the problem.
Knowing that an asset exists, what it communicates with, and whether its behaviour has changed does not establish what should happen next. That requires the asset’s production role, equipment dependencies, current operating conditions, and the authority to determine an appropriate response.
If that information remains with engineering, maintenance, or plant operations, additional telemetry can give the SOC more data without giving it enough context to act.
VISIBILITY ≠ DECISION CAPABILITY
OT visibility can show what is happening.
Security architecture must also establish what the organization can safely do about it.
That requires enough context to determine whether an asset can be patched, isolated, restarted, or taken offline, and who has authority to make that decision.
That requires enough context to determine whether an asset can be patched, isolated, restarted, or taken offline, and who has authority to make that decision.
Know What the Asset Means to the Production Process
Asset inventory answers what exists. Manufacturing security also needs to understand what an asset does within the production process, what equipment depends on it, and what happens if it becomes unavailable.
Two assets can have similar vulnerabilities while creating very different consequences if compromised or taken offline. Technical severity alone cannot capture that distinction.
The same applies to monitoring. An unusual event has different significance depending on the asset’s production role, current activity, equipment dependencies, and authorized users.
Production context therefore needs to influence the security decision itself rather than remain information someone retrieves during an incident.
The Architecture Must Connect Security and Operational Authority
Context is not enough if nobody knows who has authority to act on it.
Security should assess cyber exposure. Engineering should provide technical and process dependencies. Operations should determine production conditions that affect the safe execution of security actions. The architecture needs to define how those responsibilities connect.
An incident plan that says “isolate the affected asset” is incomplete if nobody has established who determines whether isolation is safe.
A vulnerability process that says “remediate critical findings” is incomplete if production constraints have no defined place in the decision.
The answer is not to make the SOC responsible for production decisions. It is to ensure that the SOC can reach the right information and decision authority without relying on informal relationships.
How Recurring Exceptions Point to an Architecture Problem
Manufacturing will always have situations where a standard enterprise control does not fit a production schedule, equipment dependency, maintenance requirement, or process constraint.
An individual exception can be reasonable. The architectural signal appears when the same exception repeatedly occurs.
If critical production assets routinely require exemptions from standard patching processes, the organization should question the assumption behind the process. If vendor access repeatedly requires a separate approval process, restricted access window, or compensating control, the organization should examine whether its access architecture reflects how equipment is actually maintained.
Recurring exceptions reveal where the formal security model repeatedly conflicts with normal manufacturing requirements.
This makes the exception register more useful than a compliance record. It can show where the architecture is being compensated for by people, manual processes, and undocumented knowledge.
That creates a second-order problem. Someone must remember why the exception exists, who approved it, what compensating control applies, when it should be reviewed, and what happens when the responsible person changes roles.
The organization has effectively moved part of its security architecture into human memory.
CISO CHECK: WHEN IS AN EXCEPTION AN ARCHITECTURE SIGNAL?
If the same exception repeatedly appears around:
- Patching production assets
- Vendor or engineering access
- Asset isolation
- Maintenance windows
- Segmentation changes
Ask whether the organization is dealing with an unusual condition—or
compensating for a normal manufacturing requirement that the security architecture does not accommodate.
For a CISO, recurring exceptions should trigger a different question: is this genuinely an exceptional condition, or is the architecture repeatedly encountering a normal manufacturing requirement?
If the same conflict keeps returning, documenting another exception may manage the immediate issue while leaving the architectural problem intact.
The Architecture Gap Between Security and Operations
Security and operations are often described as having opposing priorities. Security wants risk reduced. Operations wants production maintained.
The more useful framing is that both functions are evaluating the same action as whether to patch, isolate, restart, restrict, or leave an affected system in place from different risk perspectives.
Security sees the cyber exposure. Engineering sees equipment dependencies. Operations sees production conditions. Leadership may see the potential effect on output, delivery commitments, equipment availability, or safety.
Consider a vulnerable production asset that cannot be patched during an active production cycle. Security may determine that the vulnerability requires action. Operations may determine that immediate intervention would affect production. Engineering may identify a dependency that neither initially recognised.
The organization must then decide whether to intervene immediately, reduce exposure through another control, wait for a safe maintenance window, or accept residual cyber risk temporarily.
That decision cannot be made responsibly from vulnerability severity alone.
Shared Governance Does Not Require Identical Controls
IT/OT convergence does not mean every security control should be implemented identically across both environments.
Shared governance means establishing common security objectives, accountability, risk ownership, escalation principles, and decision processes. The controls used to achieve those objectives can differ where production availability, equipment lifecycle, maintenance access, or safety requirements make an enterprise control impractical.
A corporate endpoint and a production controller can both require access controls while using different access models.
An enterprise application and a production system can both require monitoring while using different approaches to normal behaviour and response.
Forcing identical controls into different environments can manufacture the very exceptions the architecture then has to manage.
The objective is not identical controls. It is a security architecture that can govern IT and OT consistently while allowing controls to reflect how each environment actually operates.
Operational Context Belongs in the Security Architecture
Operational context should not sit outside the security architecture as documentation consulted only when something goes wrong.
For manufacturing, that context includes the production process an asset supports, its equipment dependencies, maintenance state, authorized users, change windows, and the consequence of taking it offline.
This changes vulnerability management because prioritization can account for production role and equipment dependency. A critical vulnerability on a controller supporting an active production line may require a different remediation decision from the same vulnerability on a non-production system.
It changes incident response because containment can account for what happens when an affected workstation, controller, or network connection is isolated.
It also changes access governance because legitimate maintenance requirements can become part of the access model rather than recurring exceptions.
Segmentation requires the same treatment. The relevant question is not only which systems should communicate, but what could happen if a compromised system uses that communication path to reach a production cell.
Monitoring requires similar context. The SOC does not need to become a plant operations team, but it needs enough information to distinguish an event requiring immediate containment from one requiring operational validation before intervention.
Can the Architecture Support the Decision When It Matters?
The real test comes when security and production risk collide.
Suppose a production engineering workstation generates suspicious activity during an active maintenance window. The SOC can identify the behaviour and recommend containment. The plant may know that immediate isolation could affect maintenance. Engineering may know which equipment depends on the workstation.
The decision requires more than detection.
| Decision | Required context |
|---|---|
| What is happening? | Security telemetry and analysis |
| What does the asset support? | Production role and process context |
| What depends on it? | Equipment and system dependencies |
| What would containment change? | Cyber and production impact |
| Who can approve the action? | Defined decision authority |
| What happens if action is delayed? | Cyber and production risk assessment |
If answering these questions requires a chain of informal calls, undocumented knowledge, or another exception, the issue is architectural.
The security system has detected the risk but has not provided the information and authority required to govern the response.
From Cyber Risk to Production Decision
At Prudent, we see the practical direction as connecting technical visibility with production context, establishing clear decision rights across security and operations, and using recurring exceptions as signals for architectural improvement rather than permanent workarounds.
The objective is not to make the factory conform to an enterprise security model. It is to build an architecture that can govern the factory as it actually operates, including the equipment dependencies, maintenance requirements, production constraints, and security decisions that determine whether an action is safe and appropriate.
For the CISO, the test is straightforward: when cyber risk and production risk collide, can the architecture provide enough information and authority to determine whether to patch, isolate, restrict access, wait for a maintenance window, or accept residual risk?
If the answer depends on finding the right engineer, recalling an undocumented dependency, or negotiating another exception, the organization has identified more than an operational inconvenience.
It has identified a gap between the security architecture it has designed and the manufacturing environment it is responsible for governing.
That is the architectural finding. The next step is not simply to buy another security tool, but to determine where the architecture itself needs to change.
