Proofing Creep in Production: Design Patterns for Sensible Identity Verification

Two years ago, I wrote about proofing creep: the steady expansion of identity proofing into places where it is unnecessary, disproportionate, or simply lazy design. At the time, the warning was clear enough. If every modest transaction starts demanding passports, selfies, and assorted proofs of existence, we create friction, collect sensitive data we do not need, and train people to hand over documents as casually as they once handed over an email address.

Sadly, the market did not take this as a cue for reflection.

If anything, proofing creep has now reached production scale. It arrives bundled into platforms, marketed as innovation, and justified through architecture diagrams with many arrows and little restraint. Vendors have folded verification into products that were once about workflow, document signing, onboarding, or customer engagement. Organisations have mistaken availability for necessity. If the feature exists, someone will eventually insist on using it.

Earlier this year, Heather Flanagan and I presented on the topic at RSAC, focusing less on diagnosis and more on practical remedies. The conversation confirmed something important: many teams already suspect they are over-proofing. What they often lack is the language to challenge it and practical patterns for doing something better.

So let’s address that.

Proofing is not authentication

Much of this problem begins with a category error. Proofing asks who someone is at enrolment. It is usually episodic, tied to a moment in time when trust is first established. Authentication asks whether the same entity is returning now. Authorisation asks what that entity is permitted to do.

These are different functions. Yet many organisations still treat proofing as a magical ingredient that can be added to any identity problem. Fraud concern? Add proofing. Weak controls? Add proofing. Nervous executives? Add proofing. Marketing wants “trusted users”? Add proofing again.

The result is predictable. Proofing becomes a substitute for stronger runtime controls, better fraud detection, cleaner authorisation models, and more disciplined governance.

It is rather like trying to improve road safety by checking everyone’s passport before they enter a car park.

Why proofing creep happens

Proofing creep does not happen because people are irrational. It happens because incentives point in the wrong direction.

Risk teams tend to favour controls that look defensible. Architects often prefer controls they can centralise. Vendors naturally favour controls they can package and sell. Regulators rarely celebrate restraint. Internal governance structures frequently reward visible effort over measured outcomes.

Meanwhile, no one owns the most useful question of all: is this still worth it?

That question is awkward because it may require removing a control, and organisations are generally far more comfortable adding controls than retiring them.

The cost of normalisation

When users are repeatedly asked for passports, licences, face scans, or dates of birth in low-risk scenarios, two corrosive things happen.

First, users become numb. They stop distinguishing between legitimate requests and dubious ones. If every service demands sensitive evidence, suspicious requests start to feel normal.

Second, the value of proofing as a signal declines. If everyone requires strong identity evidence for trivial purposes, strong identity evidence no longer indicates seriousness. It becomes routine bureaucracy.

That routine has security consequences. A population trained to upload identity documents on command is easier to exploit. Fraudsters understand behavioural conditioning perfectly well, even if many governance committees do not.

Design pattern one: proof to purpose

Before adding any proofing step, require a plain-language explanation of the exact problem it solves.

Not “security.” Not “compliance.” Not “best practice.” Those are labels, not reasons.

A credible justification sounds more like this: we need to bind a legal identity to a regulated financial account; we need to prevent duplicate claims for a scarce public benefit; we need age assurance for access to restricted goods.

If the purpose cannot be stated clearly, the proofing step is probably compensating for some other weakness in the system.

Proofing should never be the default setting. It should be an intentional intervention tied to a specific outcome.

Design pattern two: ask for assertions, not documents

Many organisations collect raw evidence when they only need a narrow fact.

If you need to know someone is over eighteen, you may not need their full name, date of birth, address, passport number, and a copy of their face. If you need to know someone is employed, you may not need their complete personnel file. If you need residency confirmation, you may not need every line of a utility bill.

The stronger pattern is to request a trustworthy assertion containing only the fact required for the decision. This is the logic behind selective disclosure and attribute minimisation, but the principle is older than any fashionable terminology.

Ask for less. Store less. Expose less. Regret less.

Design pattern three: separate proofing from enforcement

A common mistake is assuming strong enrolment proofing removes the need for strong runtime controls.

It does not.

Someone who was verified six months ago may still be compromised today. Their device may be infected. Their credentials may be stolen. Their privileges may have changed. Their behaviour may now look deeply abnormal.

Proofing can contribute to trust, but it cannot carry trust indefinitely on its own. Systems still need monitoring, anomaly detection, sensible step-up measures, session controls, revocation processes, and competent authorisation.

If proofing is the only serious control in the environment, the organisation is not secure. It is sentimental.

Design pattern four: build reversibility

Many proofing controls persist because removing them is expensive.

Once embedded, they spread into onboarding journeys, procurement contracts, policy manuals, training materials, APIs, audit artefacts, and internal politics. Soon nobody remembers why they were introduced, but everyone can explain why changing them would be inconvenient.

So the sensible move is to design for reversibility at the start.

Keep proofing logic modular. Separate policy decisions from workflow plumbing. Avoid hard-coding proofing requirements into business processes. Make it feasible to narrow scope, replace providers, suspend checks, or retire controls without launching a transformation programme and several therapy sessions.

Every control should have a clean exit path.

Design pattern five: make proofing decisions expire

This may be the single most effective governance tool available.

Every proofing requirement should lapse unless deliberately renewed. Not the user’s identity itself, but the organisational decision that a particular proofing step remains justified.

At review time, ask whether it still reduces measurable risk, whether it creates abandonment or exclusion costs, whether the threat model has changed, whether better alternatives now exist, and whether unnecessary data is still being collected.

Without expiry, controls accumulate like sediment. Eventually the river still flows, but nobody remembers where the rocks came from.

Where strong proofing genuinely belongs

None of this means proofing is inherently bad. There are environments where strong proofing is entirely sensible and sometimes mandatory. For precisely this reason, it’s important that we don’t compromise proofing by doing it badly, or too frequently, or both.

Opening regulated financial accounts, issuing high-assurance credentials, granting access to sensitive workforce roles, enabling irreversible high-value transactions, or allocating scarce regulated resources may all justify stronger measures.

The argument is not against proofing.

It is against universal proofing, habitual proofing, and proofing used as camouflage for weak design elsewhere. Seatbelts are excellent. We do not therefore wear six while making tea.

The next phase: portable trust signals

This conversation matters now because the market is shifting. Digital wallets, verifiable credentials, selective disclosure mechanisms, and improved attribute exchange models may reduce the need for every service to independently collect raw evidence.

Instead of repeatedly demanding original documents, organisations may increasingly rely on reusable, privacy-preserving trust signals that communicate only what is necessary.

This will not create paradise. It will create new governance questions, interoperability disputes, and product slides containing the word ecosystem far too often.

But it does offer a path away from endless document re-submission and duplicated proofing journeys.

The strategic question for organisations is straightforward: which decisions truly require original evidence, and which merely require a trustworthy claim?

Those who answer that now will design better systems later.

What leaders should do now

Leaders do not need a three-year programme to improve this area. They need curiosity and a tolerance for uncomfortable answers.

Review existing proofing steps. Trace each one to a real decision. Measure abandonment and complaints. Examine retention of sensitive evidence. Challenge anything defended only because it is “industry standard.” Require periodic renewal of controls.

Most importantly, create permission for teams to simplify proportionately. Many practitioners already know certain controls are excessive. What they often lack is organisational air cover.

Provide it.

Final thought

Proofing creep is understandable. Faced with uncertainty, organisations reach for visible certainty. Identity verification feels tangible. It produces dashboards, reports, scores, screenshots, and the comforting impression that ambiguity has been defeated.

Usually ambiguity has merely been moved elsewhere.

Trust does not come from collecting the maximum possible identity data. It comes from making better decisions with the minimum necessary data, reviewed regularly, enforced intelligently, and explained honestly.

Anything else is paperwork with a user interface.

If you’re interested in other thoughts I have on digital identity, privacy, and corporate governance, I encourage you to read through this site or follow me on LinkedIn.