How to Measure Identity Posture When You Have 200 Clients and No Two Tenants Alike

Measuring identity posture for one organization is hard. Measuring it across two hundred client tenants, where no two are configured alike, run different stacks, and have different risk appetites, is a different problem — and most tooling pretends it isn't. A score that means one thing in tenant A and something else in tenant B isn't a measurement; it's a vibe. Here's how to get to something you can actually compare and act on.

Why the single-checklist approach breaks

The intuitive move is one master checklist applied everywhere. It falls apart immediately, for a structural reason: your clients don't share a configuration, a product set, or a definition of "done." One uses a different IdP. One has a compliance regime the others don't. One legitimately can't enforce a control your checklist demands because of a business constraint. Run the same 200-item checklist across all of them and you get 200 columns of mostly-not-applicable noise, and a "score" that's really measuring how closely each client resembles your template — not how exposed they are.

The heterogeneity isn't an exception to manage; it's the permanent condition. Measurement has to survive it.

Measure by failure class, not by config item

The shift that makes this tractable: stop measuring configurations and start measuring failure classes. A config item ("Setting X is enabled in product Y") is product-specific and doesn't port across tenants. A failure class ("a privileged identity can be recovered without strong verification") is universal — it's true or false regardless of which products implement it.

Define posture as a set of failure classes that matter everywhere:

Can a leaked password alone reach anything? (enforced MFA)
Can a privileged factor be reset without strong verification? (recovery)
Are there standing identities — human or machine — that nobody owns or has reviewed? (stale/over-permissioned)
Can a non-human grant reach sensitive data unreviewed? (OAuth/app governance)
Is a stolen session portable and long-lived? (session hygiene)

Each of these is answerable in any tenant, on any stack, with a yes/no/unknown. Now you're comparing the same risks across clients, even though the underlying products differ. That's a measurement that ports.

Coverage is a number; track it separately

The most important and most-skipped metric is coverage: of everything in this tenant, how much can you even see? A tenant where you've instrumented 60% and everything visible is clean is more exposed than one at 95% with a few open items — but a naive score shows the first as healthier. So split the metric in two:

Coverage: what fraction of the estate (accounts, apps, integrations, recovery flows) is actually assessed?
Findings: within what's covered, what's open?

Report them together, always. "Clean" without coverage is the lie that ends in a breach with a green dashboard.

Leading vs. lagging indicators

A static count of open findings is a lagging indicator — it tells you the state, not the trajectory. Across 200 clients you care more about leading indicators:

Mean time to close a finding once it opens. This measures whether your process works, which is what posture actually is.
New-gap rate — how fast drift introduces problems (new tenants, new apps, new accounts). High drift with slow close is the danger pattern.
Recurrence — the same failure class reopening in the same client. That's a process failure, not a one-off.

These travel across heterogeneous tenants because they're about your operation, not the clients' configs.

Normalize, then weight by exposure

Finally, a raw failure-class count treats every client the same. They aren't. Weight by exposure: a privileged identity without strong recovery in a client with sensitive data outranks a cosmetic gap in a low-risk tenant. You don't need a precise risk model — even a coarse high/medium/low exposure tier, applied consistently, turns "200 lists of findings" into "here are the ten client-risks that should move first this week." That prioritization is the entire point; a flat score across 200 tenants is unactionable by construction.

The takeaway

Across many clients, don't measure configurations — measure universal failure classes, report coverage alongside findings so "clean" can't hide blind spots, track leading indicators (time-to-close, drift, recurrence) because posture is a process, and weight by exposure so the number tells you what to do Monday morning. A score that can't survive heterogeneity isn't measuring posture; it's measuring how much your clients look like your template.

At Aurelion, measuring posture across many unlike tenants — by failure class, with coverage honesty — is exactly what we work on. If you're running identity for a fleet of clients and wrestling with this, I'd genuinely like to compare notes.