Look for role assumption patterns that should not normally occur in the environment. A query that groups activity by user, filters to a relevant time window, and counts actions can reveal whether one role is being used by multiple identities. That is a strong indicator worth investigating for credential compromise or shared access.
How to spot shared use of the same IAM role
The best signal is not the role name itself, but the pattern of assumptions behind it. If the same role is being assumed by multiple distinct identities in a short window, or by identities that should not normally converge, that is an access anomaly worth investigating. The practical test is to pivot from role-centric logs to user-centric attribution and time-bounded counting.
In AWS, that usually means analysing CloudTrail for AssumeRole events, then grouping by the calling identity, source account, source IP, session name, or principal context available in the log record. A role that appears to be “single-owner” in design but is assumed by several users, automation paths, or external principals can indicate either an operational sharing practice or a compromised credential path.
The query logic matters because role sessions are temporary and can look similar at the role level while hiding very different entry points. If you only count role usage, you can miss whether access is coming from one legitimate actor, many expected actors, or a small cluster that suggests credential reuse, delegated access, or stolen credentials.
For readers who need a deeper NHI and access-governance framing, Ultimate Guide to NHIs covers visibility, lifecycle, rotation, and offboarding, which are the controls that help explain why a role is being reused in the first place.
What the log pattern is really telling you
A clean role-assumption pattern should usually reflect a known operating model: one human operator, one automation path, or one documented integration. When the same IAM role is assumed by multiple users, the key question is whether that is intentional delegation or a sign that access boundaries have eroded. The answer often depends on whether the role is tied to an application, a break-glass process, a shared administrative workflow, or a compromised credential.
Context is especially important for AWS because the AssumeRole API can be used through console access, CLI use, federated access, cross-account access, or automation. That is why one of the strongest validation steps is to compare the principal that initiated the session with the session attributes and the surrounding activity. A single role with many distinct session names, source IPs, or originating users is not proof of abuse, but it is enough to justify deeper review.
Evidence becomes stronger when the role shows a mix of human and non-human paths, unusually broad geographic spread, or activity outside normal business hours. For example, if the same role is used by several developers and also by a build pipeline, the operational model should be documented. If it is not documented, the environment may already have an uncontrolled shared-access condition.
For incident patterns that show how cloud credentials get abused after theft, Amazon AWS Hacked Accounts Crypto-Mining and TruffleNet BEC Attack, Stolen AWS Credentials are useful references for the abuse path after a shared or stolen access path is discovered.
How to investigate without overcalling it
What to verify: Start with a time window that matches the environment, then count distinct calling identities per role and compare that with the role’s intended ownership model. Validate whether the same session pattern appears in maintenance windows, CI/CD jobs, federated workforce access, or emergency access procedures before labeling it suspicious.
- Check whether the role has a documented owner and approved use case.
- Compare assumed-role activity against expected source accounts, source IP ranges, and session naming conventions.
- Look for repeated use by principals that should not share an access path.
- Escalate if the role is used by unrelated users, especially if the activity also shows privilege escalation, unusual regions, or short-lived burst access.
Common mistake: treating any multi-user role usage as bad. In mature environments, shared operational roles can exist, but they should be tightly governed, observable, and explainable. The risk is not simply that more than one user touched the role, it is that the sharing pattern is invisible, undocumented, or broader than the access model allows.
Practitioner takeaway: Use the role as the object of analysis, but verify the people and systems behind each assumption event. The real control objective is to distinguish approved delegation from uncontrolled sharing or compromise before the ambiguity becomes an incident.
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 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5 — Account Management | Finds and reviews shared or unexpected role-use patterns across accounts and users. |
| Recommendation — Review account and role usage regularly, then remove or flag shared access paths that are not formally approved. | ||
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Continuous log analysis is needed to spot abnormal role-assumption patterns over time. |
| PR.AA — Identity Management, Authentication, and Access Control | Role assumptions must be attributable to approved identities and governed access paths. | |
| Recommendation — Monitor identity and access events continuously to detect deviations in role-assumption patterns. Bind role use to approved identities and enforce access controls that make unexpected sharing visible. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Visibility and Discovery | Unexpected multi-user role use is a visibility problem that requires discovery of who is using the role. |
| NHI-08 — Rotation and Revocation | If role sharing reflects compromise or uncontrolled access, credentials and trust paths may need revocation. | |
| Recommendation — Discover and inventory all principals that can assume the role, then alert on unexpected callers. Rotate or revoke the underlying access path when role use cannot be explained or is no longer trusted. | ||
Related resources from NHI Mgmt Group
- What breaks when multiple users share the same privileged AWS login?
- How can IAM teams tell whether an agent has excessive effective permissions?
- How can IAM teams tell whether identity security coverage is real or just broader branding?
- How can IAM teams tell whether passkey adoption is actually working?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
