Cloud IAM Pentesting: The Identity Misconfigurations Attackers Actually Exploit

TL;DR

• Identity, not infrastructure, is now the top cloud risk: the majority of cloud breaches trace back to a compromised or misconfigured identity rather than an unpatched system.
• A cloud IAM pentest tests whether a low-privilege account, service principal, or automated workflow can escalate to administrator-level access through role assignments, trust relationships, or policy gaps.
• Enabling MFA is not the same as securing identity. A 2025 Entra ID vulnerability showed that privileged access could be obtained without triggering MFA, conditional access, or a normal audit trail.
• A configuration audit and a penetration test answer different questions: an audit finds what is set incorrectly, a pentest proves what an attacker can actually do with it.
• Sectricity combines both in a single engagement, so you get a prioritised, exploit-based view of your cloud identity risk rather than just a compliance checklist.

Cloud security used to be a story about firewalls, patching, and network segmentation. In 2026, that story has changed. Across Azure, AWS, and Google Cloud, the accounts, roles, and permissions that control who can do what inside your tenant have become the primary attack surface. Sectricity's cloud penetration testing engagements increasingly focus less on infrastructure vulnerabilities and more on identity: role assignments, privileged identity management, conditional access, and the service principals that connect your applications to your cloud environment.

Why Cloud Identity Became the Number One Risk

A few years ago, most cloud incidents traced back to an exposed port, an unpatched server, or a forgotten public bucket. Today, the majority of cloud breaches trace back to a compromised or misconfigured identity rather than a technical vulnerability in the underlying infrastructure. The shift makes sense: as more of what a cloud tenant can do gets expressed through roles, groups, conditional access policies, and service principals, that layer becomes the part worth attacking, and the part most likely to contain a small, overlooked mistake.

What We Actually Test in a Cloud IAM Pentest and Configuration Audit

A cloud IAM pentest and configuration audit look at the same environment from two angles: what is configured, and what can actually be abused. In practice, most findings fall into one of five categories.

Privilege Escalation Through Role Assignments

A cloud IAM pentest does not stop at reviewing who has which role on paper. Testers actively look for accounts, human or service based, that can escalate from a limited role into full administrative control of a subscription or tenant. In practice, this usually starts with a role assignment that looks harmless: a user or application granted Contributor or Owner rights on a single resource group to get something done, which is never revoked once the task is complete. From there, testers map whether that access chains into a path toward Global Administrator or full subscription ownership.

Privileged Identity Management Gaps

Microsoft Entra ID's Privileged Identity Management (PIM) is designed to make privileged roles temporary and require justification. In assessments, Sectricity regularly finds tenants where PIM licensing is available but simply not enabled for the roles that matter most, leaving accounts with standing Global Administrator access around the clock. A compromised credential on such an account gives an attacker immediate, permanent privileged access, with no additional step required.

Conditional Access and MFA Bypass Paths

Conditional access policies are frequently built around a small number of well-known scenarios, such as blocking sign-ins by location or requiring MFA on the web, while leaving legacy authentication protocols, service accounts, or break-glass accounts outside their scope. A cloud IAM pentest checks whether these gaps can be used to bypass MFA entirely, rather than assuming a policy works as intended once it exists in the console.

Service Principals, App Registrations and Stale Credentials

Every integration, CI/CD pipeline, and internal tool that talks to your cloud environment typically does so through a service principal or app registration. These accumulate over time, often keep client secrets that never expire, and are rarely reviewed once the project that created them is finished. Testers look specifically for over-permissioned or forgotten service principals as a quiet route to persistent access.

Storage Account Permissions and SAS Tokens

Publicly accessible storage accounts and overly permissive Shared Access Signature (SAS) tokens remain one of the most common findings in cloud assessments. A single long-lived, broadly scoped SAS token can expose an entire storage account to anyone who obtains the link, regardless of how well the rest of the tenant is configured.

The Lesson From a Real Entra ID Vulnerability

In 2025, security researchers disclosed a critical Microsoft Entra ID vulnerability (CVE-2025-55241) involving Actor tokens, an internal delegation mechanism that a legacy API failed to validate correctly across tenant boundaries. The flaw could have allowed an attacker to impersonate any user in any tenant, including Global Administrators, without triggering MFA, conditional access, or leaving a normal sign-in audit trail. Microsoft mitigated the issue quickly, but the case is a useful reminder for every organisation running Entra ID: identity compromise does not always look like a failed login attempt or a conditional access alert. Assuming your identity layer is safe because your dashboards look clean is not the same as testing it.

Configuration Audit or Penetration Test? Cloud Environments Need Both

A configuration audit reviews your cloud environment against a known-good baseline: which roles are assigned where, whether PIM and conditional access are enabled, how storage accounts and key vaults are configured. It is thorough, systematic, and essential for compliance frameworks such as NIS2 or ISO 27001. What it cannot tell you is whether those misconfigurations are actually exploitable in your specific environment, in combination with each other. That is where a penetration test comes in: testers chain findings together the way an attacker would, to prove or disprove that a specific path to privileged access exists. Sectricity's audit-ready penetration testing approach combines both, so the audit findings and the exploit path end up in the same report, prioritised by what is actually reachable rather than by severity score alone.

What Good Remediation Looks Like

Once a cloud IAM pentest and configuration audit are complete, the highest-impact fixes are rarely exotic. Enforcing PIM for every privileged role, removing standing Global Administrator access, tightening conditional access to cover legacy authentication and service accounts, running a structured service principal cleanup, and replacing long-lived SAS tokens with time-boxed, scoped alternatives typically address the majority of findings. The value of the pentest is in showing which of these fixes actually closes an exploitable path, so remediation effort goes where it reduces real risk first.

Frequently Asked Questions

What is a cloud IAM pentest?

A cloud IAM pentest is a security assessment that tests whether identities in your cloud environment, including user accounts, service principals, and automated workflows, can be abused to escalate privileges or gain unauthorised access. It goes beyond a configuration review by actively attempting the privilege escalation paths an attacker would use in Entra ID, AWS IAM, or Google Cloud IAM.

How is a cloud configuration audit different from a penetration test?

A configuration audit checks your cloud environment against a known-good baseline and flags settings that deviate from it. A penetration test goes further by actively trying to exploit those misconfigurations, alone or in combination, to confirm whether they lead to real unauthorised access.

Which cloud platforms does a cloud IAM pentest cover?

Cloud IAM assessments typically cover Microsoft Entra ID and Azure role-based access control, AWS IAM roles and policies, and Google Cloud IAM, depending on which platforms your organisation runs. Hybrid environments that connect on-premises Active Directory to Entra ID require additional attention because they extend the attack surface across both worlds.

Does enabling MFA mean our cloud identity is secure?

No. MFA reduces the risk of simple credential theft, but it does not address privilege escalation through role assignments, gaps in conditional access scope, or vulnerabilities in the identity platform itself. A cloud IAM pentest tests the paths that exist regardless of whether MFA is enabled.

How long does a cloud IAM pentest take?

Most cloud IAM pentests and configuration audits run between one and three weeks, depending on the number of subscriptions, tenants, and integrations in scope. A focused engagement on a single tenant with a defined set of roles can often be completed faster.

How often should we run a cloud identity assessment?

An annual cloud IAM pentest and configuration audit is a reasonable baseline for most organisations, with an additional check after major changes such as a new hybrid identity setup, a large-scale application migration, or a significant increase in the number of service principals and integrations in use.

Related Services and Resources

Cloud identity risk rarely shows up in isolation, which is why Sectricity's cloud penetration testing is usually delivered alongside a broader look at your cloud security posture, covering network configuration, key management, and logging alongside identity. Organisations that need to demonstrate testing evidence for a regulator or auditor, for example under NIS2 or a customer security questionnaire, typically combine this with Sectricity's audit-ready penetration testing service, which structures findings and remediation evidence specifically for that purpose. If you are not yet sure whether a configuration audit, a full pentest, or both make sense for your environment, that is a conversation worth having before scoping a fixed engagement.