Cloud migration security: what actually changes when the perimeter moves

Most enterprise security models were built around a simple assumption: there is an inside and an outside, and a firewall between the two. Cloud migration security is the discipline of accepting that this assumption is gone and rebuilding the controls that depended on it. The workloads that move are usually well understood. What changes is everything around them: who is responsible for what, what counts as a perimeter, where credentials live, and what you can see when something goes wrong. This article walks through those changes in the order they tend to hurt.

Shared responsibility, as it is usually misread

Every cloud provider publishes a shared responsibility model, and every migration team nods at it. The provider secures the physical data centers, the hypervisors, the managed service internals. The customer secures what runs on top: operating systems on IaaS, application code, data classification, and, in every service model, identity and access configuration.

The misreading is subtle. Teams hear "the provider handles security" and quietly extend that to areas the provider never claimed. AWS will keep the S3 service itself patched and available. AWS will not stop you from making a bucket public, attaching an administrator policy to a build role, or leaving a database snapshot shared with the world. Those are configuration decisions, and configuration is on your side of the line in every service model, including SaaS.

The practical consequence: migrating to the cloud transfers a set of responsibilities you used to hold (hardware, physical access, hypervisor patching) and leaves you with a set you may never have held explicitly before. On-premise, network segmentation often compensated for loose internal permissions. A misconfigured service behind three layers of firewall was a finding in an audit report. The same misconfiguration on a cloud endpoint is reachable from any coffee shop on the planet. The responsibility did not grow. The blast radius of getting it wrong did.

A useful exercise before any workload moves: write down, per service you plan to consume, which controls the provider operates and which ones your team must configure and monitor. The document is usually two pages. The gaps it reveals are usually the migration's real security backlog.

Identity is the perimeter now

On-premise, the network was the primary control. Being inside the corporate network implied a level of trust, and most internal services were built on that implication. In the cloud, network location means very little. Your workloads, your administrators, your CI pipelines and your SaaS integrations all reach the control plane over the public internet, authenticated by credentials. Whoever holds the credential is inside.

That makes identity and access management the load-bearing control of the entire environment. It deserves the same design rigor that network architecture used to get, and it rarely receives it during a migration, because IAM decisions look like administrative details next to the visible work of moving servers.

Three IAM decisions matter more than the rest during a migration:

Human access through federation, with no standing credentials. Long-lived access keys for engineers are the cloud equivalent of shared root passwords. Federate access through your identity provider, enforce MFA at the point of federation, and issue short-lived sessions. If your organization runs its own identity layer, an open-source IAM server such as Keycloak can broker access to cloud consoles and APIs through OIDC or SAML, which keeps the identity source under your control and gives you one audit trail for who accessed what.

Machine identity with the least privilege the workload can tolerate. Service roles accumulate permissions the way attics accumulate boxes: each addition is reasonable, and the total is indefensible. A role that can read one bucket becomes a role that can read all buckets because someone was debugging on a Friday. Cloud providers now ship access analyzers that compare granted permissions against permissions used over a trailing window. Run them from day one, and treat the delta as a defect count.

A deliberate account and subscription structure. Accounts, projects and subscriptions are the strongest isolation boundary the platforms offer. Landing everything in one account because the migration was rushed is the cloud version of the flat internal network, and it is expensive to unwind after the fact. Separate production from everything else at the account level before the first production workload arrives.

None of this is exotic. All of it is the kind of work that gets deferred when a migration deadline is close, and it is the work attackers count on.

Secrets and keys move from the closet to the street

Every legacy estate holds credentials in places that were tolerable behind a firewall: connection strings in configuration files, API keys in environment variables checked into internal repositories, certificates on a share that three people remember. On-premise, those were weaknesses buffered by the network. During and after a migration, the same patterns become direct exposure, because the systems that read those secrets are now reachable, and the repositories that hold them are now cloned to laptops and CI runners far outside the old walls.

The fix is structural rather than heroic. Stand up a central secrets manager (the cloud provider's own, or a dedicated tool such as Vault) before workloads migrate, and make it the only sanctioned path. Applications fetch secrets at runtime through their machine identity. Nothing static ships inside an image, a template or a repository. Rotation is automated, because a rotation process that requires a human calendar entry is a process that stops the first busy quarter.

Encryption keys deserve one specific migration decision: who holds them. Provider-managed keys are operationally simple and adequate for most workloads. Customer-managed keys add auditability of every key use and the ability to revoke access to your own data unilaterally. For European organizations with data residency or sovereignty requirements, key custody is often the concrete mechanism behind the compliance statement, and it is far easier to decide before the data moves than to re-encrypt an estate afterwards.

Misconfiguration is the incident you will have

Industry reporting has been consistent on this for years: the large majority of cloud security incidents trace back to customer misconfiguration rather than provider failure or sophisticated attack. Gartner has put it bluntly in its cloud security research, projecting that through 2027, 99 percent of cloud security failures will be the customer's fault, and misconfiguration is the dominant mechanism. Public buckets, permissive security groups, disabled encryption, dashboards exposed without authentication: these are the entries that fill breach post-mortems.

Migration is the peak window for this class of failure. Teams are provisioning unfamiliar services under time pressure, copying examples from documentation and forums, and standing up temporary infrastructure that has a way of becoming permanent. A "temporary" wide-open security group created to unblock a cutover weekend has a measurable chance of still being there a year later.

The countermeasure that works is making the secure path the default path, in code:

• Provision through infrastructure as code only, and review it like application code. A Terraform diff that opens a port to the internet is visible in review. A console click is not.
• Policy as code at the organization level. Every major platform supports preventive guardrails (service control policies, Azure Policy, organization policy constraints) that make whole classes of misconfiguration impossible rather than detectable: no public buckets, no unencrypted volumes, no resources outside approved regions.
• Continuous posture scanning against a benchmark such as the CIS Foundations for your platform, with findings routed to the owning team rather than to a security mailbox nobody reads.
• Drift detection, because the environment that was compliant at cutover is a different environment six months later.

The pattern across all four: audits performed quarterly find misconfigurations after they have been exposed for a quarter. Controls encoded in the pipeline find them before deployment. During a migration, when change volume is at its highest, that difference is the whole game.

Visibility through the hybrid phase

Almost no enterprise migration is a single cutover. There is a period, often measured in years, when workloads run on both sides: the ERP still on-premise, the customer-facing services in the cloud, an identity system straddling the two, and network links binding it together. From a security standpoint, this hybrid phase is the most exposed period of the entire program, for a reason that has little to do with any single system: visibility fragments.

The on-premise estate logs to the existing SIEM. The cloud estate emits control plane logs, flow logs and service logs in formats the on-premise tooling does not natively understand. In between sits the interesting attack surface: the VPN or interconnect, the federated trust between directories, the service accounts that were granted cloud permissions so a legacy batch job could reach a cloud API. An attacker who lands in either environment will probe the seam, because the seam is where monitoring is weakest and where a foothold in the old world converts into credentials for the new one.

Three practices keep the hybrid phase observable:

Turn on the control plane audit trail everywhere, first. CloudTrail, Azure Activity Logs and their equivalents are the flight recorder of the cloud environment. They should be enabled organization-wide, immutable, and shipped to storage the workload accounts cannot alter, before the first production workload lands. Incident response in an account without an audit trail is archaeology without artifacts.

Merge the views before you need them merged. Whether the answer is forwarding cloud logs into the existing SIEM or adopting a platform that ingests both sides, the requirement is one place where an analyst can follow an identity from the on-premise directory, across the federation boundary, into a cloud session. If tracing that path takes three tools and two teams, it will not happen during an incident.

Monitor the bridges as first-class assets. The interconnect, the directory synchronization, the shared service accounts: inventory them, alert on changes to them, and review their permissions on a schedule. They are temporary by intention and durable in practice, and they are the components neither the legacy team nor the cloud team fully owns.

The hybrid phase also deserves honesty in planning. Every quarter it extends is a quarter of doubled attack surface and split operational attention. Security is one of the stronger arguments for finishing migrations rather than letting them plateau at 70 percent.

What this means for a migration plan

The changes above share a shape. In each case, a control that used to be implicit in the network (trust, secrecy, containment, visibility) has to be rebuilt as an explicit, configured, monitored control in the cloud. The migrations that go well treat that rebuilding as scope, with the same planning weight as the workload moves themselves. The ones that go badly treat security as a hardening pass scheduled after cutover, which in practice means an audit finding list discovered by someone else.

A workable sequence: define the account structure and IAM model before the first workload, stand up secrets management and the audit trail in the same phase, encode guardrails as policy before teams get provisioning access, and keep logging unified across both environments for as long as the hybrid phase lasts. None of these items require large budgets. All of them are cheap early and expensive late.

Where DNA Solutions fits

DNA Solutions plans and executes cloud migrations for European enterprises with this security model built into the sequence: account and IAM architecture, federated identity (including self-hosted Keycloak where identity must stay under your control), secrets management, policy guardrails and hybrid-phase logging. If your migration is underway and the security workstream is behind the workload workstream, that gap is recoverable, and it is easier to close now than after cutover. Talk to us.