Cloud migration security now spans more ground than traditional perimeter controls. Identity-based attacks have become a leading breach vector. Stolen credentials, not malware or misconfigured firewalls, are now the leading way attackers get in present in 22% of breaches analysed in the Verizon Data Breach Investigations Report.
Regulatory obligations have also grown more fragmented with different rules applying depending on where data is processed and stored. And AI-assisted attack techniques are reducing the effort required to exploit weak identity controls or exposed configurations. Security built into the migration from the first workload, rather than applied as a post-migration layer is what allows organizations to address these conditions as environments scale.
Cloud migration security is built through planned identity, governance and compliance decisions before the first workload moves.
The shared responsibility model
Cloud security is split between two parties. The cloud provider secures the infrastructure layer with physical data centres, host hardware, network controls and the hypervisor. The customer secures what runs on top of that infrastructure with data, identity and access configurations, operating systems and application code.
This split moves depending on the service model:
- Infrastructure as a Service (IaaS): Customer manages operating system, network configuration, data and identity. Provider manages physical and virtualization layers.
- Platform as a Service (PaaS): Provider adds runtime and middleware management. Customer still owns data, access controls and application logic.
- Software as a Service (SaaS): Provider manages nearly the full stack. Customer retains responsibility for data classification, user access and configuration settings.
Gartner projects that over 99% of cloud security failures will be attributable to customer-side misconfigurations rather than provider infrastructure gaps. This makes the boundary between provider and customer responsibility a critical planning input for every migration.
Here are ten cloud migration security strategies to look out for
1. Migration strategy: The planning phase
Cloud migrations that begin without a documented strategy tend to run into scope, cost or timeline problems mid-project. A migration strategy defines what moves, in what order and how the target environment should look before any workload is touched.
Three inputs shape a workable strategy:
- Application inventory: What exists today, its dependencies and its data sensitivity level.
- Migration pattern: Rehost, replatform, refactor or retire chosen per workload.
- Risk and compliance mapping: Which regulations apply to each dataset before it moves.
Migration programmes that begin without a documented strategy commonly encounter scope, cost or timeline challenges mid-project. These are often traced back to gaps in application inventory, compliance mapping or workload prioritization that were not resolved at the outset.
A strategy document reviewed and updated through the migration, rather than finalized once at kickoff, tends to catch these gaps earlier.
2. Applying zero trust to migrated workloads
Traditional network security assumes anything inside the perimeter can be trusted. Zero Trust removes that assumption. Every access request, from a user, device or application gets verified each time regardless of where it originates.
Three components define the model, as outlined in NIST SP 800-207:
Identity verification happens per session, not once at login. Devices are checked for security posture before granted access. Network segments are divided into smaller zones, so a compromised workload cannot move laterally across the environment.
For migrated workloads specifically, Zero Trust replaces the old VPN-and-firewall boundary with policy enforcement placed close to each resource.
3. Access control gaps behind recent cloud breaches
Identity and Access Management determines who can reach which resource, under what conditions. Recent breach data shows why this control matters more than most others during migration.
According to the Verizon Data Breach Investigations Report, 88% of attacks against basic web applications involved stolen credentials.
Migration introduces new identity and access management (IAM) decisions of which identity provider governs the new environment, whether existing roles carry over unchanged and how service accounts used by applications rather than people get scoped.
Centralizing identity before migration rather than recreating access rules manually in the new environment, which reduces the chance of leftover unused permissions persisting into production.
4. Credential and secrets security in cloud environments
Multi factor authentication (MFA) alone no longer stops every credential-based attack. Attackers now use token theft, MFA-prompt bombing and adversary-in-the-middle interception to bypass it.
Infostealer malware adds another exposure point. The Verizon DBIR found 30% of corporate-managed devices and 46% of unmanaged devices in infostealer logs contained company credentials.
Two controls address this directly:
- Least privilege access, limiting each identity to only what its role requires
- Privileged access management (PAM), which isolates and monitors high-level accounts separately from standard users
Migrated environments should apply both before workloads go live.
5. Encryption requirements for migrated data
Data storage moved to the cloud needs the same access restrictions it had on-premises, plus encryption as a default setting, not an afterthought.
Two checks matter most:
Database and storage buckets should never be publicly readable or writable unless the business function specifically requires it. Data should be encrypted both at rest and in transit, with key management handled separately from the storage layer itself.
A data breach report found that breaches involving data spread across multiple environments of cloud, on-premises and hybrid cost an average of $5.05 million, the highest among all breach types studied.
Incorporating storage permission and encryption review as a defined step in the migration process, rather than a post-migration task addresses this earlier in the programme.
6. Authentication methods for post-migration access
Password-only policies no longer meet the bar for enterprise access, even with complexity rules or regular resets attached. Attackers bypass standard MFA through prompt bombing, token theft and interception techniques.
Phishing-resistant methods close this gap. Passkeys, built on public key cryptography, remove the shared secret an attacker could steal or guess.
Per the FIDO Alliances State of Passkeys report, 68% of surveyed organizations have deployed or are actively deploying passkeys for workforce sign-in.
For migration, this means the identity provider selected for the new environment should support passkeys and phishing-resistant MFA from the start, rather than treating it as a later upgrade.
7. Tracking software components post-migration
A software bill of materials (SBOM) is a structured inventory of every component inside a piece of software including open-source libraries, third-party packages and internal code. It works like an ingredients list, showing exactly what a migrated application depends on.
For migration specifically, an SBOM answers a question inventory spreadsheets often miss, which third-party components are moving along with the application, and whether any carry known vulnerabilities.
Third-party involvement in breaches doubled from 15% to 30% year-over-year. Generating an SBOM before migration, gives visibility into risks from day one.
8. Unified cloud security visibility across migration
Cloud security tooling has historically been fragmented. One tool for cloud security posture management (CSPM), another for cloud workload protection platform (CWPP), a third for cloud infrastructure entitlement management (CIEM). A cloud native application protection platform (CNAPP) brings these into a single platform.
Gartner defines a CNAPP as a unified, tightly integrated set of security and compliance capabilities designed to protect cloud-native infrastructure and applications, spanning development through production.
During migration, this consolidation matters because:
- Misconfigurations get flagged before workloads go live.
- Excess permissions from lift-and-shift environments become visible in one view.
- Risk findings are prioritized instead of scattered across separate dashboards.
9. Continuous monitoring after migration
Manual configuration changes are a leading cause of cloud security gaps, since a single missed step during setup can leave a resource exposed. Automation removes repetitive manual work from the process and applies consistent rules across every deployment.
A continuous security model covers four stages. Monitoring for changes, analySing them against policy, reporting deviations and correcting them automatically. Building automated checks into the migration pipeline, rather than adding them after go-live maintains consistency from the first workload moved and reduces the manual overhead of post-migration remediation
10. Third-party vendor risk during migration
Every migration brings in vendors beyond the primary cloud provider with monitoring tools, backup services, migration partners and integrated SaaS applications. Each one introduces its own access points into the environment.
A vendor risk process for migration typically covers security assessments completed before contract signing, contractual terms defining data handling and incident notification timelines and ongoing monitoring of vendor access rather than a one-time review at kickoff. Vendors with standing access to migrated workloads warrant the same level of scrutiny applied to internal accounts.
Compliance requirements affecting cloud migration
Regulatory scope has widened for cloud workloads. Three frameworks illustrate this shift.
NIS2, in effect across the EU, explicitly brings cloud service providers into scope. Article 21 places supply chain risk assessment obligations directly on regulated entities, extending accountability to the vendors and cloud platforms they depend on.
APRA CPS 230, applies to all material service providers used by Australian financial institutions, not outsourcing arrangements alone. Cloud and SaaS vendors fall under this same standard.
The Texas Data Privacy and Security Act (TDPSA) carries a wider scope than most U.S. state privacy laws, since it applies based on data processing activity
| Framework | Region | Cloud-specific scope |
| NIS2 | EU | Cloud providers and supply chain risk |
| APRA CPS 230 | Australia | All material service providers, including cloud or SaaS |
| TDPSA | U.S. | No revenue threshold and broad applicability |
Building a migration security plan
Cloud migration security now spans identity controls, supply chain visibility and regulatory obligations that vary by region and workload. A connected approach of Zero Trust design, CNAPP-level visibility and compliance mapping built in from the start addresses these as an integrated programme rather than separate workstreams applied at different stages of the migration.
