Every identity security posture management deployment I have seen starts with the same twenty checks: dormant accounts, accounts without multi-factor authentication, orphaned accounts, accounts with more privilege than their job requires. They are useful. They are also the part of the problem your directory already reports, and after a year of running them most teams have learned to read the output and move on.

The questions that actually decide whether identity is your largest attack surface sit one level lower, in the configuration of the identity system itself. Those questions are not about accounts. They are about policy.

Four questions that account counts cannot answer

Does your conditional access actually cover the population it claims to cover? A policy named "require MFA for all users" is a statement of intent. What matters is the effective population: which exclusions were added during an incident and never removed, whether guest accounts are in scope, whether the policy applies to the applications people actually use or only to the ones in the pilot, whether the emergency access accounts are the only ones exempt. The number of users covered by a policy is a computation, not a label, and most organisations have never done the computation.

What does your consent policy actually allow? Application registrations accumulate. Some were granted tenant-wide consent years ago by an administrator who has since left, some were granted by users under a permissive user-consent setting, some have mailbox read scope because an integration needed it in 2021. Nobody reviews grants, because grants do not appear in an access review, and yet they are access.

Can a role be assumed from outside your boundary? In a cloud platform this is the trust relationship attached to a role: which principals may assume it, whether one of them is in another account, whether the condition restricts anything at all. In a directory it is delegation and federation: which partner tenant is trusted, for which identifiers, with which claim mapping. A role that can be assumed by a principal outside the boundary is privilege that does not appear in your entitlement review.

Does the policy name a wildcard where a resource was intended? A policy that allows an action on every resource is not the same as a policy that allows it on one bucket, and the difference is invisible in any inventory that reports roles rather than grants.

These four are not exotic. They are the conditions that make the difference between an identity that can reach one dataset and an identity that can reach the account.

Two different questions, and why keeping them apart matters

Account hygiene asks: is this account in good shape? Is the owner known, is the credential rotated, is it used, does it have more privilege than it needs.

Configuration posture asks: is the system's own policy sound? Does the authentication policy cover what it says, does the consent model restrict what it should, does the trust boundary hold, is the grant scoped to the resource it was meant for.

The two have different owners, different cadences and different remediations. Account hygiene belongs to identity operations, runs continuously and produces cleanup work. Configuration posture belongs to the platform owners, changes when policy changes, and produces design decisions. A posture programme that reports both in the same list teaches its readers to skim.

Native evidence, not the identity provider's opinion

There is a structural reason most posture tools miss the second category: they read the identity provider and stop. The identity provider knows about accounts it federates. It does not know about the user created directly in a SaaS application because a team needed one seat, the account with a local password that bypasses single sign-on, the profile assignment that grants more than the job function, or the last sign-in date of an account that never touched the identity provider at all.

The same asymmetry appears in cloud platforms. The identity provider sees the federation. It does not see the policy document attached to the role, the resource it names, the trust relationship that lets it be assumed, or the cross-account path that reaches it.

So the first architectural decision in posture is where the evidence comes from. Reading it natively, per platform, and landing it in one model is what makes the difference between a posture report and a posture claim. It is also what makes coverage honest: when each source declares what it covers and when it was last collected, "no such account" and "no source has told me about it yet" stop being the same sentence.

Applications are concepts, not registrations

Ask a security leader how many applications their organisation has and you get a number in the low tens. Ask the identity provider and you get one hundred and eighty registrations. Both are right about different things: the leader is counting applications, the directory is counting instances.

The distinction is not pedantry. Posture work is organised around applications, because applications have owners, and owners are who you route decisions to. A registration with no confirmed application behind it is an orphan by construction: it may be internal, unused, shadow, or simply mislabelled, and until someone classifies it, nobody is answerable for it. Counting instances guarantees that half your posture findings have no recipient.

There is a useful side effect. When applications are held as concepts and instances are attached to them as provenance, the applications federated through your identity provider enter the posture model without a connector per application. Coverage of the federated estate arrives with the first catalogue sync, not one integration at a time.

Reports, not dashboards

Dashboards are built by the person who understands the data and read by the person who does not. That is why posture programmes stall: the security team has a beautiful view of the estate and the application owner has an email.

An owner needs three things in one artifact: the gap that concerns their estate, the evidence behind it, and the decision you are asking them to take. A scheduled report addressed to the owner moves faster than a dashboard nobody opens, and it has a second benefit that matters more: it is auditable. A report that was sent, opened and answered is a record that a decision was requested. A dashboard cannot be asked who looked at it.

How this is built in Sharelock

Sharelock ships identity posture as a family of connected applications, one per platform, under the name Claritas: Claritas for Microsoft Entra, for Microsoft 365, for Salesforce, for AWS, for Okta, for Google Cloud. Each is a self-contained application that reads native evidence, lands it in its own database namespace, exposes its capabilities as a tool server to the agentic layer, and serves a posture surface for the person who owns that platform. Because they are separate applications, a customer can start with one and add the next without re-collecting anything.

What each application reads follows the platform rather than a template. From an identity provider: sign-in and audit events, directory configuration, authentication methods and multi-factor registration state, conditional access policy, authorization and consent policy, privileged role assignments together with the directory objects or application registrations they are scoped to, and device registration and compliance state. From a cloud platform: identities together with the policy documents attached to them, so a grant is held as the actions allowed on the specific resources the policy names, including wildcard grants, cross-account reach and the trust relationships that allow a role to be assumed. From a SaaS application: the user catalogue with active state, profile, user type and last sign-in date.

What each measures is expressed as posture rather than as a list of complaints: multi-factor coverage, privileged access concentration, risky sign-in patterns, dormancy in bands of seven, thirty and ninety days, accounts that never authenticated, distribution across profiles and departments, device hygiene, and conformance of the platform's own configuration to an agreed baseline. Account hygiene and configuration posture stay separate questions, because they have separate owners and separate remediations.

Applications are reconciled rather than listed. The platform reads application registrations from the identity provider catalogues and reconciles them into applications as real-world concepts, holding each system's instance as provenance; instances that no confirmed application claims become a governed delta that the operator classifies as internal, unused, shadow or to be clarified. Federated applications therefore enter posture with the first catalogue sync, without a connector per application, and the count a reader sees matches the applications they recognise rather than the registration objects the directory holds.

Output arrives as an artifact rather than a view: headline measures, distributions, item tables, the governance gaps the source exposes, a verdict and the confidence behind it, produced on a schedule, on request, or from a question asked in natural language and translated into a query by a data-analysis agent. The report is the thing an owner can be held to, which is the reason to produce one at all.

What to check this week

Five checks, none of which require a new tool, all of which require reading configuration rather than counts.

1. Take your most important conditional access policy and enumerate its effective population. Then look for the exclusions nobody remembers adding.
2. List application registrations with tenant-wide consent, with the date of the grant and the administrator who made it.
3. List the roles in each cloud account that can be assumed by a principal outside the account, and check what condition, if any, restricts the assumption.
4. List grants that name a wildcard resource, and for each one, find the resource the author probably meant.
5. List the accounts in your main SaaS applications whose last sign-in is older than ninety days, then check how many of them exist in your identity provider. The difference is the part of your estate no posture tool has been reading.

If those five produce nothing, your account hygiene programme is probably complete and your posture problem is elsewhere. If they produce a list, you have found the difference between counting accounts and understanding policy, which is the whole job.

‍

‍