They should do it before vendor selection, because the right product depends on the control model it must support. If governance comes second, teams tend to optimise for migration speed and end up rebuilding the same limitations on a different stack.
Why governance redesign comes before platform selection
Manufacturing firms should treat this as a control-model decision, not a software buying decision. If the approval flow, segregation of duties, exceptions process, and ownership model are unclear, migration simply moves the same ambiguity into a new tool. The practical question is what the platform must enforce, who owns those decisions, and where manual overrides are acceptable.
A governance-first approach also prevents teams from overfitting to a vendor demo. The strongest product on paper may still be the wrong fit if it cannot support plant-level delegation, batch access reviews, contractor access, or the exception handling needed for production systems.
For manufacturers with multiple sites or mixed IT and OT environments, governance should define the boundary between standard policy and local operational reality before any shortlist is built. That is the point at which platform requirements become measurable instead of aspirational.
What changes when migration follows governance redesign
When governance is redesigned first, migration becomes a translation exercise rather than a redesign in disguise. The organisation can map roles, approval paths, access reviews, and ownership lines onto the target state instead of discovering them after implementation. That usually shortens decision cycles during vendor selection because the evaluation criteria are already explicit.
This sequence also improves control consistency across plants, business units, and third parties. A platform can automate workflow, but it cannot decide whether a maintenance contractor should be treated like a temporary internal user, whether emergency access needs dual approval, or whether plant supervisors can approve exceptions within a bounded policy.
IGA Buyer's Guide is useful here because the buying process only works when lifecycle, requests, reviews, roles, and connector requirements are already defined well enough to test against real operating conditions.
How to recognise the right trigger for redesign before migration
The trigger is usually not technical failure alone, it is governance friction. If teams cannot explain who approves access, how exceptions are tracked, how role changes propagate, or how periodic reviews are evidenced, the organisation has a policy design problem that no migration will fix.
This becomes especially visible when legacy processes rely on email, spreadsheets, or informal approvals to keep production running. Those shortcuts may be tolerated during a transition, but they should be treated as signals that the operating model needs redesign before the platform choice is locked in.
For operational technology and plant environments, the distinction matters because access often spans safety, maintenance, engineering, and supplier support. A platform can enforce workflow, but it cannot repair a control model that has never separated permanent entitlement from temporary operational exception.
Risk and Threat Considerations
When governance is deferred until after vendor selection, firms tend to inherit technical debt in the control layer. That increases the likelihood of inconsistent approvals, weak segregation of duties, and access creep across plants and systems, especially where migration pressure encourages rapid lift-and-shift decisions.
Failure mechanism: Teams optimise for speed, then force the new platform to preserve legacy exceptions, manual workarounds, and unclear ownership. Over time, the platform automates the old weaknesses instead of replacing them.
Impact: The result is brittle governance, harder audit evidence, and a larger chance that privileged or operational access remains broader than intended. In manufacturing environments, that can also create cross-site inconsistency and slower containment when access must be revoked quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Account and access governance drive the control model that should be defined before platform migration. |
| Recommendation — Define account ownership, approval, review, and revocation rules before selecting a migration platform. | ||
| NIST CSF 2.0 | GV.PO-01 — Policy, roles, and responsibilities are established, communicated, and coordinated | The question is about redesigning governance before tooling, which is a policy and responsibility issue. |
| Recommendation — Establish policy roles and responsibilities before choosing the platform that will enforce them. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control design must be settled before migration so the platform can enforce the intended model. |
| Recommendation — Define access control rules before selecting a migration solution. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Manufacturing access models often include non-human access that can become overprivileged during rushed migrations. |
| Recommendation — Review non-human access entitlements before migration to avoid carrying over excess privilege. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the core control principle behind redesigning governance before tool selection. |
| Recommendation — Set least-privilege access rules before choosing a migration platform. | ||
Practitioner Guidance
What to prioritise: Define the control model first, then write the platform requirements from that model. The most important early outputs are role ownership, approval boundaries, exception rules, and review cadence, because those determine whether a tool can actually support the operating model.
What to verify: Before vendor selection, confirm that the target state can handle plant-level delegation, emergency access, contractor lifecycle, and access recertification without forcing custom workarounds. If those scenarios cannot be tested clearly, the requirements are still too vague.
Practitioner takeaway: If governance is unclear, migration does not remove complexity, it relocates it. The better sequence is to decide how access should be controlled, evidenced, and challenged first, then buy the platform that can enforce that model at scale.
Related resources from NHI Mgmt Group
- When should firms prioritise AI control plane governance over broader platform rollout?
- Should organisations prioritise external exposure or internal credential governance first?
- When should teams prioritise API platform migration over adding new features?
- When should organisations prioritise governance over speed in GenAI platform design?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org