Your
Trusted
Get Fully AWS Funded
Cloud Migration
Cloud Migration
It is a documented examination of who and what can access selected AWS resources, why that access exists and whether it remains appropriate. A useful review includes identity-provider assignments, role trust, applicable policies, ownership and decisions about remediation.
Choose a cadence based on risk, contractual obligations and applicable requirements. Quarterly review of privileged production access is one possible starting point; also review access after departures, vendor offboarding and material changes. Confirm specific obligations with the people responsible for the organization’s compliance program.
No. It identifies certain access conditions and validates policies within its supported scope. Teams still need to assess coverage, decide whether access is justified, retain evidence and evaluate the broader controls and obligations relevant to them.
Investigate first. A permission may support a rare recovery, reporting or operational task. Check the observation period and owner, test the proposed change and preserve a rollback path before removing access from a critical workload.
Privileged access management is the broader practice of controlling and overseeing powerful access. In AWS, a review can examine administrative roles, how they are assumed, MFA, approvals, duration, emergency access and the records of use. The exact implementation depends on the organization’s identity and access tools.
“A customer security questionnaire arrives on the same day an engineer needs access to investigate a delayed reconciliation job. One person asks who can reach production data; another needs a role that will let them troubleshoot. If the answers live in different tickets, policies and people’s memories, both requests can take longer than they should.
A useful AWS IAM access review connects those two situations. It identifies who and what can reach important resources, checks whether that access still has an owner and a purpose, and records the decisions and changes that follow. The result is a working record that security, platform and engineering teams can use again when the next review or access request arrives.”
In September 2026, Revolut confirmed that it had disclosed customer information after fraudulent requests arrived from a legitimate government agency email domain. TechCrunch reported that the number of affected customers was not disclosed; the Italian data protection authority opened cooperation with its Lithuanian counterpart. This incident concerns verification of information requests, and the published reports do not establish an AWS IAM failure.
A different access path emerged at payments provider Triple-A in July 2026. In its post-mortem, the company reported that social engineering compromised an engineer’s credentials, followed by higher-level permissions, access to production databases and misuse of legitimate API credentials. Triple-A reported that client funds were unaffected and that the investigation was ongoing. Its account does not identify AWS IAM as the cause. For an AWS team, the practical review is to trace what a compromised identity could assume or reach, including production data and sensitive credentials.
In a 2025 investigation of a Canadian credit union payment platform, Charles River Associates reported more than 90,000 authentication attempts and 86 compromised user accounts. The investigators found no access to underlying infrastructure, fraudulent transactions or data exfiltration. The case concerns an application authentication flow, not an AWS IAM incident; it also shows why MFA configuration and evidence from multiple logs deserve testing rather than assumption.
“Who can reach this data, why do they need it, and who can remove that access?”
Those questions make IAM security useful to both the person answering a customer and the engineer responsible for the system.
Choose a review boundary before exporting policies. For example, a team might start with the production accounts supporting payment processing or reconciliation, the storage holding customer exports, and the deployment roles that can change those services. Record the accounts, Regions, identity provider, resources, review date and people responsible. Include known exclusions, such as a subsidiary account or a third-party platform that the team cannot yet inspect.
Build an inventory of human access, workload roles and external access. Human access can come through a corporate identity provider and AWS IAM Identity Center permission sets as well as IAM users. Workloads may use roles for applications, CI/CD pipelines and automation. Partners and support providers may assume cross-account roles or receive access through resource policies. Review root access and emergency access separately.
For each route, capture the principal or group, account, role or permission set, resource or environment, owner, business purpose and approval. Add the last review date and the source of the evidence. A group name alone rarely explains who approved access or whether every member still needs it.
An IAM policy attached to a role is only part of the picture. A person may obtain a role through federation and a group assignment; a workload may use a role trusted by another account. Resource-based policies, permissions boundaries and organization-level controls can affect the result. Review the trust relationship as well as the permissions, and check the actual path to sensitive resources rather than relying on a policy name. Datadog Security Labs’ research on privilege escalation paths shows why a review should also test whether combinations of permissions can reach a more powerful role.
Consider a deployment role that can update a production application and read secrets. Its owner should be able to explain which pipeline assumes it, which environments it serves and whether interactive users can also assume it. If a former vendor can still assume the role, the finding needs an owner and an expiry decision even when the pipeline itself remains necessary. Datadog’s analysis of cross-account access risks illustrates how role assumptions can connect one compromised identity to another account.
For people, prefer federation and temporary credentials where appropriate, and check multi-factor authentication at the identity provider or relevant access path. For workloads, review role trust and remove long-lived credentials where a supported role-based approach can replace them. Emergency access also needs a named owner, a tested procedure and a record of its use. Temporary credentials still need protection: Unit 42’s research on serverless authentication describes how exposed workload tokens can be abused while they remain valid.
AWS IAM Access Analyzer can identify external access to supported resources, unused roles and permissions, and internal access to selected resource types. These are separate analyzer types with different scopes. An external finding means a policy permits access outside the configured zone of trust; it does not by itself prove that someone used that access. Check the account or organization boundary, Regions, resource coverage and exclusions before reporting that a review is complete. External findings are free; internal and unused access analysis have separate charges.
Access Analyzer uses last-accessed information to identify unused access. A finding is a lead for investigation, not an automatic deletion order. A disaster-recovery role or annual reporting job may be inactive for months and still be necessary. Ask the owner about infrequent operations, check the observation window and logs, and test a narrower policy before removing a permission.
CloudTrail provides another part of the picture: records of supported API activity. Event history covers management events for the past 90 days in a Region; data events and longer retention require appropriate configuration. Check which accounts, Regions and event types are actually recorded, whether the relevant time period is retained, and whether the team can retrieve and protect the logs. Missing events do not prove that an action was impossible or never happened.
AWS’s Security Blog describes ways to scope unused-access analysis, including exclusions for tagged roles. An exclusion can make a review manageable, but record its reason, owner and expiry. Otherwise the exception may quietly become a blind spot.
A customer reviewer usually needs to understand the control and see that it operates. Keep a dated record of the scope, inventory source, reviewer, decisions, exceptions and remediation status. Link each finding to the relevant policy or configuration version, approval and change ticket. Restrict the evidence repository because inventories and logs can themselves expose sensitive details.
A practical record for a single finding might read: “Production deployment role can read a customer-export bucket. Platform owner confirms the pipeline requires only the release-artifact bucket. Change ticket opened; narrower policy to be tested in staging; security owner to verify production deployment after release.” The example is illustrative, not a claim about a real customer.
Assign decisions to people with the right context. The application or data owner confirms the business need; platform engineering checks the technical path and implements approved changes; security challenges high-risk access and exceptions. A named accountable owner resolves disagreements and confirms closure. Agree the division of responsibility with any external provider, including who can approve and apply changes.
Start with access that could expose sensitive data or change security controls, especially unexplained external trust, dormant privileged credentials and broad production permissions without a clear owner. Review active administrator access, root access, break-glass roles and human access paths with missing or uncertain MFA. Investigate before changing a critical integration. Rhino Security Labs’ research on IAM privilege escalation provides concrete examples of permissions that can be combined to obtain greater access.
For each change, capture the current behavior, intended narrower access, affected workload, test, approver and rollback path. Validate the policy with IAM Access Analyzer, review the infrastructure-as-code change where applicable, and test representative workflows. After deployment, verify that the access is reduced and that the job or service still works. Policy validation can reveal issues, but it cannot know every business dependency.
The same principle applies to wider security tooling. Das Meta’s guide to a staged AWS Security Hub migration explains why teams should preserve visibility and check downstream findings before removing the old configuration. Access changes deserve a similarly deliberate handover.
Use a risk-based cadence. As an example, review privileged production access quarterly and revisit other access at an interval the organization sets for its risk and obligations. Also trigger a review when someone leaves or changes role, a vendor engagement ends, a new account or sensitive workload launches, or a significant permission change occurs. These intervals are operating suggestions, not a statement of a universal regulatory requirement.
Give developers a clear request path: the role or access package, intended task, environment, approving owner and expected expiry. Standard access patterns and documented escalation can reduce avoidable back-and-forth; they still need a route for urgent, exceptional work. Track whether requests are waiting for an owner or a decision so the process itself can be improved.
Das Meta’s cloud infrastructure management service describes ongoing infrastructure work, while its cloud management guide discusses ownership and version-controlled configuration. The practical scope of any access review or ongoing operation should be agreed for the particular environment and team.
More than 90,000 authentication attempts and 86 compromised accounts were reported in a 2025 credit union platform investigation. Investigators found no underlying infrastructure access or data exfiltration.
In July 2026, Triple-A reported compromised engineering credentials, privilege escalation and misuse of legitimate API credentials. Its post-mortem does not establish an AWS IAM failure.
In 2026, Revolut confirmed fraudulent information requests, but did not disclose the number of affected customers. The reported incident is not evidence of an AWS IAM breach.
CloudTrail Event history provides 90 days of management events per Region. Longer retention and data events require additional configuration.
IAM Access Analyzer uses separate analyzers for external, internal and unused access, with different scope and pricing. Review each finding and its coverage before drawing conclusions.