Skip to content
The Cyber Security Place

Defence

Cloud security in 2026: the perimeter is a permission list

There is no edge to defend and no cable to unplug. What decides how bad an incident becomes is a question nobody used to have to ask: what, exactly, can this credential reach if somebody else is holding it?

Last reviewed August 25, 2026

Analysts have long put roughly 99% of cloud security failures on the customer's side of the shared responsibility line, and misconfiguration ranks first among causes — present in about 14% of all reported breaches. The deeper shift is that the problem is identity, not network: over 70% of cloud breaches involve compromised identities and close to 99% of users, roles and service accounts hold permissions they never exercise. Non-human identities now outnumber people by ratios from 45:1 up to 144:1 in cloud-native estates. Scanning found 28.65 million new hardcoded secrets in public commits during a single year, up 34%, and about 64% of secrets leaked in 2022 were still valid years later. The control that matters is blast radius.

What can one leaked key actually reach?

Pick a credential and follow it. Not what it was issued for — what it arrives at once you allow that roles can assume other roles and that applications write things into logs.

Worked exampleWhat one leaked credential reaches

5things it can reach
2of them holding sensitive data
3hops to the far edge

Starting from Monitoring service account

  1. Hop 1

    • Metrics workspaceread access to the dashboard it was created for
    • Application log storethe same read policy was applied to the log store

  2. Hop 2

    • Application runtime rolea token written into a debug line by the application itself

  3. Hop 3

    • Production databasethe connection the application needs to work
    • Customer document storeread and write, because uploads pass through it

An illustrative estate, not a measurement of one. Every edge above is an ordinary grant that somebody had a good reason to make; none of them is a mistake in isolation. The read-only account created for a dashboard reaches customer records in three hops, and no review that examines permissions one at a time would ever notice.

The read-only monitoring account is the one worth sitting with. It was created for a dashboard, it can change nothing, and it would pass any review that asks whether an identity has write access. It also reaches customer records, because the log store it can read contains a token the application wrote there, and that token belongs to a role that talks to the database.

Every edge in that picture is an ordinary grant somebody had a good reason to make. Nobody was careless. The exposure is a property of the composition, and compositions are invisible to a review that examines permissions one at a time — which is how essentially all of them are conducted.

This is also why the phrase least privilege under-describes the work. Trimming each identity to what it needs is necessary and does not by itself break a chain, because every link in the chain is already something needed. What breaks the chain is refusing to let certain hops exist at all: a pipeline that cannot read the secret store directly, a runtime role that cannot be assumed from outside the runtime, a log store that no identity with production access can read.

The half of shared responsibility nobody reads

The model is usually drawn as a diagram in a sales deck and then never consulted again. Laid out as a grid it makes one thing obvious.

IaaSPaaSSaaSPhysical facilitiesHardware and networkVirtualisation layerOperating systemRuntime and middlewareApplication codeConfiguration and accessData and identityshaded = the customer's responsibility · solid = the two rows that are always yours

The boundary slides downwards as you move from infrastructure to platform to software, and every sales conversation is about how much of the stack you are relieved of. The two rows at the bottom never move. Configuration and access, data and identity: yours under every model, at every provider, forever.

That is the whole reason the failure statistics look the way they do. Analysts have put the customer's share of cloud security failures at around ninety-nine per cent for years, and this is not a claim that providers are perfect. It is an observation about which layers are hard: the layers a provider owns are uniform, automated and operated by specialists, while the layers you own are different in every organisation and edited by people under delivery pressure.

The term was already circulating when it needed explaining: It's not you, it's me: Understanding the shared responsibility of cloud security - Cloud Tech News, May 11, 2015. What was underestimated then was not the split but the asymmetry inside it — that the customer's half would turn out to be the difficult half.

Why is misconfiguration still the top cause?

Because the word is wrong. It suggests somebody typed the wrong thing, and that is rarely what happened.

A modern account exposes thousands of individually adjustable settings across dozens of services, most of which interact. Almost every reported exposure follows the same pattern: a setting that was correct when it was made, in a deployment much smaller than the current one, which nobody revisited when the context changed. A storage container opened to a partner in a pilot. A network rule widened during an outage at two in the morning. A role granted an extra permission to unblock a release.

None of those is a mistake at the moment it is made, and that is precisely why detection is hard. A scanner can find an open container; it cannot find a grant that was appropriate in 2023 and stopped being appropriate when the resource behind it changed. The gap between a setting somebody chose and a setting that is still right has no automated test, and it widens quietly.

The productive reframing is to stop treating configuration as a state to be audited and start treating it as code with an owner, a review and a history. Not because infrastructure as code is fashionable, but because it is the only arrangement in which the question why is this permission here has an answer somebody can read.

AWS Misconfigurations Expose Users to Cloud Security Risks ran in April 19, 2017, and the pattern it describes is unchanged today apart from the number of settings available to get wrong.

The identities that are not people

Access management was designed around employees. Somebody joins, gets accounts, changes team, leaves, and a process exists for each of those moments. Almost none of that applies to the majority of identities in a cloud estate.

Service accounts, pipeline roles, workload identities, integration keys: reported ratios put machines ahead of people by anywhere from forty-five to one up towards a hundred and forty to one in cloud-native environments, and the ratio has been climbing. Each one was created to make something work, usually in a hurry, often by somebody who has since moved on.

The structural problem is that machines do not leave. There is no resignation to trigger a review, no manager confirming the account is no longer needed, no quarterly recertification that anybody completes honestly for four hundred service principals. Surveys consistently find large shares of keys older than a year still active in production, and an access key with no expiry is a permanent grant that outlives every person who understood why it was made.

There is one control that changes this category rather than managing it: replace long-lived keys with short-lived credentials issued to a workload identity at runtime. A credential that expires in an hour cannot be leaked in a way that matters six months later, which removes most of what the rest of this section is about. It is not a small migration and it is the highest-value one available.

Secrets leaked years ago that still work

Credentials escape constantly, through routes that are well understood and apparently impossible to close: committed to a repository, pasted into a ticket, printed by a debug statement, embedded in a mobile application, left in a container image layer.

The volume is the part that surprises people. Scanning of public commits detected in the region of twenty-eight million new hardcoded secrets across a single recent year, a rise of about a third on the year before, with a notable share of the growth attributable to keys for machine-learning services that did not exist as a category two years ago.

The genuinely alarming figure is not the exposure rate but the revocation rate. When secrets leaked several years earlier were re-checked, a substantial majority were still valid. Detection has improved enormously; the response has not. Somewhere between the alert and the fix there is a step that requires knowing what the credential is for and what breaks if it is withdrawn, and for most of these nobody knows.

Which points at the same conclusion as the section above. A scanner that finds leaks is worth having and does not reduce risk on its own — the reduction happens when rotation is automatic and cheap, because then revoking a suspicious credential stops being a decision that requires courage.

Is the cloud less secure than a data centre?

No, and the question hides the interesting one. The layers a large provider operates — facilities, hardware, hypervisors, patching of the substrate — are almost certainly run better than the equivalent in a private room somewhere, by people who do nothing else.

What changes is the speed and reach of a mistake. In a physical estate, exposing a database to the internet requires several deliberate steps across equipment somebody has to touch. In a cloud account it is one attribute on one resource, and the exposure is global the moment it is saved. The floor is higher and the failure mode is faster, which is a genuinely different risk profile rather than a worse one.

The second change is that the audit trail improved beyond recognition. Every action is an API call and every API call can be recorded, which is a standard of observability no physical estate ever reached. Whether that potential is realised is a budget question, addressed below, and it is one of the few places where the cloud's security posture is decided by a finance conversation rather than a technical one.

The third change is the one that catches people out, because it runs the other way. A physical estate degrades slowly and visibly: hardware ages, somebody notices the rack. A cloud estate degrades invisibly, because nothing physical corresponds to the four hundred resources created for a project that was cancelled eighteen months ago and never torn down. Those resources keep their permissions, keep their network reachability and keep appearing in nobody's review, and the only thing that ever surfaces them is a bill somebody decides to read closely.

What changed when the workloads became models?

A new category of service arrived in cloud accounts faster than any before it, and it arrived through a door the access review was not watching.

The pattern is familiar to anyone who watched the first wave of storage services. A team needs a capability, the platform offers it behind an endpoint and a key, and the key is issued in minutes by somebody with the authority to spend a few pounds. No architecture review, no threat model, no entry in an inventory that was designed around servers. By the time anybody asks how many such endpoints the organisation uses, the answer is a number nobody can produce.

The measurable consequence is already visible in the leak data: keys for these services were among the fastest-growing category of exposed secrets in the most recent counts, rising far quicker than the overall total. That is not a statement about the services being insecure. It is a statement about how new credentials behave in an organisation that has no process for a credential type it has never seen.

Two properties make these particular keys worth separating from the general problem. They are frequently billed by consumption, so a leaked one converts directly into somebody else's expenditure on your account, which is a failure mode with no equivalent in a leaked read-only database credential. And the data flowing through them is often the material an organisation would least like to see leave: support transcripts, internal documents, customer correspondence, pasted wholesale into an endpoint because that was the quickest way to get an answer.

The correct response is unglamorous and it is the same response the storage wave eventually got. Route these calls through a gateway the organisation controls rather than letting each team hold its own key, so there is one place that knows what is being sent, one place to rotate, and one place to answer the question of which data went where. The reason to do it now rather than later is that the inventory problem gets harder every month it is deferred, and this particular category is compounding faster than anything before it.

A decade of the same argument

This section carried 415 reports across seven years, and the year-by-year shape follows the industry's anxieties rather than the state of anybody's account.

Reports in this section, by year
2015201620172018201920202021
47338976772848

The early years are dominated by a question that has since evaporated: whether moving anything sensitive off premises was defensible at all. Read those headlines now and the anxiety is about custody — where the disk physically sits, who can walk up to it, which jurisdiction it falls under. That argument was settled by economics rather than by anybody winning it.

What replaced it was narrower and more useful. Once the migration was assumed, the reporting turned to configuration, access and the interfaces between services, which is where it has stayed. The through-line across the decade is a discipline that spent its first half arguing about whether to go and its second half discovering that the difficult part was never the going.

How digital transformation is reshaping the modern enterprise, January 19, 2018, sits at the pivot. Running across several platforms was being sold as resilience, and the security consequence — that each one has its own permission model, defaults and logging, and that very few teams are fluent in two — took several more years to be stated plainly.

The logging problem: paying to see

Cloud platforms can record essentially everything, and that capability is metered, which is the part that survives every change of platform. Detailed audit trails, data-access events and network flow records are frequently off by default and charged by volume, which produces a predictable sequence.

The sequence runs: everything is enabled during the migration, the first full quarter's bill arrives, somebody is asked to reduce it, and the least visible line items are trimmed because nothing breaks when they are. Retention drops from a year to ninety days, then to thirty. Nobody notices, because the only thing that notices is an investigation, and there has not been one yet.

Then there is one. The characteristic finding in cloud incident reports is not that the intrusion was sophisticated but that its beginning falls outside the retention window, so the scope cannot be established. That converts a bounded incident into an unbounded disclosure obligation, because an organisation that cannot demonstrate what was not accessed has to assume the worst.

The decision worth taking deliberately is which specific events must survive a year, priced honestly and defended in the budget. It is a small list — control plane changes, identity events, access to the stores that matter — and it costs a fraction of logging everything. The failure mode is not choosing to log less; it is letting the choice be made by whoever was asked to reduce a bill.

Which controls actually bound the blast radius?

Ordered by how much they change the graph at the top of this page rather than by how often they appear in a framework.

Short-lived credentials everywhere they are possible. This removes the entire category of the leaked key that still works. It is the largest single improvement available and the one most often deferred, because the migration is tedious rather than difficult.

Scope each identity to what it has used, not what it might. Platforms record which permissions an identity actually exercised, so this is a report rather than a judgement. The gap between granted and used is routinely enormous, and closing it is mechanical.

Break the chains that cross a boundary. Decide which hops must not exist — a build role that cannot act as the application, a monitoring identity that cannot read stores holding production tokens — and enforce those as policy rather than as convention. This is the control that acts on composition instead of on individual grants.

Separate environments with an account boundary, not a tag. A naming convention is not a security control, and the strongest isolation a platform offers is the boundary between accounts.

Log the small set that matters, for a year, in writing. Priced and defended deliberately, as above.

Where to start on a Monday

Three queries, all answerable from the platform's own tooling, none of which needs a purchase.

List every long-lived credential and its age. Sort descending. The top of that list is a set of permanent grants nobody has thought about in years, and it is usually shorter than feared and older than believed.

Pull the granted-versus-used report for your twenty broadest roles. The platforms produce this. The difference between the two columns is exposure you are carrying for no benefit, and removing it breaks nothing by construction.

Pick your least privileged identity and trace what it can assume. Follow it two hops. Most teams doing this for the first time find a path they did not know existed, which is the finding — not the specific path, but that the map was wrong.

After those three the harder work is genuinely prioritisable: migrating to short-lived credentials, splitting environments across account boundaries, and settling the retention question with a number rather than a default. An organisation that has done the first three can answer what one leaked credential would cost it, and that is the question the entire subject reduces to.

Common questions

Who is responsible for security in the cloud?

Both parties, at different layers, and the split moves with the service model. The provider secures the facilities, hardware and virtualisation; the customer secures configuration, access, identity and data. Those last two are the customer's under every model, and they are where the overwhelming majority of reported failures occur.

What is the single most common cause of cloud incidents?

Misconfiguration, consistently ranked first, and it now features in a substantial share of all reported breaches. The word makes it sound like carelessness; usually it is a default that was reasonable for a small deployment and became dangerous at scale.

Why do misconfigurations persist when everybody knows about them?

Because the number of settings grew faster than the number of people reviewing them, and each one is individually defensible. A permission granted for a good reason in 2023 becomes an exposure in 2026 when the resource it points at changes.

How much of the risk is identity rather than network?

Most of it. Reported figures put compromised identities behind more than seventy per cent of cloud breaches, and studies of live estates find that nearly all users, roles and service accounts hold permissions well beyond what they use.

What is a non-human identity?

A credential belonging to a machine rather than a person: a service account, a pipeline role, an API key, a workload identity. They now outnumber people substantially — reported ratios range from tens to one up towards a hundred and forty to one in cloud-native estates — and almost none of them has an owner or an expiry.

Do leaked keys actually get used?

Frequently, and long after the leak. Scanning of public repositories detected tens of millions of new hardcoded secrets in a single recent year, and a majority of secrets leaked several years ago were still valid when checked. Exposure and revocation are almost entirely disconnected.

Is the cloud less secure than a data centre?

No, and the comparison misleads. The infrastructure layers a provider operates are almost certainly better run than an equivalent private facility. What changes is that a single misconfigured permission can expose a service globally in seconds, with no physical constraint to slow it down.

What is blast radius and why does it matter more here?

How far an attacker gets once they hold one credential. In a cloud estate the answer is a graph traversal rather than a network diagram, because roles can assume other roles. A credential with modest direct permissions can reach sensitive data in two or three hops.

Which controls actually bound the blast radius?

Short-lived credentials instead of long-lived keys, scoping each identity to the resources it uses rather than the ones it might, and blocking role chains that cross a trust boundary. Those three do more than any amount of alerting.

Does multi-cloud improve resilience?

It improves resilience against a provider outage and worsens the security position, because each platform has its own permission model, its own defaults and its own logging. Very few teams are equally fluent in two, and the second one is where the gaps are.

Why is cloud logging so often incomplete?

Because much of it is charged by volume and off by default, so a cost review quietly reduces retention. The result is an estate that can be investigated only for the period somebody was willing to pay for, which is typically discovered during an incident.

What should a cloud review check first?

Long-lived credentials and their age, permissions that were granted but never exercised, and which identities can assume which roles. Those three questions surface more real exposure than a scanner report of several thousand findings.

Cloud security coverage

415 reports, newest first. Most cited sources: helpnetsecurity.com (102), infosecurity-magazine.com (32), itproportal.com (21), csoonline.com (19), tech.einnews.com (16), darkreading.com (13).