No. Under the NIST Risk Management Framework (RMF), different systems do not have to use an identical set of controls, even within the same organization. Control selection is risk-based, and each system or system boundary can have a different control set, provided the decisions are justified, documented, and approved.
What RMF actually requires
NIST RMF requires you to:
- Determine the system’s impact level (for federal use, per FIPS 199 / NIST SP 800-60 or a comparable method).
- Select baseline controls (for example from NIST SP 800-53 or a sector profile like NIST SP 800-82 for ICS/OT).
- Tailor those controls (add, remove, or adjust) based on system-specific risks and compensating protections.
- Document, implement, assess, and maintain those controls over the system lifecycle.
This process does not require that every RMF system in the enterprise end up with the same final control set. It requires that each system has a defensible, traceable control selection and tailoring rationale.
When different systems can justifiably use different controls
It is common and appropriate for different RMF systems to have different control implementations, and sometimes different control selections, when:
- Impact levels differ: A plant historian that does not handle export-controlled or safety-critical data may not need the same rigor as a system with ITAR/EAR data or safety functions.
- System roles differ: A Level 3 manufacturing operations system connected to corporate ERP carries different risk than an isolated Level 1/2 machine controller with limited connectivity.
- Technical constraints exist: Legacy OT assets may not support certain NIST controls directly (for example host-based agents, modern crypto). Compensating controls at the network or procedural level may be used instead.
- Environments differ: A cleanroom with strict physical access control reduces some physical security risks compared with an uncontrolled shop-floor area, which may influence how certain controls are implemented.
In all cases, you still need traceable justification for any deviation from the baseline, with appropriate approvals and change control.
Why many organizations still standardize on a common baseline
Even though RMF does not require identical controls for all systems, most regulated manufacturers establish a common baseline for similar system types, then tailor from there. This is driven by practical considerations:
- Audit and regulator expectations: Auditors look for consistency of control intent across comparable systems. Ad hoc, system-by-system control sets are harder to defend and maintain.
- Integration and interoperability: MES, ERP, QMS, historians, and OT networks are tightly coupled. Divergent control approaches (for example, different authentication models or logging practices) can complicate interfaces and evidence collection.
- Lifecycle and change control: Plants run mixed-vendor, long-lived assets. A shared baseline by system class (for example, “standard for OT Level 3 servers”) simplifies validation, change impact analysis, and multi-site rollout.
- Cost and complexity: Each unique control set requires separate hardening guides, validation, training, and ongoing assessments. Standardization reduces recurring effort.
So while not mandatory, a documented, reusable baseline control catalog mapped to NIST is usually more sustainable than designing each RMF system in isolation.
Dealing with legacy and brownfield environments
In brownfield industrial environments, some NIST controls may be technically infeasible or operationally risky to implement identically on all systems (for example, full disk encryption on legacy PLC engineering workstations that cannot be easily requalified).
Typical patterns include:
- Class-based baselines: Define baselines for classes such as “corporate IT”, “Level 3 operations servers”, “Level 2/1 control systems”, each mapped to NIST controls, then document justified tailoring inside each class.
- Compensating controls: When a host-level control cannot be implemented on a specific OT asset, use network zoning, access control, or procedural controls, and document the mapping and residual risk.
- Phased adoption: Align control upgrades with planned outages, validation windows, and hardware refresh cycles, rather than forcing uniform controls across all sites at once.
This approach accepts that not all systems will look the same at any given moment, while maintaining a consistent, NIST-aligned intent and roadmap.
Key governance points for different control sets
If you allow different systems to have different NIST control implementations or tailoring, governance becomes critical:
- Traceability: Maintain clear mapping from each system to its baseline, tailoring decisions, and rationale. This is essential for audits and future re-assessments.
- Approval workflow: Ensure deviations from the standard baseline go through defined risk review and authorization, not ad hoc exceptions.
- Impact analysis: For tightly integrated systems, evaluate how a control change on one system (for example, stronger authentication) affects connected MES, QMS, or OT systems.
- Re-use: When you approve a well-justified deviation for one system class (for example, a specific approach for legacy CNC controllers), consider formalizing it as an option in the baseline catalog.
In regulated manufacturing, this governance is often more decisive for audit posture than whether every system has the exact same NIST control list.
Bottom line
RMF does not require all systems to use the same NIST controls. It requires that each system have a risk-appropriate, well-documented, and maintained set of controls that map to a recognized catalog such as NIST SP 800-53. In practice, most organizations standardize baselines by system class and then tailor, especially in brownfield industrial environments where uniform implementation is constrained by legacy assets, validation burden, and downtime risk.
