Keeping your cloud environments secure during a merger or acquisition

Keeping Your Cloud Environments Secure During a Merger or Acquisition

Speakers: Isaac Lepow

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=RiSBcFYUiCg

Overview

Isaac Lepow delivered a practitioner-focused walkthrough of the cloud security pitfalls that emerge during mergers and acquisitions, drawing from direct experience with three acquisitions at a previous role. The talk covers specific operational landmines in AWS and GCP organization-level services that can silently break access, disrupt security monitoring, or create unmonitored access paths during account migration. Lepow also addresses the broader organizational dependencies — SSO providers, CI/CD pipelines, log management systems — that create a web of interconnected risks when two cloud environments are merged.

Background

▶ Watch: IAM Identity Center: one instance per org, one identity source per org (2:00)

When a company acquires another company's cloud environment, the resources within individual AWS accounts or GCP projects largely continue to function. EC2 instances keep running, Lambda functions keep executing, S3 data remains stored. The problems arise at the organization level — the services, policies, and integrations that operate across accounts and projects rather than within them. These organization-level complications are mentioned in vendor documentation if you know exactly where to look, but they are easy to overlook if you are approaching your first cloud migration during an acquisition.

The talk is scoped to AWS and GCP (where Lepow has the most experience) and focuses specifically on the organizational and cross-account services that require special handling. It deliberately does not attempt to cover every possible complication, instead selecting specific examples that illustrate the types of problems that arise.

Key Findings

▶ Watch: Delegated administrator deregistration requirement for account migration (6:30)

IAM Identity Center instances are organization-specific. Each AWS organization gets exactly one IAM Identity Center (formerly AWS SSO) instance with one identity source. When you move an AWS account from the acquired company's organization into yours, anyone who had access through their IAM Identity Center loses it immediately. Getting the acquired company's employees onto your SSO provider is a hard prerequisite for account migration if you want them to retain access. If they are using per-account SAML identity providers instead, those will continue to work after migration and can be deprecated on a longer timeline.

Root credential management has recently changed. AWS introduced centralized root credential management for organizations less than a year ago. If you have it enabled, you can delete root credentials from all member accounts centrally. If not, you must obtain root credentials for each account individually. Importantly, if the acquired company has lost root credentials for any accounts, you can now update the email and phone number from the AWS Organizations console and go through password reset and MFA recovery without opening support cases.

Delegated administrator accounts must be deregistered before migration. AWS provides a clear error message if you attempt to migrate a delegated admin account without deregistering it first. However, GuardDuty is a special case because it can be configured either as a delegated administrator through AWS Organizations (the recommended way) or through the legacy invitation method. If the acquired company uses the legacy method, you must dissociate all member accounts from the GuardDuty admin before migration. Simply migrating accounts will not automatically associate them with your GuardDuty delegated admin if legacy associations exist.

GCP IAM hierarchy requires careful permission alignment. GCP permissions can be assigned at the project, folder, or organization level. When migrating projects between organizations, folder-level and organization-level permissions do not travel with the project. Custom IAM roles at the organization level in the source organization must be recreated in the destination. Google Workspace integration means employees must get onto your Workspace, though cross-domain sharing provides a transitional bridge. Critically, deleting a GCP organization requires deleting the underlying Google Workspace account, which Google describes as "potentially a very damaging action that might be impossible to fully reverse" — with implications far beyond just the cloud environment (corporate Gmail, for example).

VPC Service Control Perimeters must be disabled for GCP project migration. If the acquired company uses VPC Service Controls to meet compliance requirements, you cannot migrate protected projects without disabling the perimeter. If the perimeter exists to satisfy a compliance requirement, there may not be an acceptable window to disable it, and Lepow acknowledged having no good answer for this scenario beyond contacting support.

Technical Deep Dive

▶ Watch: GCP IAM hierarchy: folder and org-level permissions don't travel with projects (10:30)

The GuardDuty migration complication deserves particular attention. GuardDuty member accounts can be associated with an admin account through two mechanisms: the Organizations-based delegated admin (recommended) and the legacy invitation method (deprecated but still functional). If the acquired company's GuardDuty is configured via the legacy method, migrating member accounts into your organization does not sever the legacy association. Your delegated admin cannot see these accounts, and they remain associated with the old admin account. The fix requires manually dissociating all member accounts from the legacy admin, migrating them, and then either letting your delegated admin auto-discover them or manually adding them. Importantly, dissociation does not disable GuardDuty on the accounts — it only severs the admin relationship.

For AWS, IAM policies with Condition keys referencing organization IDs or OU paths (e.g., aws:PrincipalOrgID) will silently change behavior when accounts move between organizations. Lepow acknowledged this as a significant concern that was cut for time but noted that AWS documentation covers it thoroughly.

Resource Access Manager (RAM) shared resources, shared VPCs, and shared Route 53 configurations were described by another practitioner Lepow consulted as "exactly as bad as you described" — suggesting this is a known pain point that warrants its own talk.

Demo / Proof of Concept

▶ Watch: Deleting a GCP org requires deleting Google Workspace — potentially irreversible (12:30)

There was no live demo. Lepow showed screenshots of AWS documentation, error messages encountered during migration attempts, and GCP documentation warnings. The talk was structured as a guided walkthrough of documentation and operational experience.

Defensive Implications

▶ Watch: The web of dependencies: SSO, CI/CD, networking, finance stakeholders (16:00)

The most critical defensive action is to maintain log continuity during migration. Whether your organization uses Splunk, OpenSearch, or a SaaS SIEM, ensure that the log pipeline infrastructure (CloudTrail, CloudWatch, Cloud Logging) is updated to include acquired accounts and projects immediately. If the acquired company has their own SIEM, maintain it in parallel until you can confirm that all logs are flowing to your system. Losing logs during the migration window is the worst possible outcome from a security monitoring perspective.

Have a migration plan with a documented backout plan for each step. Google explicitly recommends this in their documentation: ensure you have permissions to send migrated projects back to the source organization if something breaks unexpectedly. Test rollback procedures before executing forward migrations.

Engage all stakeholders early: SSO/identity team, CI/CD pipeline owners, network infrastructure teams, finance/billing teams, and their counterparts at the acquired company. The "web of dependencies" means that changes to one system can cascade into unexpected failures elsewhere.

Key Takeaways

• IAM Identity Center is a hard migration prerequisite: Getting acquired employees onto your SSO is required before account migration, not after.
• GuardDuty has a legacy association trap: The legacy invitation method creates associations that do not automatically transfer to your delegated admin during migration.
• Root credential management just got easier: Centralized root access management and org-level email/phone updates eliminate the need for support cases.
• GCP organization deletion is destructive and potentially irreversible: It requires deleting the underlying Google Workspace account, which affects email and all Workspace services.
• VPC Service Control Perimeters block GCP project migration: If the perimeter exists for compliance, disabling it may not be acceptable and there is no documented workaround.
• Log continuity is the top priority: Ensure no gap in security monitoring coverage during the transition window between old and new log infrastructure.

About the Speaker(s)

Isaac Lepow has worked in various security roles and has spent significant time in cloud security. He performed cloud migration and integration work for three acquisitions at his previous employer. He credits AWS and GCP documentation as primary sources for much of the specific technical guidance in the talk and emphasized that contacting cloud provider support should be the first response when uncertainty arises during migration.