A static cloud credential — an access key downloaded once and placed in a configuration file, an environment variable, or a secrets manager — works exactly the same way for as long as it exists, whether it’s being used by the legitimate service it was created for or by whoever else eventually gets hold of it. Workload identity replaces this model with credentials that are issued automatically, scoped narrowly, and expire on their own, removing the long-lived static secret from the equation entirely.

The core idea

Workload identity lets a workload — a VM, a container, a Kubernetes pod, a CI/CD pipeline — prove its identity to a cloud provider using an identity mechanism native to the platform it’s already running on, rather than a separately issued static credential it has to store and protect. The cloud provider verifies that identity (often via a signed token from the underlying platform) and, if the trust relationship allows it, issues short-lived, temporary credentials scoped to what that specific workload is allowed to do. No static key is generated, stored, or needs rotating, because the credential is requested fresh each time it’s needed and expires shortly after.

This is the same underlying pattern as GitHub Actions OIDC for CI/CD, generalized to any workload: an ambient, platform-verified identity replacing a portable static secret.

Where this shows up across major platforms

AWS IAM roles for EC2 instances and ECS/EKS workloads let a compute resource assume a role automatically, without ever having an access key stored on the instance — the AWS SDK, when running on that instance, retrieves temporary credentials from the instance metadata service automatically, and those credentials rotate on their own throughout the instance’s lifetime.

Google Cloud’s Workload Identity Federation extends this further, allowing workloads running outside Google Cloud entirely (in another cloud, or in an on-premises environment, or in GitHub Actions) to authenticate using their own platform’s native identity, federated into GCP’s IAM without any GCP-specific static credential ever being generated for that external workload.

Azure Managed Identities provide the equivalent for Azure resources — a VM, a function, an App Service instance can have an identity automatically managed by Azure, with credentials retrieved and rotated transparently by the platform.

Why the static-key model is worse than it initially appears

A static key’s risk isn’t just “it might leak.” It’s that the key, once created, has no natural expiration and no built-in mechanism forcing anyone to verify it’s still needed or still appropriately scoped — it persists exactly as originally configured until someone actively intervenes. Combined with the fact that static keys are portable (they can be copied, embedded in code, committed to a repository, or exfiltrated and used from anywhere), a leaked static key gives an attacker exactly the same access the legitimate workload has, usable from anywhere, for as long as the key remains valid — which in practice is often indefinitely, since key rotation discipline tends to be inconsistent in most organizations.

Workload identity credentials, by contrast, are typically scoped to be usable only from the specific platform context that requested them, are short-lived by default, and require no manual rotation process to maintain that short lifespan — the security property comes from the architecture itself, not from an operational discipline that has to be maintained correctly over time.

Migrating from static keys to workload identity

Start with the highest-risk static credentials first — keys with broad permissions, keys used in externally reachable services, keys that have existed longest without rotation — rather than attempting a full simultaneous migration, which is often impractical across a large existing environment.

Confirm the workload’s actual runtime platform supports the corresponding identity mechanism before planning the migration — a workload running on a platform without native workload identity support (some older on-premises or hybrid setups) may need an intermediate solution, like a secrets manager with automated rotation, as a partial improvement rather than the full architectural change.

Update IAM policies to trust the workload identity mechanism specifically, scoped as narrowly as the static key’s replacement role should be — this is also a natural opportunity to right-size permissions that may have accumulated excess over the static key’s lifetime, rather than simply replicating the old key’s exact permission set under the new mechanism.

Decommission the static key only after confirming the workload identity path is fully functional, running both in parallel briefly if needed to avoid an availability gap, then removing the static credential entirely rather than leaving it as an unused, still-valid fallback.

A practical checklist

• Identify workloads still using static cloud credentials, prioritized by permission scope and exposure
• Confirm the platform-native workload identity mechanism available for each workload’s actual runtime environment
• Configure IAM trust relationships scoped narrowly to the specific workload identity, not broadly
• Migrate and verify functionality before decommissioning the static credential
• Treat any remaining static credential, after this process, as requiring active justification for why workload identity wasn’t a viable replacement

The shift from static keys to workload identity isn’t primarily about convenience, even though it does remove manual rotation overhead. It’s about changing the credential’s fundamental risk profile — from a portable secret that persists until someone acts, to an ephemeral one that expires by default.

Most identity security programs — MFA policies, access reviews, onboarding and offboarding workflows — were designed around a mental model of a human user logging in. Service accounts, API keys, workload identities, and now AI agents acting autonomously don’t fit that model cleanly, and in most organizations, they receive a small fraction of the governance attention human identities do, despite frequently outnumbering human users by a wide margin in any modern cloud environment.

Why non-human identities are structurally under-governed

There’s no natural offboarding trigger. A human employee leaving triggers an HR process that (ideally) disables their access. A service account has no equivalent event — it keeps functioning until someone specifically remembers it exists and decides to remove it, which, as covered in identity audits generally, tends to happen rarely and inconsistently.

Permissions get granted broadly because there’s no individual accountability pressure. Nobody feels personally exposed by over-provisioning a service account’s permissions the way they might hesitate to request excessive personal access — the account is abstract, its permissions feel like an infrastructure detail rather than a decision with a name attached to it.

They’re numerous enough that manual review doesn’t scale. A mid-sized cloud environment can easily have service accounts, API keys, and workload identities numbering in the thousands, dwarfing the human user count — manual, human-driven access review processes that work reasonably well for a few hundred employee accounts break down entirely at that scale.

AI agents introduce a new and distinct version of this problem

An AI agent with tool access — the ability to call APIs, execute code, modify data, or take actions on a user’s behalf — is a non-human identity with a property service accounts traditionally didn’t have: its actions aren’t fully deterministic from a static configuration. A service account does exactly what its code tells it to do, every time, in a way that’s auditable in advance. An AI agent’s specific actions depend on its inputs and its reasoning at runtime, which means the risk isn’t just “does this identity have too much permission” (the traditional over-provisioning question) but also “can this identity be manipulated, through its inputs, into using its legitimate permissions in unintended ways” — a genuinely new dimension that traditional service-account governance wasn’t built to address.

Excessive agency as the specific failure mode to watch for

The OWASP Top 10 for LLM Applications identifies excessive agency — granting an AI system more autonomy, tool access, or permission than the task actually requires — as a distinct risk category. It manifests in the same pattern as traditional over-provisioning (an agent given broad database write access when it only needs to read a specific table) but with an added risk surface: if that agent can be manipulated through its inputs (a classic prompt injection scenario) into taking actions using its own legitimate, unrevoked permissions, the excessive scope of those permissions determines how much damage a successful manipulation can cause. Scoping an agent’s tool access as narrowly as the task requires isn’t just good practice — it’s the primary control limiting what a successful manipulation of that agent can actually accomplish.

What actually needs to change in practice

Treat non-human identity inventory as seriously as human identity inventory, with the same expectation of knowing who or what owns each one, why it exists, and what it’s actually used for — an unowned service account is a governance gap in exactly the way an unowned human account would be treated as one.

Apply least privilege more aggressively to non-human identities than the current default, precisely because the absence of individual accountability pressure means the default outcome, without deliberate counter-effort, is over-provisioning.

Build offboarding triggers for non-human identities explicitly, rather than relying on someone remembering — tying service account lifecycle to the lifecycle of the project or integration it supports, so decommissioning the project has a corresponding, enforced step for its associated identities.

For AI agents specifically, scope tool access to the minimum the task requires, and treat any tool or API access an agent has as something that could be invoked through unintended input, not only through intended use — which means the permission scope itself, not just the intended behavior, needs to be defensible.

Extend credential hygiene practices — short-lived tokens over static keys, rotation, monitoring for anomalous usage — to non-human identities with the same rigor applied to human credentials, rather than treating a service account’s static, long-lived API key as an acceptable default simply because it’s not a human logging in.

The scale of the shift

As AI agents become more common in production systems — not just answering questions but taking actions, calling tools, and operating with standing permissions — the non-human identity population in most organizations is set to grow substantially further, and faster than most identity governance processes are currently equipped to track. Treating this as a known, generalizable identity problem (apply the same governance discipline, adapted for scale and for the new manipulation risk agents introduce) is a more tractable path than waiting for the population of ungoverned non-human identities to become large enough that a comprehensive retrofit is required under incident pressure.

An unused cloud identity — an IAM user nobody logs into anymore, a service account for a decommissioned integration, a role created for a migration that finished a year ago — is functionally identical to an unpatched vulnerability. It doesn’t matter that nobody on your team is using it. What matters is that its credentials still work, exactly as well, for anyone who happens to find them.

Why unused identities accumulate

Identities get created deliberately and removed by nobody’s default responsibility. Offboarding processes, when they exist, usually focus on disabling a departed employee’s primary login — they less consistently catch the service accounts that person set up, the API keys they generated for a one-off script, or the IAM role created specifically for a project that’s since been shelved. Each of these represents a valid credential that continues to function indefinitely unless something explicitly removes it, and nothing about normal operations naturally surfaces “this hasn’t been used in months” as a signal anyone acts on.

Finding unused identities with activity data, not assumption

AWS IAM Access Analyzer’s unused access findings directly surface unused IAM roles, unused access keys on IAM users, and unused passwords, based on actual observed activity rather than requiring manual review of every identity. This turns “which of our hundreds of IAM users and roles are stale” from a guessing exercise into a query against real usage data.

Cloud provider “last accessed” and “last used” metadata exists across most major providers for service accounts, API keys, and roles — checking this directly, even without a dedicated unused-access tool, gives a concrete date rather than relying on institutional memory about whether something is still needed.

Cross-referencing identity lists against current employee and vendor rosters catches accounts that should have been disabled during offboarding but weren’t — this requires connecting your identity provider’s audit data to your HR or vendor management system, which isn’t automatic in most setups but is one of the highest-value manual checks available.

Service identities deserve more scrutiny than human ones, not less

Service accounts and machine identities often get created with broader permissions than strictly necessary, because there’s no individual human whose access needs feel personally accountable — nobody wants to be the reason a batch job fails from insufficient permissions, so the path of least resistance is granting broadly. Combined with the fact that service accounts don’t have an obvious “this person left the company” trigger to prompt review, they tend to accumulate both excess permission and staleness at a higher rate than human accounts, while receiving less routine attention.

What to do once you’ve found unused identities

Don’t delete immediately — deactivate first, and observe. An identity that appears unused in your analysis window might back an infrequent process (a quarterly compliance export, an annual data migration script) that simply hasn’t run recently. Deactivating (disabling the credential without deleting the identity) and monitoring for any access failures over a follow-up period is safer than immediate deletion, and still closes the exposure during the observation window.

Extend your observation window for anything ambiguous. Thirty days of “unused” data is a reasonable default for continuously-running services, but insufficient for anything tied to quarterly, annual, or on-demand processes — check with the team that would own the process before treating a longer-cycle identity as confirmed unused.

Prioritize by permission scope, not just by staleness. An unused identity with narrow, low-impact permissions is a lower-priority cleanup than an unused identity holding broad administrative access — if you can only tackle a subset immediately, start with the ones that would matter most if found and used maliciously.

Building this into an ongoing process, not a one-time cleanup

A single cleanup pass reduces the current backlog but doesn’t stop new unused identities from accumulating going forward, since the same organizational gaps that created the current backlog — no clear ownership of removing access when it’s no longer needed — remain in place afterward. A recurring quarterly (at minimum) review, ideally automated through a tool that surfaces unused-access findings continuously rather than requiring someone to remember to run an audit, keeps the backlog from silently rebuilding.

A practical checklist

• Run cloud-native unused access tooling (like AWS IAM Access Analyzer) as a recurring process, not a one-time audit
• Cross-reference identity lists against current employee and vendor rosters to catch offboarding gaps
• Apply extra scrutiny to service and machine identities specifically, since they accumulate excess more often and get reviewed less
• Deactivate before deleting, with an observation period for anything not obviously safe to remove immediately
• Prioritize cleanup by permission scope and blast radius, not purely by how long an identity has been idle
• Establish a recurring cadence for this review, not a one-time project, since the conditions that create unused identities don’t go away after a single cleanup

The goal isn’t a one-time reduction in identity count. It’s closing the gap between “how many valid credentials exist” and “how many are actually needed,” on an ongoing basis, since that gap is where a meaningful share of real incidents originate.

Traditional network security assumed a defensible boundary: a corporate network with a firewall at the edge, internal traffic implicitly more trusted than external traffic, and access controlled largely by what network segment you could physically or logically reach. Cloud environments break this assumption structurally — most cloud resources are reachable over the public internet by design, and what actually stands between an attacker and your data is increasingly a permission check evaluated by an identity provider, not a network path blocked by a firewall.

Why the network perimeter stopped being the primary boundary

In a cloud environment, an S3 bucket, a database, or an API endpoint is often reachable from anywhere on the internet unless explicitly restricted — and even when network restrictions exist, they’re frequently permissive by necessity, since legitimate access (from developers, from other cloud services, from users) also needs to traverse the same public internet. This means the network layer, while still worth hardening, isn’t where most access decisions actually get enforced anymore. The enforcement point has moved to IAM: does this identity have permission to perform this action on this resource, evaluated per-request, regardless of what network path the request arrived on.

What this changes practically

A compromised credential now matters more than a compromised network position. In a traditional perimeter model, gaining access to the internal network was often the hard part of an attack, after which lateral movement was comparatively easier. In a cloud environment, an attacker with a valid but overprivileged credential can often reach exactly what they need directly, without needing to compromise any network boundary at all — the credential itself is the boundary that mattered.

Least privilege on identities does the work that network segmentation used to do. Where network segmentation limited blast radius by controlling what a compromised machine could reach on the network, IAM scoping limits blast radius by controlling what a compromised identity can do regardless of where it’s calling from. A tightly scoped IAM role with no meaningful network restriction is often a stronger control than a broad IAM role sitting behind a well-segmented network, because the segmentation doesn’t stop a legitimately-authenticated call from an already-compromised identity.

Service-to-service authentication is now an identity problem, not just a network problem. Whether one internal service can call another used to be substantially a network question (can it reach the right port on the right host). It’s increasingly an identity question — does this specific service’s identity have a role or token that authorizes this specific call — which is why workload identity and service-to-service authentication design has become a first-class security concern rather than an implementation detail.

Where network controls still matter

This isn’t an argument that network security has become irrelevant — it remains a meaningful additional layer, particularly for defense in depth and for reducing the attack surface an identity-layer compromise can reach. Network policies (in Kubernetes, in VPC security groups) that restrict which services can even attempt to communicate reduce the paths available to an attacker who has compromised one workload, even if IAM would separately block the attempt. The point isn’t that network controls are obsolete — it’s that they’re no longer sufficient on their own, and organizations that invest heavily in network segmentation while leaving IAM broadly permissive are protecting the boundary that matters less while underinvesting in the one that matters more.

Where teams still get the balance wrong

Treating “inside the VPC” as equivalent to “trusted.” A service reachable only from within a VPC still needs proper authentication and authorization for calls it receives — network placement isn’t a substitute for verifying who’s calling and what they’re allowed to do, since anything else inside that VPC (including a compromised workload) can also reach it.

Investing in network monitoring while IAM policies go unreviewed. Network traffic monitoring and intrusion detection get regular attention in many security programs, while IAM policy review — auditing for unused, overprivileged, or stale permissions — happens far less consistently, despite IAM misconfiguration being a more direct path to most cloud breaches than a network-layer compromise.

Assuming a well-configured security group compensates for an overprivileged role. A database with a restrictive security group but a service account holding broad, unscoped permissions to it is still exposed to anything that compromises that service account — the network restriction only helps against threats arriving from an unexpected network path, which is a shrinking fraction of realistic cloud attack scenarios.

The practical implication

Security effort in cloud environments should be weighted toward identity: least-privilege IAM policies, short-lived credentials over static ones, strong authentication for service-to-service calls, and continuous auditing of what every identity can actually do. Network controls remain a legitimate and useful additional layer, but they’re the secondary boundary now, not the primary one — and a security program still organized as if the network perimeter is the main line of defense is protecting against yesterday’s most common attack path more than today’s.

A static cloud credential — an AWS access key, a GCP service account key — stored as a GitHub Actions secret has one fundamental property that makes it a standing risk: it remains valid until someone actively notices it shouldn’t be and rotates it. OpenID Connect (OIDC) support in GitHub Actions removes that credential from the equation entirely, replacing it with a token that’s short-lived by design and requires no manual rotation discipline to stay safe.

How the exchange actually works

When a workflow configured for OIDC runs, GitHub’s Actions runner requests a JSON Web Token (JWT) from GitHub’s own OIDC provider (token.actions.githubusercontent.com). This token contains claims about the workflow run — which repository, which branch or ref, which workflow file — and is signed by GitHub. The workflow then presents this token to the cloud provider (AWS STS, for example), which has been configured ahead of time to trust GitHub’s OIDC provider and to check specific claims in the token before issuing temporary credentials. If the claims match what the trust policy expects, the cloud provider issues short-lived, scoped credentials good only for that specific workflow run.

No static credential is stored anywhere in this flow. The only thing GitHub holds is a role ARN or equivalent identifier telling it which role to request — the actual authentication happens fresh, per run, through the signed token exchange.

Setting up the AWS side of the trust relationship

Configuring this requires two things in AWS: registering GitHub’s OIDC provider as a trusted identity provider in IAM, and creating an IAM role with a trust policy that specifies exactly which GitHub repositories (and optionally, which branches or environments) are allowed to assume it. A typical trust policy condition restricts the sub claim to a specific pattern like repo:your-org/your-repo:ref:refs/heads/main, meaning only workflow runs on that exact branch, in that exact repository, can successfully assume the role — a workflow run from a fork, or from a different branch, will have a token with a sub claim that doesn’t match, and the assume-role call will simply fail.

This scoping is what makes OIDC meaningfully more secure than a static credential even beyond the “no long-lived secret” property — the trust relationship itself constrains which workflows can even attempt to use it, rather than relying on the credential’s holder being trustworthy by assumption.

The workflow-side configuration

The workflow needs explicit permissions: id-token: write set — this is the permission that allows the job to request an OIDC token from GitHub in the first place, and it’s not granted by default even when other broad permissions are set. Combined with an action like aws-actions/configure-aws-credentials, specifying the target role’s ARN, the workflow requests the token, performs the exchange with AWS STS, and receives temporary credentials scoped to that role — all without a static AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY appearing anywhere in the workflow or in GitHub’s secret storage.

Why the “short-lived” property matters beyond convenience

A leaked static credential is a live problem until someone notices and rotates it — which could be minutes or months, depending entirely on whether monitoring catches the exposure. An OIDC-issued credential, even if somehow captured mid-flight during a specific run, expires on its own shortly after that run completes, typically within the hour. This changes the actual risk calculus: the attacker’s usable window is bounded by design, rather than bounded by however quickly your team happens to detect and respond to a leak.

What OIDC does not solve

OIDC removes the specific risk of a long-lived credential leaking from CI storage. It doesn’t address other CI/CD security concerns: a compromised workflow can still assume the role and act with whatever permissions that role grants during its valid window, so scoping the IAM role’s own permissions narrowly still matters exactly as much as it did with static credentials. It also doesn’t protect against a malicious pull request modifying the workflow file itself to add unauthorized steps, if the workflow’s trigger configuration allows untrusted code to influence what runs — that’s a separate class of risk (pull_request_target misuse, in particular) that OIDC doesn’t touch.

Multi-cloud and cross-provider considerations

AWS, Google Cloud, and Azure all support this pattern under slightly different names (AWS calls it “Web Identity Federation,” GCP calls it “Workload Identity Federation”) but the underlying mechanism — trusting GitHub’s OIDC provider and issuing short-lived credentials based on token claims — is conceptually the same across all three. If your pipeline deploys to multiple clouds, this pattern is worth implementing consistently across all of them rather than only for whichever provider had the most convenient existing tutorial.

A practical checklist

• Register GitHub’s OIDC provider in your cloud provider’s IAM configuration
• Write the trust policy’s conditions narrowly — specific repository, specific branch or environment, not a broad wildcard match
• Set permissions: id-token: write explicitly on any workflow using OIDC
• Remove any existing static cloud credentials stored as GitHub secrets once OIDC is confirmed working, rather than leaving both in place indefinitely
• Scope the IAM role’s own permissions narrowly — OIDC changes how the credential is obtained, not how much access the resulting credential should have

Migrating from static credentials to OIDC is one of the highest-leverage changes available for CI/CD security, precisely because it eliminates an entire category of leak (a long-lived secret sitting in storage) rather than just making that category harder to exploit.

Overprivileged IAM identities rarely come from one obviously bad decision. They come from a hundred individually reasonable ones — a broad policy attached during setup, a permission added to unblock a deploy, a role copied from a template that itself was never trimmed. The result is an environment where almost every identity has more access than it uses, and nobody can say with confidence which ones without checking.

Start with what’s provably unused, not what looks risky

Guessing which roles are overprivileged by reading policy documents doesn’t scale and misses the point — a policy can look reasonable on paper and still grant access nothing has touched in a year. IAM Access Analyzer’s unused access findings are built for exactly this: it surfaces unused roles, unused access keys, unused passwords, and — most usefully — the specific unused services and actions within an otherwise-active identity’s policy, based on real activity data rather than a manual read of the JSON.

This reframes the question from “does this policy look too broad” to “what has this identity actually never used,” which is both more concrete and harder to argue with when you bring findings to a team that owns the resource.

Cross-reference with CloudTrail for the identities Access Analyzer won’t fully cover

Access Analyzer’s unused-access findings are strong for standing IAM users and roles but won’t capture every nuance of activity, especially for identities used inconsistently or through cross-account access patterns. For those, CloudTrail’s event history lets you query what a specific principal has actually called over a given window — filtering by user identity ARN and looking at the distinct set of API actions invoked is a direct way to compare “granted” against “used” for any identity you’re specifically concerned about.

Compare against role purpose, not just activity

An identity can be actively using every permission it has and still be overprivileged, if the permissions it’s using go beyond what its actual job requires. This shows up most often in service roles: a Lambda function that only needs to read from one S3 bucket but was granted broad s3:* access because it was faster to configure. Activity-based tooling won’t flag this, because the access is being used — just more broadly than necessary. This requires pairing the automated findings with a manual pass asking “does this identity’s actual function justify this scope,” particularly for any role with wildcard resources or actions.

Prioritize by blast radius, not by count

Once you have a list of overprivileged identities, tackling them in the order you found them wastes effort on low-stakes fixes while high-risk ones wait. Rank by what the identity could do if compromised, not by how many unused permissions it has — a role with three unused but highly sensitive permissions (like iam:CreateUser or kms:Decrypt on a broad key set) deserves attention before a role with twenty unused but low-impact ones.

A practical checklist

• Run IAM Access Analyzer’s unused access analysis across every account, not just production
• Query CloudTrail directly for any identity Access Analyzer’s findings don’t fully cover
• Cross-check active-but-broad permissions against the identity’s actual functional purpose, not just usage data
• Rank remediation by potential blast radius, not by finding volume
• Treat any identity with wildcard actions or resources as a priority review, regardless of what usage data shows

Finding overprivileged identities is a data problem before it’s a policy-writing problem. The tooling to answer “what’s actually being used” already exists in most AWS accounts — the gap is usually that nobody’s running it on a recurring basis, not that the answer is hard to get.

Least privilege fails in practice for a simple reason: granting permissions is a one-time decision made under uncertainty, and revoking them requires confidence that nothing will break. Most teams grant broadly upfront because they don’t know exactly what a role will need, and then never revisit it, because finding out what’s actually being used requires visibility that doesn’t exist by default.

Why permissions accumulate

Roles and users rarely lose permissions once granted. Common patterns:

• A role gets AdministratorAccess or a broad managed policy during initial setup “to unblock things,” with a plan to tighten it later that never happens
• A permission was needed for a one-time migration or debugging session and was never removed afterward
• A service’s responsibilities changed, but its IAM policy was never updated to match — it still holds access relevant to what it used to do
• Permissions get copied from an existing role as a starting template, inheriting whatever excess that role had accumulated

None of these are unusual mistakes. They’re the predictable result of granting being cheap and auditing being expensive, unless you have tooling that makes the audit cheap too.

Finding unused access with IAM Access Analyzer

AWS IAM Access Analyzer’s unused access analysis is built specifically for this problem. Once enabled, it continuously analyzes accounts and surfaces:

• Unused IAM roles
• Unused access keys on IAM users
• Unused passwords on IAM users
• For active roles and users, specific unused services and actions within their attached policies

This last category is the one that matters most for least privilege work — it doesn’t just tell you a role exists and might be over-permissioned in theory, it tells you which specific granted permissions haven’t actually been exercised, based on real access activity. Findings consolidate into a centralized dashboard, so security teams can prioritize accounts by finding volume instead of manually reviewing every policy by hand.

Two details from AWS’s documentation that change how you plan this work. First, the unused access analyzer has a configurable tracking period of 1 to 365 days, and it only evaluates entities that have existed for the whole period (AWS docs: create an unused access analyzer). Second, unused access analysis is a paid feature billed per IAM role or user analyzed per month, unlike external access findings, which are free (AWS pricing page). Check the pricing page for the current rate in your region.

Turning findings into safe policy changes

Finding unused permissions is the easy part. Removing them without breaking something is where teams get cautious, and reasonably so — an unused-in-the-analysis-window permission isn’t necessarily an unused-forever permission if it backs an infrequent process like a quarterly batch job or an annual compliance export.

A safer sequence:

1. Extend the observation window before acting on any single finding — a permission unused in a 30-day window might still be legitimate for something that runs monthly or quarterly
2. Cross-reference against known infrequent processes — check with the team that owns the role about anything that runs on a schedule longer than your analysis window before removing access tied to it
3. Use policy generation, not just manual editing — Access Analyzer policy generation builds a policy template from the actions an entity performed in your CloudTrail logs over a period of up to 90 days, which is a better starting point than hand-editing an existing broad policy. It has limits: it needs a CloudTrail trail, it does not identify action-level activity for data events such as S3 object reads, it does not include iam:PassRole (CloudTrail does not track it), and it counts denied actions as activity. Review the generated template rather than attaching it as-is (AWS docs: policy generation)
4. Apply changes in a way that’s reversible — deploy the tightened policy, monitor for access denials over a follow-up period, and keep the prior policy version available to roll back quickly if something legitimate breaks

Where least privilege breaks down structurally

Two patterns undermine least privilege even with good tooling:

Wildcard actions and resources. A policy using "Action": "s3:*" or "Resource": "*" defeats granular analysis because it’s technically “using” a category of permission broadly enough that unused-access tooling has less to work with. Scoping policies to specific actions and specific resource ARNs, rather than wildcards, is what makes the analysis actually useful later.

Shared roles across multiple purposes. A single role used by several different services or functions accumulates the union of everything any of them needs, and removing anything requires confirming none of the other consumers depend on it. Splitting roles by function, even when it means more roles to manage, keeps each one’s actual permission needs legible.

A practical checklist

• Enable IAM Access Analyzer’s unused access analysis across your accounts, not just external access analysis
• Prioritize review by finding volume, starting with roles holding the broadest permissions
• Extend your observation window before removing access tied to infrequent processes
• Replace wildcard actions and resources with specific ARNs and actions where feasible
• Split multi-purpose shared roles so permission needs stay attributable to a single function
• Treat policy tightening as a monitored, reversible change, not a one-way cutover

Least privilege isn’t a policy you write once. It’s a permissions posture that decays by default unless something is actively pulling it back toward minimal, which is what continuous unused-access analysis is actually for.

Turn on all four S3 Block Public Access settings at the account level in every AWS account, or, if you use AWS Organizations, enforce them with an organization policy so no account can switch them off. Then look for buckets created before April 2023, because AWS’s private-by-default change only applied to new buckets. The rest of this article explains what each setting does, because the names are similar and the differences matter when something stops working.

The four settings

AWS describes four independent settings. Two act when someone tries to make something public; two act on what is already public.

An ACL (access control list) is the older per-bucket and per-object permission mechanism in S3; a bucket policy is the JSON resource policy attached to a bucket.

The pairs matter. BlockPublicPolicy alone stops a new public policy but leaves an existing one working. RestrictPublicBuckets alone neutralizes an existing public policy but lets someone attach a new one. AWS recommends turning on all four.

One warning from AWS’s documentation is worth repeating: “Block public access settings don’t alter existing policies or ACLs. Therefore, removing a block public access setting causes a bucket or object with a public policy or ACL to again be publicly accessible.” The settings are a shield over your policies, not a cleanup of them.

What S3 counts as “public”

S3 uses its own definition, and it is stricter than “allows everyone”.

• ACLs. An ACL is public if it grants any permission to the AllUsers or AuthenticatedUsers groups. AuthenticatedUsers means any AWS account holder, not users in your account.
• Bucket policies. S3 starts by assuming a policy is public, then checks whether it qualifies as non-public. To be non-public, a policy must grant access only to fixed values, with no wildcard and no IAM policy variable, for things such as specific AWS principals, aws:SourceIp address ranges, or conditions like aws:SourceVpc, aws:SourceArn and aws:SourceAccount.

AWS’s documentation gives an example: a policy granting "Principal": "*" with the condition "StringEquals": {"aws:SourceVpc": "vpc-91237329"} is non-public, because the VPC ID is fixed. The same policy using StringLike with a wildcard VPC value is public.

Where the settings apply, and which wins

You can set Block Public Access on an access point, a bucket, an AWS account, and, since November 2025, across an organization. AWS’s rule for overlapping settings is simple: S3 “applies the most restrictive combination”. If the account blocks public policies, no bucket in that account can be made public through a policy, whatever the bucket’s own setting says.

This is why the account level is where to start. One command covers every existing and future bucket in the account:

aws s3control put-public-access-block \
    --account-id 123456789012 \
    --public-access-block-configuration '{"BlockPublicAcls": true, "IgnorePublicAcls": true, "BlockPublicPolicy": true, "RestrictPublicBuckets": true}'

The command needs the s3:PutAccountPublicAccessBlock permission. AWS’s CLI reference notes that it can return an access-denied error when the account is governed by an organization-level policy, because that policy takes over account-level settings.

To check a single bucket’s own settings:

aws s3api get-public-access-block --bucket amzn-s3-demo-bucket

AWS’s API reference cautions that this returns the bucket-level configuration only; the effective behavior also depends on the account and organization settings.

Access points behave differently

AWS notes two details for S3 access points. Their Block Public Access settings can only be set when the access point is created and cannot be changed afterward. And an access point whose network origin is a VPC is always treated as non-public, whatever its policy says.

Enforcing it across an organization

On November 26, 2025, AWS announced organization-level enforcement for S3 Block Public Access. You attach an AWS Organizations S3 policy at the root, at an organizational unit or to specific accounts, and new member accounts inherit it. AWS states there is no additional charge. AWS’s policy syntax documentation shows the whole policy:

{
    "s3_attributes": {
        "public_access_block_configuration": {
            "@@assign": "all"
        }
    }
}

The value is "all" or "none". The organization level is all or nothing: it turns the four settings on or off together. AWS’s documentation adds that if you want to manage the settings per account, you should disable the S3 policy type at the organization level.

For a multi-account estate, this is the strongest form of the control, because an administrator inside a member account cannot turn it off. That is our reading of the design rather than an AWS claim. Before attaching it, find any account that legitimately serves public content from S3 and move that content behind CloudFront first.

The April 2023 default, and what it did not change

In December 2022, AWS announced two changes that took effect from April 2023: newly created buckets would have Block Public Access enabled, and ACLs disabled through the “bucket owner enforced” Object Ownership setting. AWS said the console already used both defaults, and the change extended them to buckets created through the S3 API, CLI, SDKs and CloudFormation. An update dated April 27, 2023 says the settings then applied to all new buckets in all AWS Regions.

The announcement describes newly created buckets only. A bucket created in 2021 with a public policy keeps it until someone acts. The places to look first:

• AWS accounts older than 2023, especially ones nobody owns any more.
• Buckets created by older infrastructure-as-code modules that set the bucket ACL or policy explicitly.
• Accounts where someone turned the account-level setting off to make one website work.

Auditing an account

AWS Security Hub has four controls that cover this, if you use it:

IAM Access Analyzer for S3 also reports buckets that grant access to anyone on the internet or to other AWS accounts. AWS notes that in rare cases Access Analyzer and the Block Public Access evaluation can disagree on whether a bucket is public.

If you do not use either service, this Python script with boto3 reports the gaps in one account. It only reads configuration. It is illustrative: we tested its logic with botocore’s Stubber against simulated responses, not against a live AWS account.

"""Report S3 Block Public Access gaps in one AWS account (read-only)."""
import boto3
from botocore.exceptions import ClientError

SETTINGS = ("BlockPublicAcls", "IgnorePublicAcls", "BlockPublicPolicy", "RestrictPublicBuckets")
MISSING = "NoSuchPublicAccessBlockConfiguration"


def block_config(fetch) -> dict:
    """Return the four settings, treating 'not configured' as all False."""
    try:
        return fetch()["PublicAccessBlockConfiguration"]
    except ClientError as e:
        if e.response["Error"]["Code"] == MISSING:
            return {k: False for k in SETTINGS}
        raise


def audit(session=None) -> list[str]:
    session = session or boto3.Session()
    account_id = session.client("sts").get_caller_identity()["Account"]
    s3control = session.client("s3control")
    s3 = session.client("s3")

    findings = []
    account = block_config(lambda: s3control.get_public_access_block(AccountId=account_id))
    off = [k for k in SETTINGS if not account.get(k)]
    if off:
        findings.append(f"account {account_id}: off at account level: {', '.join(off)}")

    for bucket in s3.list_buckets()["Buckets"]:
        name = bucket["Name"]
        cfg = block_config(lambda: s3.get_public_access_block(Bucket=name))
        # Effective setting is the most restrictive of account and bucket.
        effective_off = [k for k in SETTINGS if not (cfg.get(k) or account.get(k))]
        try:
            is_public = s3.get_bucket_policy_status(Bucket=name)["PolicyStatus"]["IsPublic"]
        except ClientError as e:
            if e.response["Error"]["Code"] != "NoSuchBucketPolicy":
                raise
            is_public = False
        if is_public or effective_off:
            findings.append(f"bucket {name}: policy public={is_public}; "
                            f"effectively off: {', '.join(effective_off) or 'none'}")
    return findings


if __name__ == "__main__":
    for line in audit():
        print(line)

GetBucketPolicyStatus returns IsPublic: true when S3 considers the bucket’s policy public. Known limits of the script:

• It does not read organization-level policies, so an account protected only by an organization policy may be reported as “off”.
• It does not paginate the bucket list or handle buckets in Regions that need a regional client, which matters for large accounts.
• The missing-configuration error code is taken from the AWS SDK’s model for the account-level API; we did not confirm the bucket-level code against a live account.
• It checks policies and settings, not ACLs on individual objects.

If you need public content

Serving a website straight from a public bucket is the main reason people switch these settings off. AWS’s recommended alternative is CloudFront with origin access control (OAC): the bucket stays private and a bucket policy grants read access only to your CloudFront distribution. AWS recommends OAC over the older origin access identity (OAI), citing support for all Regions including those launched after December 2022, for SSE-KMS encryption, and for PUT and DELETE requests. The bucket policy looks like this, with your own bucket name, account ID and distribution ID:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipalReadOnly",
      "Effect": "Allow",
      "Principal": {"Service": "cloudfront.amazonaws.com"},
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
        }
      }
    }
  ]
}

Because the condition uses a fixed AWS:SourceArn value, S3 treats this policy as non-public under the definition above, so it works with all four settings on.

Block Public Access does not cover everything. AWS’s documentation advises also checking identity-based policies on IAM roles and resource-based policies on related resources such as KMS keys. For why per-bucket checklists rarely keep up across many accounts, see why cloud misconfiguration checklists don’t work.

Sources and verification

Checked on October 8, 2026. We did not run the CLI commands or the audit script against a live AWS account.

Passwords and passkeys get compared as if they’re two options on the same axis, usually framed as “convenience versus security.” That framing undersells what actually changes. A password is a shared secret: both the user and the server know a value derived from it, and anything either party can be tricked into revealing can be replayed. A passkey, built on the FIDO2/WebAuthn standard, removes the shared secret entirely and replaces it with a public-private key pair, where the private key never leaves the user’s device.

Why this isn’t just “a stronger password”

The practical difference shows up during a phishing attempt. A password (or a one-time code from SMS or an authenticator app) can be typed into a convincing fake login page, and the attacker relays it to the real site in real time — this is how adversary-in-the-middle phishing kits defeat traditional MFA. A passkey can’t be phished this way, because the cryptographic challenge generated during login is bound to the actual origin (the domain) the browser is talking to. If a user lands on a lookalike domain, the browser and authenticator simply won’t produce a valid signed assertion for it — there’s no code or value for the user to accidentally hand over, because nothing reusable is ever transmitted.

This is why NIST’s SP 800-63B digital identity guidelines specifically describe WebAuthn as phishing-resistant through this verifier-origin binding, rather than relying on the user noticing something looks wrong.

Where the protection actually breaks

Passkeys only preserve this property end to end. Two places commonly undo it:

Recovery paths. If losing a passkey means falling back to an email link or an SMS code to regain access, the account’s real security level is whatever that fallback provides, not what the passkey provides. Attackers target the weakest link in the chain, and a phishing-resistant primary factor with a phishable recovery path is still a phishable account.

Enrollment. A passkey is only as trustworthy as the process that registered it. If an attacker can register their own passkey on a compromised account (through a stolen session, a support-desk social engineering call, or a weak initial verification step), the passkey itself does nothing to stop them going forward — it just becomes their credential now, not the legitimate user’s.

What actually changes operationally for a security team

• Help desk load shifts, it doesn’t disappear. Password resets get replaced by device-loss and recovery-flow support requests. If your recovery flow is weak, this becomes a new social-engineering target rather than a solved problem.
• Device and platform coverage matters. Passkeys sync differently across Apple, Google, and Microsoft ecosystems, and cross-platform sync behavior affects how you think about account recovery and device offboarding when someone leaves.
• Not every login surface supports it yet. Legacy internal tools, some enterprise SaaS admin panels, and API-based service accounts often can’t use WebAuthn at all, so passkeys typically roll out unevenly across an org’s actual login surface rather than replacing passwords everywhere at once.
• It doesn’t replace authorization controls. A phishing-resistant login says nothing about what that authenticated session can then do — least-privilege access control still matters exactly as much after passkeys as before.

Rollout priority, not rollout completeness

Given uneven support, the highest-value place to start is the accounts where phishing has the most consequence: administrators, finance roles, and anyone with standing access to sensitive systems — not a company-wide simultaneous cutover. Pair the rollout with hardening the recovery path (no email or SMS fallback for high-privilege accounts) and verifying enrollment requires strong initial proof of identity. Without both of those, you’ve changed the login screen without actually closing the attack path it was meant to close.

If you run ZITADEL, the open-source identity platform, check the version number today. Three critical flaws, each of which lets an attacker take over someone else’s account, were fixed in releases between mid-July and early September 2026, but their CVE records were published on October 4, 2026. Anything older than 4.17.3 is affected by at least one of them, and ZITADEL 3.x has no fix for the most serious one.

This article lays out which versions are affected by each flaw, what each requires from an attacker, and which questions to ask of your own logs. It is based on ZITADEL’s GitHub security advisories and the CVE records; we did not install ZITADEL or test any of the flaws.

The three flaws

All three are authorization or verification failures around how an account gets tied to a login method. The details come from ZITADEL’s advisories, and the dates and CVSS 4.0 scores from the CVE records, which were published by VulnCheck, acting as CVE Numbering Authority (the organization authorized to issue the CVE IDs).

An IdP (identity provider) is an external service such as a company directory or social login that vouches for a user’s identity. A passkey is a phishing-resistant sign-in credential bound to a device, covered in our comparison of passkeys and passwords.

What each one means in practice

CVE-2026-105207 is the broadest. ZITADEL’s advisory says an attacker who knows only a victim’s login name can bind their own external identity to the victim’s account through the Login V2 identify-only session, then sign in as the victim. The same weakness is reachable through the API endpoint that adds IdP links, so changing the login screen does not close it. The advisory says it needs no authentication, no privileges and no user interaction. If your instance allows external IdP sign-in at all, treat this as the priority.

CVE-2026-105209 matters most for multi-tenant setups. If you use separate ZITADEL organizations for separate customers or business units on one instance, an administrator in one organization could obtain an enrollment code for a user in another and register their own authenticator. The attacker needs a legitimate foothold first, so for a single-organization company the realistic threat is an insider or a compromised administrator account. For a service that gives each customer an organization, a customer administrator is a possible attacker.

CVE-2026-105215 is a pre-hijack. The attacker creates an account in advance, bound to the victim’s external identity. The victim’s first genuine sign-in through that IdP then lands in the attacker-prepared account. It needs the victim’s external user ID, which the advisory says may be known or predictable, and only Login V1 is affected.

When the fixes actually shipped

The CVE records were published on October 4, 2026; two of them (CVE-2026-105209 and CVE-2026-105215) were updated on October 5. The fixes are older. The “public” dates in the CVE records are July 29, August 14 and September 4, 2026 for CVE-2026-105215, CVE-2026-105209 and CVE-2026-105207, respectively. ZITADEL’s releases page lists 3.4.15 and 4.17.1 as released August 14, 2026 and 4.17.3 as released September 4, 2026, which matches. It lists 4.16.2 and 3.4.14 as released July 29, 2026, which also matches.

Two consequences follow. First, an organization that kept to a routine upgrade cadence may already be on a fixed build without having seen any alert. Second, an organization that skipped those releases has been exposed for weeks to flaws whose fixes were public, and the CVE publication on October 4 makes the technical detail easier for others to find. Whether anyone used them in that window is something we found no reporting on.

Where the sources disagree or are unclear

• Version ranges for CVE-2026-105207. ZITADEL’s advisory lists 3.0.0 through 3.4.15 and 4.0.0 through 4.17.2 as affected, with 4.17.3 as the fix. The CVE record’s text agrees, but its structured data also contains a second block that lists versions up to and including 4.19.4 as affected. That contradicts the advisory, which names 4.17.3 as the fixed release, and would flag a patched 4.19.4 server in any scanner that reads that field. We treat the advisory as authoritative and note the record’s data as inconsistent; we have not seen a correction.
• Severity numbers. A widely circulated summary lists the three flaws as 9.8, 9.6 and 9.1. Those are the CVSS 3.1 scores. On CVSS 4.0, which the CVE records also carry, all three score 9.3. The two are different scales and should not be compared against each other.
• What “latest” is. The newest release we found on October 6 was 4.19.4, dated October 1, 2026. The release notes for 4.19.2 (September 28, 2026) say it addresses three further vulnerabilities: two rated High, both account takeover issues (advisories GHSA-x4c7-fpcx-w9q6 and GHSA-jh92-5mrj-p2w2), and one rated Low (GHSA-w4gv-rcwj-w6r5). We did not review those advisories in detail, and they are separate from the three CVEs covered here.

What to do, in order

This sequence is our recommendation, built on ZITADEL’s advisories.

1. Find every instance and its version

Include development, staging and any instance that serves a single customer. Record whether it runs 3.x or 4.x, and whether Login V1, Login V2 or both are enabled, since that decides which flaws apply.

2. Upgrade to 4.17.3 or later, preferably the newest 4.x

Fixing all three requires at least 4.17.3. Given the further fixes in 4.19.2, aim for the newest 4.x release. One upgrade requirement to plan for: the 4.19.2 release notes say Login V2 now requires session cookie signing, that the ZITADEL_SESSION_COOKIE_SECRET environment variable (at least 32 characters) must be set before upgrading, and that users have to sign in again afterward. If you are on 3.x, plan the move to 4.x now: the advisory for CVE-2026-105207 says the 3.x line reached end-of-life on August 31, 2026 and will not be patched, so staying on 3.x leaves that flaw open. Test the upgrade first, because a major-version move can change login behavior.

3. If you must wait, apply the partial workarounds and limit exposure

ZITADEL lists two partial workarounds. Disabling external IdP account linking reduces the CVE-2026-105207 route through Login V2 but not the API route. Disabling manual account creation on external IdPs reduces CVE-2026-105215 but turns off legitimate self-service registration. For CVE-2026-105209 the advisory says no configuration workaround fully addresses it. Our own suggestion, not ZITADEL’s: where an instance is only used by staff, restricting it to a VPN or an allowlist of source addresses reduces the number of people who can reach the vulnerable endpoints, though it does not help against CVE-2026-105209, where the attacker is already an authenticated administrator.

4. Look for takeovers that already happened

Upgrading removes the flaw, not an attacker who has already taken an account. We did not verify ZITADEL’s log or event names, so use your own audit logs and match these questions to what they record:

• IdP links. Have any existing accounts gained an external IdP link that the owner did not create, especially since August 2026? A takeover through CVE-2026-105207 leaves a new link on the victim’s account.
• Passkey and passwordless enrollment. Were enrollment codes issued by an administrator in organization A for a user in organization B? Did any account register a new authenticator it did not request?
• Accounts created through external sign-in that no real person used. Pre-hijack accounts are created through the registration endpoint, with an external identity attached before the real person arrives.
• Sign-ins that follow one of those changes from an unfamiliar address or device.

If you find a suspicious link or authenticator, remove it, revoke the account’s active sessions and review what the account could reach. Our guide to detecting leaked keys and rotating them covers the follow-up for any secrets those accounts could read.

5. Keep the logs

Make sure identity-provider events are retained somewhere an attacker with administrator rights in one tenant cannot erase them. The reasoning is in our piece on logging for incidents rather than dashboards.

What this says about identity systems generally

The three flaws share one pattern, which is our reading, not ZITADEL’s: the system trusted a claim about who was acting without checking it where the change happened. In CVE-2026-105207 it was a link request, in CVE-2026-105209 a header naming an organization, and in CVE-2026-105215 identity fields supplied by the browser. When you review any identity platform, including a hosted one, ask where an account’s credentials can be added or changed, and what is checked at that exact step.

The timing is also a lesson. These are fixed-before-disclosed flaws, and the organizations hurt are those that treat identity software as set-and-forget. Put your identity provider on the same patch watchlist as your edge devices, and rank it using the approach in our vulnerability backlog piece.

Sources and verification

Checked on October 6, 2026. We did not install ZITADEL, test any flaw or review its source code. ZITADEL’s advisories and releases page were read through a page-summarizing tool; the CVE records were read directly from the CVE Program API. The affected-version lists, workarounds and release dates below should be checked against the primary pages before you act on them.

A security questionnaire filled out by a vendor’s sales or solutions team, then filed away unread, is the default third-party risk process at most companies — and it predicts almost nothing about actual risk, because the person answering it usually isn’t the person who built the system or knows its real failure modes.

Scope data access before you evaluate anything else

The single most useful vetting question isn’t “do you have SOC 2” — it’s “what data does this tool actually need, and does the integration request more than that.” OAuth scopes and API permissions requested during setup routinely exceed what the tool’s stated function requires, because broad defaults are easier for the vendor to build than granular ones. Reviewing the actual requested scopes against the tool’s job description, before granting access, catches over-permissioned integrations that a compliance questionnaire never asks about.

Compliance certifications tell you about process, not about your specific risk

SOC 2 and ISO 27001 are useful signals that a vendor has a security process, but they don’t tell you whether that process covers the specific way you’re using the tool, or whether a breach at the vendor would actually expose your data versus just their infrastructure. Ask vendors directly what a breach on their end would mean for your specific data — the quality and specificity of that answer is a better risk signal than the certification badge itself.

Offboarding is where most third-party risk actually lives

Vetting focuses entirely on the point of approval, but a large share of real incidents trace back to tools that were approved once, integrated deeply, and never revisited — accumulating access and dormant integrations for accounts nobody uses anymore. Build a recurring review (even annual) of what’s still connected and what access it still has, not just a one-time approval gate. An unused integration with live credentials is functionally identical to a live vulnerability, and most companies have several they’ve forgotten about.

MFA fatigue attacks — also called push bombing — don’t exploit a technical flaw. They exploit the fact that most MFA rollouts treat “any second factor” as good enough, when the factor’s design determines whether an exhausted employee at 11pm taps “approve” just to make the notifications stop.

Number matching isn’t optional anymore

Plain push approval (“tap yes or no”) is the weakest form of MFA still in wide use, precisely because it asks the user to make zero cognitive effort. Number matching — where the user has to type a code shown on the login screen into the push prompt — adds just enough friction to break the autopilot response that makes bombing effective. If your identity provider supports it, this is a config change, not a project, and it should be the default for every account, not an opt-in.

Phishing-resistant factors change the incentive, not just the defense

Number matching reduces bombing success rates, but it doesn’t touch attacks that pair the push spam with a live phishing page relaying real-time codes. FIDO2 security keys and passkeys remove this entire class of attack because the cryptographic challenge is bound to the origin domain — there’s no code to relay. Rolling these out for admin and finance roles first (the accounts actually worth targeting) gets you most of the risk reduction without a company-wide hardware rollout.

Rate-limit and alert on push volume, not just failed logins

Most detection stacks are tuned to flag failed authentication attempts, but a bombing attack looks like a string of successful prompt deliveries with no failures at all — the attacker already has valid credentials, they’re just waiting for a mis-tap. Add a specific alert for unusual push notification volume per user per hour, independent of your failed-login alerting, and rate-limit repeated prompts to the same device to cut off the exhaustion tactic entirely.

Most least-privilege initiatives stall for the same reason: security teams design the policy around what an auditor wants to see, not around how engineers request and use access day to day. The result is a system everyone routes around within a month.

Start with role mining, not role design

Before writing a single policy, pull 90 days of actual access logs and group people by what they use, not what their job title implies they should use. You’ll almost always find that job-title-based roles overprovision by 3-5x. Role mining gives you a baseline that reflects reality, which means the policy you eventually ship won’t immediately break someone’s workflow.

Time-bound elevated access by default

Standing admin access is the single biggest reason least-privilege programs get undone six months later — someone gets temporary access for an incident, and it never gets revoked because revocation isn’t anyone’s job. Build expiry into the request, not into a quarterly review. A 24-hour default that requires re-justification is far more durable than a 90-day access review that nobody actually reads.

Measure friction, not just coverage

Track how many access requests get approved without modification versus how many get pushback or take more than a day. If your approval time creeps up, engineers will start requesting broader roles “just in case” to avoid asking twice — which quietly reverses the entire program. Friction is a leading indicator that your policy has drifted from actual need.

The rollout order that works

1. Mine current usage, not job descriptions
2. Ship time-bound elevation before you touch standing roles
3. Narrow standing roles only after elevation data shows what’s actually needed
4. Review friction metrics monthly, formal access reviews quarterly

Teams that reverse this order — writing the policy first and measuring friction never — are the ones still running the same over-permissioned setup a year later, just with a nicer-looking spreadsheet.