Scan later, or score now

Here is a pattern worth noticing. Almost every identity security product on the market is a reader. It connects to your platforms, pulls configuration back, compares it to a policy, and tells you what is wrong. Posture management, entitlement analytics, drift detection, CIEM — different acronyms, same shape. Something is built, and later something else reads it and disapproves.

That shape has a cost nobody really prices in, and it is not accuracy. The readers are usually accurate. The cost is that by the time they look, the cheap moment has passed.

Four things a scan can never recover

When a tool reads your configuration back weeks after the write, four things are gone, and no amount of cleverness recovers them.

The intent. The scanner sees redirect_uri = https://app.vendor.com/cb. It does not know a finance team asked for this, that it handles cardholder data, that the vendor's own documentation specified that exact URI, or that somebody checked. It has bytes. It does not have reasons, and most good risk judgements are made on reasons.

The alternatives. It sees what exists. It cannot see what was proposed and rejected, which means it can never tell you the configuration could have been narrower. There is no counterfactual in a scan. There is only a finding.

The approver. It can tell you a risk exists. It cannot tell you which change introduced it or whose name is attached. Attribution gets reconstructed afterwards from change tickets and commit logs, badly, usually during an audit, usually by someone who wasn't there.

The whole identity. This is the one that matters most and gets discussed least. The real blast radius of an identity is the SSO claims plus the entitlements plus the vaulted service account. Okta's reports see Okta. SailPoint sees SailPoint. Vault sees Vault. Each is accurate about its own slice and blind to the other two. The risk lives in the union, and the union exists nowhere.

And the fifth cost, which is commercial

By the time a scan finds something, fixing it is no longer free.

Changing a live configuration means a change request, an approval, a maintenance window, a regression risk, and a conversation with whoever owns the application about why you want to touch something that currently works. The finding is correct. It also goes on a backlog, because the cost of acting on it is now measured in people's time rather than in a click.

A risk found before the write costs one edit. The same risk found after the write costs a project. Same risk, same severity — two orders of magnitude difference in what it takes to deal with it.

This is why posture dashboards accumulate. Not because teams are lazy, and not because the tools are wrong, but because the tools report at the moment when action is most expensive.

What exists at creation time

Now consider the other end. In the instant before the write, something is holding, all at once:

• the proposed configuration — which does not exist yet, and therefore costs nothing to change
• the intent that produced it: the request, the vendor metadata, the data classification
• the whole identity across SSO, governance and privileged access, because it is about to write all three
• a named human who is about to approve it

No scanner has any of that. It arrives later, reads one platform, and finds an orphan with no parentage and no alternatives.

Why this is structural, not a feature gap

Service management is the interesting near-miss. It holds the request and the approval and has done for twenty years — but it does not perform the write, so it never learns what was actually created. Scanners are the exact mirror: they see the result and never the reason.

The gap in the middle is not a missing feature on any of these roadmaps. It is a position in the flow — the thing that sits between the request and the write, across every platform the identity touches. Whatever occupies that position can do something none of the others structurally can.

What it looks like in practice

A number that moves. In our own runs the hero figure is 61 → 38: sixty-one is the blast radius of the configuration as proposed, thirty-eight is the same identity after one fix — a shared secret replaced at layer five, costing nothing because the thing did not exist yet.

That delta is only possible if you scored something unbuilt. A scanner can only ever show you sixty-one, after it is live, and then open a ticket for somebody else to close in the next quarter.

So the claim is narrower and more useful than "we find risk". Everybody finds risk. It is: we find it at the one moment when fixing it is free, and we can fix it ourselves, because we are the one about to do the writing.

The honest limits

Two, and they are real.

It only covers what you provision. Applications onboarded some other way have no score. Coverage equals adoption. Scoring the estate you already have is a different product — and that product is a scanner, competing with people who have been doing it for a decade and are good at it.

It requires writing more than one platform. If you only ever configure SSO, your "seven layers" is mostly one layer, and the cross-platform advantage evaporates. The governance and privileged-access work is not a roadmap nicety; it is the thing that makes the central claim true.

Both of those are worth saying out loud, because a positioning that only survives when nobody asks hard questions is not positioning. It is marketing.