One consolidated view of Entra ID identity risk, scored every night

What ISPM is (and how it differs from IAM, PIM, and MDR)

Identity security posture management is the continuous assessment of an identity environment’s exposure: which accounts, credentials, permissions, and configurations create risk, scored and tracked over time, not audited once a year.

It’s easy to confuse ISPM with adjacent categories that touch the same data. They solve different problems.

IAM (Identity and Access Management) provisions and manages access. It’s the system that creates accounts, assigns licences, and enforces sign-in policy. IAM is the plumbing.

PIM (Privileged Identity Management) manages just-in-time elevation for privileged roles. It controls how a user temporarily becomes an admin. PIM is a control mechanism for one specific risk: standing privilege.

MDR (Managed Detection and Response) watches for active threats and responds to them. It’s reactive by design, looking for signs of compromise after something has already gone wrong.

ISPM doesn’t provision access, elevate privilege, or detect active attacks. It assesses the state of the identity environment itself: how many stale accounts exist, whether guest access is properly scoped, whether service principals are carrying credentials nobody’s watching, whether privileged roles are actually protected. It’s the posture check that tells you where IAM, PIM, and MDR are exposed to begin with.

ISPM is also a narrower, deeper subset of CSPM (Cloud Security Posture Management). Classic CSPM assesses cloud configuration broadly, storage buckets, network rules, resource policies, across an entire cloud estate, with identity treated as one line item among many. ISPM inverts that emphasis: identity is the primary, most deeply assessed layer, not an afterthought.

ID Posture reflects that inversion rather than a hard boundary. Its scoring model is still 100 percent identity, the four pillars below are the entire 0 to 100 posture score, but its coverage has grown to include Azure resource-configuration checks that sit directly adjacent to identity: whether Azure SQL, Cosmos DB, and Redis enforce Entra ID authentication instead of local key-based access, network exposure on Key Vaults, storage accounts, and virtual networks, and access configuration on AKS clusters and virtual machines. None of these move the identity score. They exist because a database left on local key authentication, or a storage account open to the public internet, is often a more direct route around Entra ID’s own access controls than a gap in the identity layer itself, and a tool that only ever looked at identity would miss it.

For organisations where identity is the primary attack surface, which describes most Microsoft 365 and Entra ID-centric businesses, a tool built identity-first, and expanding outward from that foundation rather than starting from a broad, shallow cloud inventory, still finds and prioritises risk that a general CSPM product isn’t built to surface.

Why identity posture is the Essential Eight gap for Australian mid-market

Essential Eight has genuine, broad awareness across Australian organisations, driven by ASD guidance, insurance questionnaires, government tender requirements, and board-level risk conversations. But most of the tooling and guidance built around it clusters on the same six strategies: patching applications, patching operating systems, application control, configuring Microsoft Office macro settings, and backups. Patch management platforms are mature. Application control has established tooling. Backups are a solved operational problem for most IT teams.

The two identity strategies, E8-5 (restricting administrative privileges) and E8-7 (multi-factor authentication), are comparatively under-served. They’re harder to audit because they’re not a single setting you can check once. Administrative privilege sprawl accumulates over time, one temporary access grant that never gets revoked, one former contractor’s account still holding a directory role. MFA coverage gaps hide in Conditional Access policy exclusions, break-glass accounts, and legacy authentication methods that never got properly retired. Neither strategy has a clean, single dashboard in Entra ID that shows the full picture.

Microsoft’s own tooling for this is real and free, but it’s spread thin. Identity Secure Score in the Entra admin center gives you a general risk indicator, not a drill-down to specific affected accounts. Purview Compliance Manager has Essential Eight templates, but they operate at the compliance-documentation level, not the live, per-object evidence level. Conditional Access reporting shows policy coverage but not the accounts falling outside it. Subscription-level RBAC lives in the Azure portal entirely, disconnected from anything in Entra ID. To actually evidence E8-5 and E8-7 for an audit, a tender, or a board pack, someone has to manually piece the picture together across four or five separate Microsoft surfaces, then re-do it every time it’s needed again.

That’s the specific gap ID Posture is built to close: one consolidated dashboard that shows administrative privilege exposure and MFA coverage together, continuously, instead of several clunky, disconnected Microsoft surfaces that each show part of the picture.

What continuous posture scanning covers

ID Posture connects to a customer’s Entra ID tenant with read-only, application-only Graph API access, no delegated permissions, no standing user credentials, and scans it automatically every night once connected. Each scan evaluates 98 findings, produces a 0 to 100 posture score, and drills down to the specific affected objects behind it.

Australian data residency and why it matters

For an Australian organisation handling its own employees’ and customers’ identity data, where that data physically sits and how it’s handled matters under the Privacy Act, and increasingly matters to auditors, insurers, and enterprise customers asking security questionnaire questions before they’ll sign a contract.

ID Posture is hosted in Australia, with scan data stored in Blob storage in the AU East region, and operated by SOLUTIONWARE PTY LTD (ABN 81 630 109 643), trading as ID Posture.

There’s also a genuine architectural constraint behind the residency story, not just a hosting location. Scan-derived identity data, display names, UPNs, and email addresses belonging to the customer’s own users and guests, is never stored in ID Posture’s SQL database. It’s written to Blob storage only. This isn’t a policy promise sitting on top of a normal database; it’s a structural decision in how the product is built, which means there’s no accidental path for that data to end up somewhere it shouldn’t.

How a trial works

Starting a trial doesn’t require a sales call, a procurement process, or handing over standing credentials. An IT admin signs in with their own Microsoft work account, works through a short, read-only admin-consent flow to grant ID Posture application-level Graph API access, and the first scan runs from there. No credentials are stored beyond the application-only Graph connection itself, and the consent granted is read-only throughout, covering the same permission scopes documented for the product (Directory.Read.All, Policy.Read.All, AuditLog.Read.All, and related read-only Graph scopes), never write access. Connecting Azure subscriptions for the RBAC and Azure resource-configuration checks is a separate, optional step using the same read-only model; a single built-in Reader role covers all of it in one grant.

Once the first scan completes, the dashboard shows a scored result: overall posture score, the four pillar scores behind it, and every finding with drill-down to the specific accounts, apps, or role assignments driving it. There’s no sample data and no placeholder dashboard to imagine your own environment into. It’s your tenant’s actual posture, scored.