What actually causes cloud breaches?
Most cloud breaches are not sophisticated. They come from misconfiguration and identity: a storage bucket left open, an over-privileged role nobody reviewed, a management plane reachable from the internet, or credentials that never expire. The shared responsibility model puts all four squarely on the customer, not the provider.
The misconfiguration problem, stated plainly
Cloud providers secure the infrastructure. You secure what you build on it — identity, network exposure, data access, and configuration. That boundary is where breaches happen, and it is why “we are on AWS” or “we are on Azure” is not a security posture.
Verizon’s 2026 DBIR found vulnerability exploitation is now the leading breach entry point at 31%, with third parties involved in 48% of breaches. In cloud estates both tend to arrive through the same door: an exposed service or an integration with standing access nobody audits.
Seven practices worth the effort
1. Remove standing privileged access
Permanent administrator roles are the single largest avoidable risk in a cloud estate. Move to just-in-time elevation with approval and expiry. If that is too big a step, start by ensuring no human account holds permanent root or global administrator.
2. Treat the control plane as internet-facing infrastructure
The management console and API are the highest-value target in your environment: they can create, delete and exfiltrate everything at once. Enforce phishing-resistant MFA, restrict by network where feasible, and alert on every privileged control-plane action.
3. Log the control plane and keep the logs
CloudTrail, Azure Activity Logs and Google Cloud Audit Logs are what turn an incident into an investigation. Retain them outside the account that generates them, so an attacker with administrative access cannot erase the evidence of what they did.
4. Make configuration a code review, not a console click
Infrastructure as Code means a misconfiguration is a reviewable diff rather than an invisible click at 6pm on a Friday. It also makes drift detectable: if production no longer matches the code, something changed outside the process and that is worth knowing about.
5. Scan for posture continuously, not annually
Cloud posture management catches public storage, unencrypted volumes, permissive security groups and over-broad IAM policies as they appear. An annual assessment tells you what was wrong last quarter.
6. Rotate and scope credentials, and ban long-lived keys
Mandiant’s M-Trends 2026 highlights attackers harvesting long-lived OAuth tokens, session cookies and hard-coded keys from third-party SaaS vendors, then pivoting into downstream customer environments. Prefer workload identity federation over static keys, and scope every token to the minimum it needs.
7. Encrypt, and own the key decision deliberately
Provider-managed encryption is fine for most data. For regulated or high-consequence data, decide consciously whether you need customer-managed keys, and document why. The decision matters more at audit than the default does.
The FinOps connection people miss
Unused resources are not only a cost problem. An orphaned VM nobody owns is unpatched, unmonitored and still reachable. Cost governance and security governance find the same things — which is a good argument for running them together rather than in separate quarters.
A short self-assessment
Can you list every identity with administrative rights in each cloud account? Do you know which storage is publicly reachable right now, rather than at last review? If your cloud administrator account were compromised, would you still have the logs to reconstruct what happened? Three no answers is a starting backlog.
Where Rivo fits
Our cloud services cover readiness audits, architecture design, cloud security posture and FinOps governance across AWS, Azure and Google Cloud. Where the work is identity hardening and compliance evidence, our cybersecurity services team runs alongside. Talk to our engineers about an assessment.
