Restrict admin and enforce MFA: identity as the strongest lock on AWS

Most serious intrusions do not begin with a clever exploit. They begin with a credential: a phished password, a leaked access key, an over-privileged role that one compromise turns into the keys to the estate. That is why two of the ACSC Essential Eight strategies, restrict administrative privileges (strategy 5) and multi-factor authentication (strategy 7), carry so much weight. They sit on the path almost every attacker has to walk.

This piece is for the identity and cloud architects who have to make those two strategies real on AWS. The good news is that AWS turns both from policy aspirations into mechanisms you can configure, enforce, and prove.

Identity is the control plane

In a cloud estate there is no perimeter to stand behind. The thing that decides what an actor can do is not a firewall rule but an identity and the permissions attached to it. Identity is the control plane. Every API call, every console action, every workload-to-workload request is authorised against an identity, which means the controls that govern identity are the highest-leverage controls you have.

Think of it as a lock. A weak lock is a long-lived access key with broad permissions and no second factor: pick it once and you own everything it touches. The strongest lock has three properties. The privilege behind it is minimal. The privilege is not standing, it is granted only when needed. And opening it requires proving identity with more than a password. Strategies 5 and 7 build exactly that lock, and AWS gives you the parts.

Restrict administrative privileges

Restricting administrative privileges is least privilege applied to the people and roles that can change things. In practice it means four disciplines: grant the minimum permissions a task needs; keep dedicated admin identities separate from daily-use accounts; avoid standing privileged access; and validate, then periodically re-validate, exactly who holds privilege and why.

On AWS those disciplines have direct mechanisms:

• Least-privilege IAM policies. Scope permissions to specific actions, resources, and conditions rather than reaching for *. Start narrow and widen only when a real task demands it.
• AWS IAM Identity Center with permission sets. Centralise workforce access across accounts and assign people to permission sets rather than minting individual IAM users. Admin access becomes a named, auditable assignment, not a scattered set of long-lived credentials.
• Temporary credentials via roles and AWS STS. Prefer roles that issue short-lived credentials through AWS STS over long-lived access keys. Credentials that expire on their own are credentials an attacker cannot hoard.
• Separate admin identities from daily use. The identity a person uses to read a dashboard should not be the identity that can delete a production database. Distinct identities, distinct permission sets, distinct sign-in.
• Restrict local administrator rights on instances. The principle does not stop at the AWS API. On EC2 Windows and on Amazon WorkSpaces, limit local administrator rights so a single compromised desktop or server is not a free promotion to full control.

The first three of those replace the most dangerous artefact in many AWS accounts, the long-lived access key, with identities and short-lived credentials that are far harder to steal and far easier to revoke.

Just-in-time, not standing

The single most effective change you can make to administrative access is to stop letting it stand around. Standing privilege is a window that is always open: an attacker who lands on an identity with permanent admin rights has admin rights the moment they arrive. Just-in-time access closes that window most of the time and opens it only on request.

The model is simple. A person who needs to perform a privileged task requests elevation. The grant is time-bound, scoped to what the task needs, and revoked automatically when the window closes. Between requests, no one holds standing admin. On AWS you build this around IAM Identity Center assignments and roles assumed through AWS STS, so that elevated access is something you assume for a defined period rather than something you carry.

Multi-factor authentication, everywhere

Multi-factor authentication is the second face of the same idea: a password alone is no longer proof of identity, so require a second factor. The strategy is only as strong as its weakest sign-in path, which means the goal is coverage without exceptions. On AWS, enforce MFA across every place an identity authenticates:

• The AWS root user. The most powerful identity in an account should never be reachable with a password alone. MFA on root is non-negotiable, and the root user should be locked away for break-glass use only.
• The console. Human sign-in to the AWS Management Console must require a second factor.
• IAM Identity Center. Where workforce access is centralised, enforce MFA at the Identity Center sign-in so every permission-set assignment inherits it.
• Workloads and applications. MFA does not stop at the AWS control plane. The applications running on AWS, and the identities that reach them, need a second factor too.

The discipline that makes this work is the absence of bypass paths. An MFA policy with a quiet exception, a service account that skips it, a legacy login that does not enforce it, is an MFA policy an attacker will simply route around. Enforce it, then go looking for the holes.

Phishing-resistant at higher maturity

Not all second factors are equal. A one-time code can be phished as readily as a password if an attacker relays it in real time through a convincing fake sign-in page. The Essential Eight maturity model recognises this, and its higher levels lean toward phishing-resistant MFA, the kind that cryptographically binds the authentication to the legitimate site so a relayed credential is worthless. FIDO2 security keys are the canonical example, and AWS supports FIDO2 and passkeys as MFA methods.

The evidence

A control you cannot prove is a control you are only hoping for. The reason these two strategies are so well suited to AWS is that the platform lets you demonstrate them continuously rather than asserting them in a policy document.

• IAM Access Analyzer surfaces over-permissive and externally exposed access, and helps you tighten policies toward least privilege based on what identities actually use, evidence that privilege is scoped, not assumed.
• IAM credential reports list every identity, its access keys, their age, and its MFA status, so you can show there are no stale long-lived keys and that MFA is enabled where it should be.
• AWS CloudTrail records who did what, when, and whether the session was elevated, giving you the audit trail to prove there is no standing admin and that privileged actions trace to a time-bound, authenticated grant.

Together these let you answer the questions an auditor, or an incident responder, will actually ask. Who can administer this account? When did they last hold privilege, and for how long? Is MFA enforced on every sign-in path, with no exceptions? On AWS those are queries against live evidence, not a leap of faith.

The strongest lock you can fit

Strategies 5 and 7 are the same control seen twice: minimise privilege, make it temporary, and prove identity with more than a password. AWS turns each part into a mechanism, least-privilege IAM, Identity Center permission sets, short-lived credentials through AWS STS, just-in-time elevation, MFA on every path with phishing-resistant factors for the strongest levels, and Access Analyzer, credential reports, and CloudTrail to prove it all holds. Build that lock well and you have removed the path most intrusions depend on. Identity, configured this way, is the strongest lock on AWS.