Identity & Access Management Cheatsheet

IAM is the discipline of granting exactly the access each identity needs, and no more, then proving it stays that way. Where attack-detection asks "is someone abusing this access," governance asks "should this access exist at all," and the second question prevents far more incidents than the first catches. This is the design and review reference: the configuration and patterns that keep an Entra tenant least-privilege over time, across human users, guests, applications, and the non-human identities that quietly outnumber all of them. Every control here exists because access, left alone, only grows.

The IAM problem

Access only ever accumulates unless something removes it. People change roles and keep the old access (permission creep), accounts outlive their owners (stale identities), apps and service principals are granted broad scopes and never reviewed, and privilege becomes permanent. Every item below is a governance control that counters one of these drifts.

Group and role architecture

Groups are how access scales without becoming unmanageable. The core decision is assigned vs dynamic membership: assigned groups are explicit and auditable but manual; dynamic groups are rule-driven and self-maintaining but only as correct as their rule. Access is granted to groups, not users, so that a role change is a group change, not an audit of every resource. The failure mode is the nested group nobody fully maps: access granted three groups deep, inherited by members who were never meant to have it. Keep nesting shallow and deliberate, and treat a dynamic-group rule as a privileged object, because in effect it is one, it grants access at the scale of whatever it matches.

Conditional access design

Conditional access is the policy engine that decides whether a sign-in proceeds. Good design is layered and explicit: a baseline that requires MFA and a compliant or managed device, risk-based policies that step up on signal, and as few exclusions as possible. The common design errors are a single monolithic policy that is impossible to reason about, and a sprawl of overlapping policies whose combined effect nobody can predict. Build named policies with one clear intent each, test them in report-only mode before enforcement, and keep a documented map of which policy covers which population, an undocumented CA estate becomes a set of rules people are afraid to touch, which is how stale exclusions survive for years.

Applications and consent governance

OAuth consent is how apps get access to your data, and unrestricted user consent is how attackers do too. In a consent-phishing attack the user is tricked into granting a malicious app real Graph permissions (read mail, read files), and because the user consented, no credential was stolen and MFA never mattered. The governance move is to restrict who can consent, define the low-risk permission tier an app may be granted without admin review, route everything above it to an admin-consent workflow, and periodically re-examine what apps already hold, because the dangerous grant is usually the one made months ago that no one has looked at since.

Service principal and workload governance

Service principals and workload identities authenticate as themselves and outlive any human. They are the least-governed identities in most tenants and the most dangerous when neglected: a forgotten app registration with a long-lived secret and broad permissions is a standing backdoor that no password reset or offboarding ever touches. The reason they sprawl is that anyone can register an app, the credential never expires unless someone sets it to, and ownership evaporates when the person who created it leaves. Inventory every service principal against an accountable owner, classify by privilege, prefer certificates over secrets, and alert on credential additions, a new secret on an existing app is one of the cleanest persistence moves an attacker has.

Privileged access

Standing privilege is the highest-value target in the tenant, so the governance goal is that almost no privilege is permanent. PIM makes privileged roles eligible rather than active: a user activates the role when needed, time-bound and justified, and it drops automatically after. That single change turns a permanent Global Admin (a credential worth stealing every hour of every day) into a role that is dormant most of the time and audited every time it wakes. Role assignment itself is governed (who may grant privilege, and how that is reviewed), and a small number of break-glass accounts exist for the day everything else fails, designed deliberately, not discovered missing during the incident.

Entitlement management and access reviews

Entitlement management packages access into requestable, approvable, expiring bundles, so granting is governed at the point of request, not retrofitted later, and the access carries its own expiry instead of living forever. Access reviews are the counterweight that removes what is no longer needed. Together they make access a loop (request, approve, use, review, expire) rather than the one-way accumulation that is the default state of every directory. The hardest part is the leaver and the mover: offboarding usually removes the obvious account but leaves the group memberships, app roles, and standing access behind, which is exactly the residue that becomes an orphaned attack surface. Lifecycle automation that triggers on the HR signal, not on someone remembering, is what closes that gap.

IAM monitoring queries

Governance needs evidence, not assumption. These KQL queries surface the three drifts that governance exists to counter, the stale account that should be gone, the identity quietly accumulating access, the application credential nobody is tracking. Run them on a cadence and feed the output straight into the access-review process, so the monitoring and the remediation are one loop rather than a report that gets filed. They run in Microsoft Sentinel; several depend on the IdentityInfo table, which requires UEBA enabled with Entra ID as the entity provider.

Stale member accounts

Members with no successful sign-in inside the threshold are candidates for disable-then-delete, route them to manager review with their directory context attached.

Permission creep

Accounts gaining group memberships without losing any are accumulating access, the signature of a mover whose old access was never removed.

Credential health

Credential lifecycle events on app registrations surface new, expiring, and long-lived secrets, the service-principal hygiene that governance has to enforce.

Governance checklist