They should usually standardise access first, because manufacturing estates rarely change all at once. Bridging old and new systems with consistent authentication reduces friction immediately while the broader platform modernisation programme continues in phases.
Why standardising access usually comes first
When estates are heterogeneous, access standardisation is the fastest way to reduce operational friction without waiting for a full replacement programme. A consistent authentication and access pattern lets teams apply one way of proving who or what is allowed in, even while legacy platforms remain in place. That gives you immediate control over a mixed environment and avoids forcing every old system to be modern before it becomes governable.
It also creates a cleaner migration path. If access rules, authentication flows, and account handling are aligned first, replacement work can focus on the application or platform itself rather than repeatedly solving the same login and privilege problems in each project.
What replacement should wait for, and what should not
legacy system replacement is usually the larger strategic fix, but it is slower, costlier, and more disruptive than access standardisation. If you try to replace everything before fixing access consistency, you can end up carrying the same fragmented identity patterns into the new stack. That often preserves hidden risk instead of removing it.
The practical test is whether the legacy system can be safely bridged. If it can, standardise the access layer first and migrate in phases. If a legacy platform cannot support the minimum authentication or segregation required for safe operation, replacement rises in priority because the access problem has become an exposure problem.
How to sequence both workstreams without stalling either
The best sequence is usually to treat standardised access as the control plane and replacement as the target state. Teams can introduce consistent authentication, account handling, and access review across the estate while separately planning system retirement by business criticality, technical dependency, and change window.
- Start with the systems that have the broadest business reach or the highest privilege exposure.
- Standardise access to reduce variance across old and new systems.
- Replace the systems whose technical limits prevent safe access governance or isolation.
- Use each migration to remove one more exception from the access model.
That sequence keeps progress visible. It also prevents the common failure mode where modernisation is delayed until the hardest legacy dependency is solved, while access remains inconsistent for years.
Risk and Threat Considerations
Mixed estates become risky when different systems enforce different login rules, account lifecycles, or privilege assumptions. In practice, attackers and insiders alike benefit from the weakest path, so inconsistent access standards can turn a migration programme into a patchwork of exposure.
Failure mechanism: Legacy platforms often persist with shared accounts, weak authentication, poor revocation, or exceptional access paths. If teams defer standardisation, those weaknesses remain in active use and can undercut newer controls elsewhere in the environment.
Impact: The organisation keeps carrying avoidable access risk during the entire replacement programme, and compromise of one old system can become a route into newer ones if trust and authentication are not normalised first.
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 CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Consistent user authentication is central to standardising access across mixed estates. |
| IA-5 — Authenticator Management | The question hinges on harmonising credential handling while old and new systems coexist. | |
| Recommendation — Standardise organisational user authentication before migrating systems. Unify authenticator lifecycle handling across legacy and modern systems. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access standardisation is an access-control governance decision across the estate. |
| A.8.5 — Secure authentication | Authentication consistency is the immediate control lever when bridging old and new platforms. | |
| Recommendation — Define one access-control model that legacy and replacement systems must follow. Apply consistent authentication requirements before platform retirement. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account consistency and revocation are key to standardising access during phased replacement. |
| Recommendation — Rationalise account management across both legacy and replacement estates. | ||
Practitioner Guidance
What to prioritise: Prioritise the access patterns that are shared across the estate, not the most visible application refresh. A single standard for authentication and account handling usually delivers more immediate risk reduction than a piecemeal replacement schedule.
Decision rule: If a legacy system can be placed behind a consistent access layer without breaking operations, standardise first. If it cannot support safe isolation, revocation, or authentication at all, treat replacement as the earlier control requirement.
Practitioner takeaway: The right order is usually to make old and new systems obey the same access rules first, then retire the legacy exceptions one by one.
Related resources from NHI Mgmt Group
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?