Root access and why the control plane is the whole game
Encryption at rest, network segmentation and vulnerability management all assume the attacker has to break something. An attacker with control plane access does not: they make ordinary API calls, and every control you built is a setting they can now edit, including the logs that would have recorded them doing it. This is why the ranking of cloud security work is not a matter of taste. Everything else on this pillar is downstream of who can call the management API as an administrator.
What is the control plane and why does it outrank everything?
The control plane is the management API that creates, reconfigures and destroys resources, as distinct from the data plane, which serves your actual traffic. Creating a machine, attaching a role, changing a firewall rule, generating a new key, disabling logging: all of these are authenticated HTTPS requests to a public endpoint. There is no console in a locked room, and physical proximity buys nothing.
Because configuration is the control, control plane access is authority over the controls themselves. Encryption at rest is a good example of why this matters. It defends against someone obtaining the physical media or reading the storage layer directly, and it is worth having. It does nothing against a caller who asks the service politely for the object, and an administrator can grant themselves that permission and then read anything the account holds.
The test that follows is unforgiving and worth applying to every security investment: would this control survive an attacker who holds administrative credentials in this account. Most would not. The few that do are logs written to a destination the account cannot modify, keys held under a policy the account cannot change, and denials enforced from above the account, which is why those three appear repeatedly across this pillar.
What can root and global administrator actually do?
More than an ordinary administrator, and in ways that are hard to constrain by design. On AWS, the root user of the organisation's management account can act outside organisation policies, change payment details, close accounts and alter the organisation itself. On Azure, a Global Administrator in the tenant can elevate their own access to the root management group and then hold rights over every subscription beneath it. On Google Cloud, an Organisation Administrator can set policy anywhere in the hierarchy.
The path teams most often miss is the identity provider behind all of this. If your cloud administrators sign in through a directory, then whoever administers that directory can create or impersonate an administrator, so a super administrator of your workspace or tenant is effectively a cloud administrator whether or not they hold a cloud role. Estates are frequently discovered where directory administration is looser than cloud administration, which makes the cloud controls decorative.
The other overlooked capability is establishing new trust. An attacker with sufficient privilege does not need to keep the credential they stole: they can register an additional identity provider, add a federation trust, or create a role assumable from an account they own. That is quiet, survives every password reset, and is one of the few changes worth alerting on unconditionally.
| Privileged identity | What it can reach | Where it should sit | Detection |
|---|---|---|---|
| Root of an AWS management account | The organisation, billing, all policy | Hardware keys, no access keys, used almost never | Alert on every sign-in and every use |
| Root of a member account | That account, outside some guardrails | Contact details owned centrally, MFA enrolled | Alert on sign-in, review contact changes |
| Azure Global Administrator | The tenant, and root management group after elevation | Few holders, time-limited elevation | Alert on the elevate-access action |
| Owner at a root or high management group | Every subscription beneath it | No standing holders | Alert on role assignment at that scope |
| Directory or workspace super administrator | Any federated cloud administrator | Same controls as cloud root, often weaker | Alert on new admin, on new federation trust |
| A new identity provider or federation trust | Whatever role it maps to, permanently | Should change almost never | Alert unconditionally, treat as an incident |
Why is account recovery the weakest link?
Because recovery is designed to work when the credential does not, which makes it a parallel authentication path that most organisations never assess. Root access on the major providers can generally be recovered through the registered email address, sometimes with a phone factor, and support processes exist for customers who have genuinely lost everything. An attacker who controls the mailbox is therefore in a strong position regardless of how good your password and second factor are.
The common failure is mundane. The root address is a personal mailbox belonging to whoever opened the account, or an alias forwarding to a shared inbox several people can read, or a mailbox in a domain nobody is monitoring. Phone-based recovery adds its own exposure through number takeover. None of this is exotic, and all of it sits outside the cloud security controls a review typically examines.
Fix it structurally. Root and administrator contact addresses should be distribution addresses in a domain you control, monitored, with their own strong authentication and their own audit trail, and readable only by the small group who would ever legitimately act on them. Enrol phishing-resistant hardware keys where the provider supports them, and record the recovery arrangement in your break-glass procedure so it is a deliberate design rather than an accident of history.
How do you protect the control plane day to day?
Remove standing administrative access from humans and make elevation time-limited, which is the single change with the largest effect. Alongside it, keep the management or organisation account free of workloads: it exists to hold policy and billing, and every application deployed into it widens the set of people and pipelines with a reason to be there. Separation here is cheap at the start and expensive to retrofit.
Then use the layer above the account. Organisation-level policy that denies disabling audit logging, denies deleting the log destination, denies removing security tooling roles and denies use of regions you do not operate in cannot be overridden by a compromised account administrator, and blocks actions no legitimate delivery work requires. This is the only category of control that holds when the account itself is lost.
Break-glass access completes the picture, and it needs to be genuinely usable. A dormant privileged account, credentials split and held physically, hardware key in a safe, an alert on any use, and a rehearsal on a fixed cadence to confirm it still works after the last identity change. Untested break-glass fails at the worst moment, and the failure mode is that somebody grants themselves permanent access under pressure and it is never removed.
Which control plane events deserve an alert?
A short list, because a long one gets muted. Any use of root or of a directory super administrator. Any change to audit logging configuration or to the log destination. Any new identity provider, federation trust or role trust policy that references an external party. Any change to organisation policy or to a root management group role assignment. Any modification to the key policy on a customer-managed key. Each of these should be rare, so an alert on each is quiet by construction.
Deliberately leave out the noisy things. Failed sign-ins, new instances, security group changes on development accounts and permission grants inside a team's own boundary are all better served by periodic review than by pages, and including them is how the alerting channel becomes background noise that hides the six events that mattered.
Route these somewhere a person is accountable for outside working hours, and route them out of the account that generated them. An alert delivered only into the compromised account's own notification service is not evidence, because the attacker holds the permissions to change where it goes.
What can you test this week?
Enumerate every path to full control, including the ones that are not cloud roles. Write down each identity that can reach root or global administrator, each mailbox that can recover one, each person who administers the directory, and each pipeline or automation identity with the ability to modify policy. Most organisations find the list is roughly twice as long as they expected and includes at least one mailbox or contractor account nobody had considered.
Then run one deliberate exercise: sign in with root, or perform the elevation action on your tenant, and time how long it takes for a human to notice and contact you. This is the highest-signal test on the page. If nobody calls, the control plane is unmonitored regardless of what the alerting configuration claims.
Finally, confirm the log destination is outside the account being logged, and that the account being logged cannot delete or alter it. That property is what makes an audit trail evidence rather than a convenience, and it is the difference between reconstructing an incident and taking the attacker's word for what happened.
Common questions
- What is the cloud control plane?
- It is the management API that creates, reconfigures and destroys resources, as distinct from the data plane that serves your application traffic. Every management action, including attaching a permission, changing a firewall rule or disabling logging, is an authenticated request to a public endpoint. Because your security controls are themselves configuration, control plane access is authority over the controls, which is why it ranks above everything else.
- Why does encryption at rest not protect against an administrator?
- Encryption at rest defends against someone obtaining the storage media or reading the storage layer directly. It does not defend against a caller who asks the service for the object through the API, because the service decrypts transparently for authorised requests. An account administrator can grant themselves that authorisation, and if they can also change the key policy, customer-managed keys do not change the outcome either.
- How should root account access be secured?
- Enrol phishing-resistant hardware keys, remove any long-lived access keys attached to it, and use it almost never. Point its contact address at a monitored distribution address in a domain you control, with its own strong authentication, readable only by the few people who would act on it. Alert on every sign-in, and keep the credentials as a rehearsed break-glass procedure rather than something an engineer can reach on a normal day.
- Why is account recovery a security risk?
- Recovery is designed to work when the credential does not, so it is a second authentication path that bypasses your password and second factor. If the registered address is a personal mailbox, an unmonitored alias or a shared inbox, whoever reads that mailbox can obtain root. Phone-based recovery adds number takeover risk. Assess recovery paths with the same seriousness as sign-in, because attackers generally prefer them.
- Which cloud events should always raise an alert?
- Use of root or a directory super administrator, any change to audit logging or its destination, any new identity provider or federation trust, any role trust policy referencing an external party, changes to organisation policy or root-scope role assignments, and changes to a key policy. Each should be rare, so alerting on all of them stays quiet. Noisy events like failed logins belong in periodic review instead.
- Can an attacker keep access after we reset all passwords?
- Yes, if they had enough privilege to establish new trust. Registering an additional identity provider, adding a federation trust, or creating a role assumable from an account they control all survive credential resets, because nothing they rely on is a password. This is why trust configuration changes belong on the unconditional alert list and why incident response has to include an inventory of federation and trust policies.
