ListKeys Action is an IAM permission that allows a principal to enumerate the access keys attached to an account or identity. It is commonly used in cloud control planes and can reveal active secrets, so it is normally tightly restricted and audited alongside key rotation and least-privilege policy controls.
What ListKeys Action Does
ListKeys Action is a control-plane permission that lets a principal enumerate the access keys attached to an account or identity. In practice, that means visibility into live secret material, so the permission is usually treated as sensitive administrative access rather than a routine read-only privilege.
The key point is that enumeration itself can be enough to change the security picture. Even when the action does not expose the secret values directly, it can reveal which identities still rely on long-lived keys, where rotation debt exists, and which accounts deserve stronger monitoring or removal.
Why It Is Security-Sensitive
Because access keys are bearer-like credentials in many cloud platforms, seeing that they exist can help an attacker target the next step in an intrusion chain. If the permission is too broad, an insider, compromised admin, or abused automation path may use it to inventory secrets and identify the easiest path to persistence.
In an identity and access model, this is closely related to credential governance, least privilege, and auditability. The danger is not just disclosure, but what that disclosure enables: faster secret harvesting, better targeting of key theft, and a cleaner map of exposed administrative surfaces.
How Organisations Check Exposure
Exposure review starts with an asset and identity inventory. Teams need to know which cloud accounts, roles, service principals, or workloads can call the action, whether those identities are intended to administer key lifecycle, and whether the permission is available from interactive sessions, automation, or delegated trust chains.
Reviewing cloud provider guidance is also essential, because the safest pattern often is to avoid shared key dependency altogether. The Azure Storage Security Guide is a useful example of the broader control pattern: minimise shared-key reliance, prefer tighter delegation models where available, and align enumeration rights with actual operational need.
For external reference, organisations should compare their own IAM design with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access control, authentication, and audit expectations, and with OWASP Non-Human Identity Top 10 where key lifecycle and overprivilege risks are part of the design.
Remediation, Detection, and Post-Exposure Review
When this permission exists, the first remediation question is whether it is actually needed. If not, remove it. If it is needed, constrain it to the smallest administrative boundary possible, log all usage, and pair it with strong review around key rotation, secret storage, and alerting on unexpected enumeration.
Detection should focus on unusual key-listing activity, especially from identities that normally do not manage credentials, from new geographies or hosts, or in bursts that suggest reconnaissance. After suspected abuse, review whether keys were copied, whether follow-on authentication occurred, and whether any sessions, tokens, or dependent automation accounts need to be rotated or revoked.
For the broader response model, NIST Privacy Framework can help structure governance around sensitive identity material, while NIST Cybersecurity Framework 2.0 gives a practical way to align identify, protect, detect, respond, and recover activities around exposed credentials.
Risk and Threat Considerations
ListKeys Action is risky because it turns secret inventory into an accessible control surface. Even without exposing the secret values themselves, the permission can help an attacker or careless operator identify where long-lived credentials exist, which accounts deserve attention, and where a future compromise will be easiest to sustain.
Failure mechanism: Excessive enumeration rights let a principal discover active keys, which supports credential targeting, secret sprawl mapping, and persistence planning after initial access.
Impact: Stolen or abused enumeration access can accelerate key theft, weaken containment, and increase the chance that sensitive accounts remain exposed after rotation or incident response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | ListKeys Action exposes credential inventory and supports key lifecycle control. |
| AC-6 — Least Privilege | The permission is a privileged enumeration capability that should be narrowly assigned. | |
| AU-6 — Audit Review, Analysis, and Reporting | Key enumeration is a sensitive event that should be logged and reviewed. | |
| Recommendation — Restrict and audit key-listing rights under IA-5 to protect authenticator lifecycle management. Apply AC-6 to limit key-listing access to the smallest set of administrators. Use AU-6 to review alerts and logs for unexpected key-enumeration activity. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Enumerating keys exposes secret inventory and increases leakage risk. |
| Recommendation — Limit key visibility to reduce secret leakage and discovery of active credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | The permission is part of account and credential administration. |
| Recommendation — Use CIS-5 to govern who can enumerate and manage account credentials. | ||
Practitioner Guidance
Governance implication: Treat this permission as a privileged control, not a convenience feature. Ownership should sit with the team that manages key lifecycle, and any exception should be time-bound, reviewed, and tied to a specific operational need.
Practitioner takeaway: If a principal can list keys, assume it can help shape the next compromise path, so review it with the same discipline you would apply to other credential-management privileges.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org