46% of organizations report security incidents involving unmanaged machine identities.

Cross-cloud transfers create machine identities on both sides — and forget them on both sides.

Here's what happens when a regulated dataset needs to move between two cloud environments:

A service account gets created on the source side with read access to the dataset. Another gets created on the destination side with write access to the target bucket. Both need cross-cloud networking permissions. And in practice, both get more privileges than strictly necessary — because debugging cross-cloud IAM failures is one of the most time-consuming problems in cloud engineering.

That's the setup. Here's where it gets interesting.

There's no single IAM system that spans both clouds. AWS IAM and GCP IAM are separate policy engines with different permission models, different role hierarchies, and different audit log formats. You define access rules independently in each environment, and nobody is cross-referencing them.

The principle of least privilege is almost always violated in practice. Teams elevate permissions to get the job done, because the cost of getting it wrong is a failed transfer at 2 AM.

And the part that keeps security teams up at night — ad-hoc transfers leave orphaned machine identities.

The job finishes. The data arrives. But those service accounts, API keys, and automation credentials? Many remain active long after the transfer is complete. No one revokes them because no one owns the cleanup.

Each one is an exploitable account that didn't exist before the transfer — and that your security team doesn't know about.

What does your team's cross-cloud IAM hygiene look like after a transfer completes?