The greatest security risk in a cloud migration may not be the target environment. It may be the transition – the period when applications, data, identities and controls are divided between old and new environments.
For regulated organisations, this transitional state needs to be designed and governed as carefully as the destination itself.
Zero Trust provides a practical framework for doing that. Rather than assuming a workload, user, service or connection should remain trusted because it was trusted before migration, each migration wave requires the programme to establish:
- Who or what needs access
- Why that access is required
- How it will be authenticated and authorised
- What evidence will demonstrate that the controls are working
Applied in this way, Zero Trust becomes more than a security architecture. It becomes part of how the migration is sequenced, governed and delivered.
- Our guide to Zero Trust Security explains the underlying principles and what a Zero Trust architecture requires.
This article addresses a different question – how should Zero Trust principles be applied during a live cloud migration?
Why cloud migration security can fail during the transition
During migration, some services may remain on-premises while others operate in the cloud. Identities may work across both environments, applications may rely on dependencies that have not yet moved and temporary administrator privileges may be introduced to complete migration work. Monitoring may also be divided between environments. Together, these conditions can weaken controls that worked effectively before migration.
The National Cyber Security Centre recommends understanding users, devices, services and data before implementing Zero Trust. It also advises organisations to retain existing controls where Zero Trust controls cannot yet mitigate all identified risks.
Cloud migration security must therefore address three states:
- The controls operating before migration.
- The controls protecting the organisation while old and new environments co-exist.
- The controls that must be operating and evidenced before the old environment can be safely decommissioned.
Zero Trust gives migration teams a framework for making these decisions explicitly, rather than assuming that security controls will catch up after cutover.
Zero Trust should influence what moves first
Migration programmes are often sequenced according to technical complexity, infrastructure dependencies, contracts, data centre plans and delivery deadlines. These considerations matter, but they do not show whether a workload can move without weakening control.
A regulated migration must also consider how access, dependencies and trust relationships will change as each component moves. The NCSC recommends understanding users, devices, services, applications, data flows and architectural dependencies before implementing Zero Trust Network Access. It also recommends updating the threat model to identify where existing mitigations may change or new risks may emerge.
This changes the sequencing question from; Which application can we move next? to; What must be ready before this application can move without weakening control?
An application may depend on a legacy identity service. A workload may rely on monitoring that has not yet been reproduced in the cloud. A service may require temporary connectivity to the on-premises environment, introducing a new trust path during transition.
In each case, the workload may be technically ready to move while the controls needed to operate it safely are not. Migration sequencing should reflect both.
Apply Zero Trust through Assess. Map. Move.
Catapult CX’s migration approach is built around three stages, Assess. Map. Move. This provides a practical structure for applying Zero Trust principles as part of the migration, without turning it into a separate security transformation programme.
Zero Trust does not replace the wider controls required for data integrity, resilience, recovery and operational readiness. It provides an additional lens through which access, identity and trust can be assessed at each stage.
Assess. Understand where trust exists today
Begin with the current architecture before designing the target environment.
Identify the users, service identities, applications, devices, data, integrations and dependencies involved. Establish which controls protect them and whether those controls are explicit or simply consequences of the existing architecture.
For example, an application may appear well protected because only a limited number of people can reach the network on which it sits. Once the application moves to the cloud, that implicit protection may disappear.
NIST’s Zero Trust Architecture guidance states that trust should not be granted solely because of network location or asset ownership. Each access request should be explicitly authenticated and authorised against defined policy.
The assessment must therefore establish not only what exists, but where the organisation currently relies on implicit trust. This gives the migration programme a baseline from which to identify what must change.
Map. Define the controls before the workload moves
Once the architecture and dependencies are understood, define the controls required in the target environment and during the transition.
Identity and access are central to this stage. NCSC cloud guidance confirms that access control remains the customer’s responsibility and recommends understanding identity and access requirements before migration. Addressing them early also makes it easier to adopt controls such as multi-factor authentication and Zero Trust access mechanisms.
For each migration wave, the programme should define:
| Question | What the programme needs to establish |
|---|---|
| Who or what needs access? | Users, administrators, service identities, devices and integrations |
| What do they need access to? | Specific applications, services, APIs and data |
| Why is access required? | Business role, application dependency or migration activity |
| How will access be verified? | Identity, device or service health, authentication and access policy |
| How much access is required? | The minimum privilege required for the task or resource |
| How will data be protected? | Classification, encryption, key ownership, integrity and residency requirements |
| What is temporary? | Migration accounts, elevated privileges, credentials and transitional network routes |
| How will activity be evidenced? | Logging, monitoring, access records, configuration changes and policy history |
| What happens if a control fails? | Fallback, recovery, rollback and incident-response arrangements |
| How will exceptions be governed? | Named ownership, compensating controls, review dates and removal conditions |
This turns Zero Trust principles into clear migration acceptance criteria. These controls should sit alongside the functional, operational, data and resilience criteria for each migration wave, rather than being checked through a separate security review at the end.
A workload is not ready to move simply because it can run in the cloud. The controls required to operate it safely must be ready as well.
Move. Migrate, verify and remove temporary trust
Cloud migrations should progress in controlled waves wherever possible. This allows issues to be identified and corrected before they affect more of the estate. NCSC guidance also recommends maintaining an inventory, identifying security boundaries and simplifying permissions during migration planning.
Each migration wave should test control as well as functionality:
- Can authorised users and services access what they need?
- Are unauthorised users and services prevented from accessing it?
- Are service identities, API keys and other credentials restricted appropriately?
- Are privileged and break-glass access arrangements working as intended?
- Are logs reaching the operational monitoring environment?
- Can access and configuration decisions be reconstructed afterwards?
- Can the workload be recovered or rolled back safely?
- Have migration-only accounts, privileges and network routes been removed?
- Are any remaining exceptions documented and owned?
This evidence is particularly important in regulated environments. NCSC cloud guidance recommends retaining audit information that enables organisations to establish how and when security events occurred and investigate access, configuration changes and resource activity.
A migration wave is not complete from a governance perspective until the organisation can demonstrate how access is controlled, confirm that temporary trust has been removed or explicitly governed and produce the evidence needed to support those conclusions.
Do not force every legacy system into the same model
Requiring every application to reach the same Zero Trust end state before migration begins can make the programme unnecessarily complex or prevent some workloads from moving at all.
Legacy applications may not support modern authentication or secure protocols. Others may depend on architectures that cannot be redesigned within the scope, budget or timescale of the immediate migration.
The NCSC recognises this through its guidance on mixed estates, where systems that implement Zero Trust principles operate alongside conventional systems that cannot support them directly.
The answer is not to treat those systems as trusted by default or to delay the entire migration until they have been modernised. It is to govern each one as an explicit exception.
For every exception, the programme should establish:
- Why the system cannot meet the target control model
- What additional or compensating controls are required
- How its access and connectivity will be restricted
- How activity will be monitored and evidenced
- Who owns and has accepted the associated risk
- Whether the exception is temporary or expected to remain
- When it will be reviewed, removed or addressed through later modernisation
Migration deadlines do not remove the risk created by a legacy system. They make it more important that the risk is visible, controlled and owned.
A controlled exception is a governance decision. An undocumented exception is a future problem.
Five control gates for each migration wave
The requirements identified through the Assess, Map and Move stages can be converted into five control gates for each migration wave.
These give programme, technology, security and risk leaders a shared basis for deciding whether a workload is ready to proceed.
| Control gate | Key question | Exit condition |
|---|---|---|
| 1. Current architecture understood | Do we understand the workload, its users, identities, data, dependencies, security boundaries and current controls? | The architecture, dependencies and existing trust relationships are documented sufficiently to support a migration decision. |
| 2. Target controls defined | What controls must operate in the target environment? | Identity, access, data protection, monitoring and operational requirements are agreed, with clear ownership. |
| 3. Transitional controls agreed | What temporary access, connectivity, privilege or other control is required while the old and new environments co-exist? | Each temporary control has a defined purpose, owner, review point and removal condition. Recovery and rollback arrangements are also agreed. |
| 4. Evidence verified before cutover | Can the organisation demonstrate that the required controls are operating? | Access, logging, monitoring, data integrity and recovery arrangements have been tested before the workload becomes dependent on the target environment. |
| 5. Temporary trust removed | What access, connectivity or privilege is no longer required once the migration wave is stable? | Migration accounts, elevated permissions, credentials and temporary network paths have been removed. Anything that remains is documented and governed as an exception. |
These gates turn security and governance requirements into measurable programme decisions. They reduce the risk of discovering after migration that an important control depended on an architectural assumption that no longer applies.
Cloud providers do not remove responsibility for control
Cloud providers can offer mature security capabilities and secure default configurations. Organisations remain responsible for how their services are configured, accessed and governed.
NCSC guidance is clear that cloud customers retain responsibility for configuring the services they use. During migration, this includes understanding the organisation’s access model, dependencies, security boundaries and the controls it must operate itself.
The same principle applies to third-party resilience. On 13 July 2026, designation regulations came into force for the first four Critical Third Parties – Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited. Regulatory oversight applies to their systemic services; it does not transfer responsibility away from financial services firms. Firms remain accountable for managing their third-party risks, operational resilience and outsourcing obligations under the UK Critical Third Party regime.
- We examine the wider implications in our article on the UK Critical Third Party regime and cloud concentration risk.
The migration implication is straightforward. Infrastructure can be outsourced, but accountability for understanding and controlling its use cannot.
Zero Trust provides an additional lens for making those decisions. Alongside questions about what should move, change or be retired, the programme should ask; what trust are we removing, retaining or introducing as this workload moves?
The answer may change the migration sequence. Moving an identity platform earlier could simplify the waves that follow. Establishing central logging before business applications move could provide evidence across the programme. Removing an obsolete integration may be safer than recreating its privileged access in the cloud.
In some cases, leaving a poorly understood application where it is will be safer than migrating it with broad temporary permissions simply to meet a programme date.
This allows security requirements to inform the route through the migration, rather than being assessed only when a workload is ready for cutover.
What good looks like after migration
A successful regulated cloud migration should leave the organisation with stronger, more visible control, not simply more of its technology running in the cloud.
Users, services and devices should have clearly defined identities.
- Access should be narrower and easier to explain
- Standing privileges should be reduced
- Important activity and configuration changes should be visible through operational monitoring
- Temporary accounts, credentials and network routes should have been removed
- Any remaining legacy dependencies or exceptions should be documented, owned and regularly reviewed
A programme can finish on time and still leave fragmented identities, excessive permissions, undocumented dependencies and insufficient audit evidence. In that situation, the systems have moved, but the organisation’s control has not materially improved.
Zero Trust principles help prevent this by making control readiness part of migration sequencing, acceptance and completion, not a review conducted after the move.
Catapult CX’s migration service helps organisations assess their current estate, map the dependencies and controls required for each migration wave and move services in controlled stages. The objective is not simply to complete the migration, but to arrive with clearer access, stronger evidence and fewer inherited risks.
If your programme is moving infrastructure, applications or data to the cloud, the critical question is not simply whether the move is technically possible? It is whether you can make the move without losing control on the way?
Frequently Asked Questions
What is cloud migration security?
Cloud migration security is the process of protecting applications, data, identities, infrastructure and access as systems move from one environment to another. It covers the target cloud environment and the transitional period when old and new systems operate together.
Effective cloud migration security also considers temporary connectivity, migration accounts, elevated privileges, data integrity, monitoring, recovery and the removal of access that is no longer required.
Why is the transition a significant cloud migration security risk?
During migration, identities, applications, data and controls may be divided between on-premises and cloud environments. Services may depend on systems that have not yet moved, while temporary access and network routes may be introduced to keep them operating.
These conditions can create new trust relationships or weaken controls that worked in the original environment. The risk must therefore be assessed for each migration wave, not only for the final cloud architecture.
How does Zero Trust improve cloud migration security?
Zero Trust removes implicit assumptions of trust based on network location, asset ownership or previous access. Users, devices, workloads and services must be explicitly authenticated and authorised according to defined policies.
During migration, this helps organisations identify changing trust relationships, apply least privilege, control temporary access and verify that the required controls are operating before a workload moves.
Should Zero Trust be implemented before cloud migration?
A complete enterprise-wide Zero Trust transformation is not necessarily required before cloud migration begins. However, Zero Trust principles should inform planning before the first workloads move.
Understanding identities, applications, data flows, dependencies and security boundaries early allows the organisation to determine which controls must be in place for each migration wave and which legacy arrangements will require additional protection.
Can legacy applications be included in a migration using Zero Trust principles?
Yes. Some legacy applications cannot support modern authentication, secure protocols or policy-based access directly. NCSC guidance recognises that these systems may need to operate within a mixed estate alongside services that support Zero Trust principles.
They should be treated as explicit exceptions, with restricted connectivity, compensating controls, active monitoring and named risk ownership. The organisation should also define whether the exception is temporary or will remain until the application is modernised or retired.
What controls should be verified before a workload moves?
The precise requirements will depend on the workload and its risks, but the organisation should normally verify:
- Authentication and authorisation
- Least-privilege access
- Service and workload identities
- Data protection and integrity
- Logging and operational monitoring
- Privileged and emergency access
- Recovery and rollback arrangements
- Ownership of any exceptions
Migration-specific accounts, permissions, credentials and network routes should also have defined removal conditions.
Does Zero Trust slow down cloud migration?
It may identify dependencies or control gaps that change the planned sequence, but addressing those issues before migration is usually less disruptive than discovering them after cutover.
By defining access, evidence and acceptance criteria early, Zero Trust can reduce late security reviews, unclear responsibilities and remediation work after workloads have moved.
Does moving to a major cloud provider transfer responsibility for security?
No. Cloud providers are responsible for defined parts of the underlying service, while customers remain responsible for how they configure, access and use their cloud environments. The division of responsibility varies according to the service and deployment model.
Regulated financial services firms also remain accountable for their operational resilience, outsourcing arrangements and third-party risks, including where a provider is subject to oversight under the UK Critical Third Party regime.
