Why IAM stays off the modernisation roadmap
Legacy modernisation programmes tend to focus on the systems causing the most visible pain – the brittle core platform, the outdated customer interface or the application nobody wants to touch.
Identity infrastructure often escapes the same scrutiny because it still appears to work. Users can log in. Applications remain accessible. The underlying problems stay hidden in duplicated identities, accumulated permissions, manual access processes and ageing authentication components.
They become visible only when the organisation tries to move something.
Identity and access management (IAM) governs how digital identities are created and managed, how users are authenticated and what systems, applications and data they can access. In a legacy estate, these controls often extend across multiple generations of technology, creating dependencies that are difficult to see until applications and infrastructure begin to move.
That is why IAM is not a security workstream to bolt on once the ‘real’ modernisation is underway. It is an architectural dependency that can determine what can move, how the programme must be sequenced and whether the resulting environment is genuinely more secure, resilient and manageable.
How legacy IAM increases modernisation risk and cost
Deferring IAM does not make the underlying complexity disappear. It allows it to surface later, when architecture decisions have been made, migration plans committed and the cost of changing direction is considerably higher.
A legacy application may not support the target identity provider. Users may hold different identities across inter-connected systems. Roles and permissions may be too inconsistent to migrate reliably. Service accounts and automated processes may depend on embedded credentials, while customer authentication data may be impossible to move without disrupting the login experience.
These are not simply security problems. They affect what can move, which systems must continue operating together and how the migration needs to be sequenced. They can create additional integration work, extend periods of dual running and delay the retirement of legacy systems.
There is also a clear security consequence. Verizon’s 2025 Data Breach Investigations Report, covering more than 22,000 incidents and 12,195 confirmed breaches, found that credential abuse was involved in 22% of breaches, making it the leading initial attack vector.
That figure does not measure legacy IAM specifically. It does, however, illustrate the exposure that fragmented identity estates can amplify. Multiple authentication systems, inconsistent access controls and limited visibility over who can access what, make weaknesses harder to identify and manage.
If applications, data and infrastructure are modernised without addressing those weaknesses, the organisation risks rebuilding them in the target environment. The technology may be newer, but the access risk, operational complexity and cost of change remain.
This is part of the wider cost of technical debt. Legacy technology consumes budget not only through infrastructure and maintenance, but through the additional effort required to integrate, secure and change everything around it. We explore that broader calculation in Legacy Software Modernisation. How CTOs Calculate Tech Debt
IAM is an operational resilience dependency
For financial services and government organisations, IAM is not only a security consideration. It is part of the governance and operational resilience of the services they provide.
The FCA and PRA’s operational resilience regime requires in-scope firms to identify their important business services, map the resources and dependencies supporting them and remain within defined impact tolerances. Identity infrastructure may form a critical part of those dependencies, particularly where several applications or services rely on a shared authentication platform.
Where identity services depend on cloud or other third-party platforms, those dependencies must also be understood. The UK’s Critical Third Party regime does not bring a firm’s internal IAM architecture within its regulatory perimeter, but it reinforces the need to understand the resilience, concentration and recovery implications of relying on critical technology providers.
For central government organisations, the Government Cyber Security Policy Handbook identifies identity and access control as a core protective principle. It requires organisations to manage the full identity lifecycle, from provisioning and access review to the timely removal of access when it is no longer needed.
GOV.UK One Login demonstrates the strategic importance of identity as shared infrastructure for citizen-facing services. Although its purpose differs from workforce IAM, it shows why identity increasingly needs to be treated as a core component of modernisation rather than a feature added separately to individual applications.
Signs IAM may already be constraining your modernisation
IAM problems often remain hidden until a programme is committed and applications begin to move. Identity should be reviewed earlier if your estate includes several of the following:
- Multiple authentication systems spanning legacy and modern applications
- Different MFA requirements and exceptions across platforms
- Users maintaining several identities or credentials for related systems
- Manual or unreliable joiner, mover and leaver processes
- Permissions that have accumulated without regular review
- Shared, privileged or service accounts with unclear ownership
- Applications reliant on proprietary, ageing or unsupported authentication methods
- Static credentials or secrets embedded in applications and automated processes
- Incomplete access logs or audit records fragmented across different systems
- Shared directories or identity platforms supporting undocumented application dependencies
- Limited visibility over who, or what, can access critical systems and data
None of these automatically means the organisation needs to replace its entire IAM estate. They do mean that identity dependencies should be understood before the target architecture is finalised and the migration sequence is locked down. Otherwise, IAM constraints are likely to surface later, when resolving them becomes more disruptive and expensive.
What an IAM review needs to establish
If IAM has been deferred, the answer is not to assume that the entire estate needs replacing. The starting point is a structured review that identifies where the risk, complexity and dependencies sit before the organisation commits budget or builds its migration plan around the wrong assumptions.
A modernisation-focused IAM review should establish:
- Who and what has access. The human, customer, partner, privileged, service and machine identities operating across the estate, including shared accounts and credentials with unclear ownership.
- How access is managed. How identities and permissions are created, reviewed, changed and removed and whether access continues to reflect current roles and responsibilities.
- How identity is currently delivered. The directories, authentication methods, identity providers, federation arrangements and application integrations on which access depends.
- Where the weaknesses and constraints sit. Including inconsistent MFA, accumulated permissions, unsupported authentication components, embedded credentials and gaps in logging or traceability.
- What the target architecture requires. Which identity services should be retained, integrated, consolidated or replaced and where legacy and modern environments may need to co-exist during migration.
- How resilient and auditable the model is. Whether identity services can be recovered, access events can be traced and the organisation can demonstrate who or what has access to critical systems and data.
Catapult CX’s Identity & Access Management Review assesses these controls, technologies and dependencies in the context of the wider modernisation programme. It shows what can remain, what needs to change and where IAM work must sit within the migration roadmap, without assuming that systems still performing a useful role need to be replaced.
Case in point. Migrating identity without disrupting customers
Identity modernisation becomes particularly difficult when changing the underlying architecture could disrupt thousands of existing users. Catapult CX encountered exactly that challenge at Aldermore Bank.
When the bank replaced its legacy Business Savings front end and moved its identity infrastructure to Auth0, the technical migration had to be effectively invisible to existing customers. Its legacy authentication module did not support the modern identity standards required by the new architecture, while many customers had multiple logins connected to the same email address. A conventional like-for-like migration was therefore not possible.
Catapult CX designed a bespoke solution. User records were made available through a dedicated API. A custom Auth0 database used that API for login and password reset, while custom actions managed MFA enrolment and role assignment without interrupting the customer experience.
The result was the successful migration of 59,400 customers and 83,500 user profiles, with 100% of users retaining their existing credentials and MFA factors throughout.
Read the full Aldermore Auth0 migration case study.
The wider lesson is not about Auth0 alone. Legacy authentication constraints can be solved through the right combination of architecture, integration and migration engineering. They are a reason to bring identity into the modernisation programme early, not to leave it out of scope.
Sequencing IAM into your modernisation roadmap
The answer is not to fix every IAM issue before modernisation can begin. It is to understand the identity estate early enough for those findings to shape the architecture, priorities and migration sequence.
That means bringing IAM into the programme from the outset:
- Assess the current identity estate. Map identities, permissions, authentication methods, directories, integrations and third-party dependencies alongside the wider application and infrastructure estate.
- Identify the constraints and priorities. Establish which weaknesses create an immediate security or resilience risk, which could prevent applications from moving and which can be addressed later.
- Shape the target architecture. Decide which identity services should be retained, integrated, consolidated or replaced, including how legacy and modern environments will operate together during the transition.
- Build IAM into the migration sequence. Determine which applications can move immediately, which require remediation and which depend on wider changes to identity infrastructure.
- Design governance and traceability into the target state. Define ownership, access reviews, privileged access, lifecycle controls, logging and recovery requirements before migration begins, not after an audit exposes the gaps.
This reflects Catapult CX’s broader approach to legacy modernisation – diagnose the dependencies, prioritise what needs to change and modernise in a sequence that reduces delivery risk.
Identity infrastructure is rarely the most visible problem in a legacy estate. But if it is left out of the plan, it can make everything else harder, slower and riskier than it needs to be.
Find the identity risks before they block modernisation
Catapult CX’s Identity & Access Management Review identifies the dependencies and weaknesses within your current estate and shows what needs to change before they disrupt your modernisation programme.
FAQs
What is identity and access management?
Identity and access management (IAM) is the combination of processes, policies and technologies used to manage digital identities, authenticate users and control access to systems, applications and data. It covers the full identity lifecycle, including how access is granted, reviewed, changed and removed.
What does an IAM review cover?
An IAM review assesses how human, customer, partner, privileged, service and machine identities are managed across an organisation. It typically examines identity lifecycles, authentication methods, permissions, privileged access, directories, application integrations, MFA, logging, governance and resilience. It should also identify which identity services can be retained, integrated, consolidated or replaced.
Why does IAM matter in legacy modernisation?
Identity services often connect multiple applications, platforms and generations of technology. If those dependencies are not understood before modernisation begins, they can restrict what can move, complicate integrations, disrupt users and carry existing access weaknesses into the target environment.
When should an IAM review take place?
An IAM review should take place during the early discovery and dependency-mapping stages of a modernisation programme, before the target architecture and migration sequence are finalised. It can also be undertaken later if identity problems have already emerged, although the options may then be more constrained and expensive.
Why does IAM get deprioritised in modernisation programmes?
IAM often continues functioning well enough that it does not appear as urgent as a failing core system or outdated application. Its weaknesses tend to remain hidden until an organisation attempts to migrate an application, consolidate platforms, introduce stronger access controls or demonstrate compliance.
Does modernising IAM require replacing the entire legacy estate?
No. Depending on the existing architecture, identity services can often be integrated with or layered over systems that still perform a useful role. Catapult CX’s Aldermore migration, for example, introduced Auth0 while retaining the existing application database and allowing customers to keep their credentials and MFA factors.
Can IAM modernisation happen alongside a wider migration?
Yes. In most cases, IAM should be planned alongside the wider modernisation rather than completed as a separate programme beforehand. The review establishes which identity changes are prerequisites for migration, which can happen in parallel and which can be addressed later.
Which UK requirements and standards apply to IAM?
The requirements depend on the organisation and sector. In-scope financial services firms must consider identity infrastructure when mapping the technology and third-party dependencies supporting important business services under the FCA and PRA operational resilience regime. For central government organisations, the Government Cyber Security Policy Handbook identifies identity and access control as a core protective principle, including effective provisioning, access review and timely removal. Other legal, regulatory and contractual requirements may also apply depending on the systems and data involved.
