You closed the tickets. The dashboard went green. Then Intruder’s 2026 Cloud Security Index, built from misconfiguration data across 3,000 organizations on AWS, Azure, and Google Cloud, showed leftover risk that barely overlaps from one provider to the next. A shared cybersecurity checklist can stamp the same controls complete while the actual exposure lives in a different identity model, a different storage API, and a different logging gap you never scored.

That leftover exposure is the bill you will pay later. Public storage. Over-privileged identities. Management endpoints your copied playbook never named because it was written for a different control plane. You bought a percentage for the steering deck. The attacker gets the provider you treated as a clone of the one you actually understand.

Copy-Paste Hardening Maps the Wrong Control Plane

Tape this sentence to the jumbotron before the next risk meeting. Intruder looked across those 3,000 tenants and said the quiet part out loud:

Risk profiles across providers have almost nothing in common.

You already knew AWS and Azure feel different to operate. The dataset says the failure modes diverge far enough that a single CIS-flavored scorecard becomes a reporting convenience leadership will treat as coverage. Defense in depth still matters. Stacking a perimeter firewall in front of a cloud you run like a colo does not purchase identity, key, and resource-policy coverage. Azure’s failure cluster will not resemble Google Cloud’s. AWS will surprise you in a third direction. If your threat-protection stack grades all three environments with one template, you are measuring loyalty to the template.

This is a bad look for any program that still briefs a single cloud-security percentage. The number hides the provider that is quietly worse. Attackers already know which plane you under-instrument. Brute-force against a management endpoint you never put on the shared list is cheap. Your copied hardening pass never opened that ticket, so your scanner had nothing to fail.

Security teams arrived here honestly. You were asked for one metric, one exception process, and one scanner policy that could survive an audit committee. Merging three clouds into a single CSPM profile felt like maturity. It produced a comparable number. Comparable is the trap. The board can rank you against last quarter. The attacker ranks you against the cloud whose IAM you never learned.

Shared lists also flatten language until it lies. Public storage is not one finding. Object ACL models, default encryption, anonymous access flags, and cross-account sharing controls differ by vendor. Admin exposed is not one finding either. One cloud leans on access keys and instance roles. Another leans on tenant-wide directory roles and service principals. A third leans on project-level IAM and workload identity. A checkbox that says MFA on the console can be true and still leave a machine-identity path wide open. Your cyber security reporting will still show green, because the checkbox matched.

Shared Fixes Leave Provider-Specific Doors Open

Stop translating. Start mapping. Immediate work is inventory and evidence. Ongoing work is drift control and rehearsal. Keep it vendor-neutral; native APIs and logs are enough to run this without buying a new platform to feel busy.

Do the work in the order that shrinks blast radius first:

• Split the asset inventory by provider. One row per account, subscription, or project, with owner, region, and internet-facing services named in that cloud’s own language.
• For each provider, list the real admin planes: IAM, federation, keys, storage ACLs, serverless roles, Kubernetes APIs, management portals. Record which of those are reachable from the internet and which logs you actually retain for 90 days or more.
• Hunt public exposure and brute-force noise on those native endpoints. A generic SSH and RDP checkbox misses the admin APIs, metadata services, and identity endpoints that actually matter in each cloud.
• Rewrite security hardening baselines per cloud. Copying bucket policy language from one vendor onto another is how findings evaporate during the equivalent control debate.
• Tune threat detection to native telemetry and event schemas. Shared SIEM rules that assume one log shape will miss the other two providers on a quiet weekend.
• Tabletop incident response per provider. Containment clicks, evidence locations, and identity freeze steps differ. Rehearse the cloud you use least; that is the one your on-call will fumble.

Put names on the map. A shared cloud team with no break-glass owner per provider is how containment waits on a Slack thread at 2 a.m. Require proof. A scanner screenshot is a souvenir. Proof looks like logging enabled and queried last week, a public resource list exported this month, an identity privilege review with a date on it, and a freeze procedure someone has actually run in a non-production tenant. If you cannot name the person who can disable keys in Google Cloud tonight, your Google Cloud control is still a hope parked next to an AWS runbook.

A Green Scorecard Slows Cybersecurity Response

When the page turns, your incident response team inherits the same fiction. They open a generic cloud runbook and reach for the wrong console. Containment time stretches while someone hunts for the identity store this provider actually uses. Hours spent translating a playbook are hours the session keys keep working. Threat detection that was tuned on one event schema stays quiet in the other two. You will learn which cloud was the orphan during the incident, which is the most expensive classroom I know.

The same failure mode showed up outside cloud this week. Some teams still treat images off in email as a finished threat-protection step. Attackers answered with QR lures built from text, which still render when pictures are blocked. A trusted software source delivered code that stole credentials. A control you already checked can fail in a channel you never re-tested. Multi-cloud programs collect that failure at scale because three vendors give you three channels to get wrong, and your scorecard only speaks one dialect.

If you want defense in depth that survives contact with production, collect independent proof per provider. Logging on. Least privilege evidenced. Public exposure listed. A named owner who can freeze that cloud’s identities before the standup. Score each cloud as its own problem. Intruder’s sample already printed the lesson; your next ticket queue does not need to reprint it.

Sources

• Your Cloud Security Checklist Doesn’t Work the Way You Think It Does
• Weekly Recap: Chrome 0-Day, Router Hijacks, Coder Supply Chain Attack and More