The Speed of Trust

Digital trust is the thing executives believe they're buying. It appears in strategy decks, in vendor categories, in the risk section of the annual report. ISACA, which has done more than anyone to define it, calls it "the confidence in the integrity of the relationships and transactions between providers and consumers within a digital ecosystem," and the professionals they survey agree it matters: in ISACA's State of Digital Trust 2024, built on responses from more than 5,800 professionals worldwide, 82% said digital trust would become more important over the next five years.

Then there's the other half of the same research. In its European cut — 1,161 business and technology professionals surveyed in January 2024 — 77% agreed digital trust is crucial to digital transformation, and 77% reported that their organizations either don't measure the maturity of their digital trust practices or don't know whether they do. Only 21% were planning to increase the budget for it. Nearly three quarters, 71%, provided no staff training on it at all.

A thing that everybody values and almost nobody measures isn't a strategy. It's a mood.

My argument is that digital trust does have a measure, that it's unglamorous and entirely countable, and that most organizations already have the data to calculate it this week. The measure is this: how fast can you safely extend trust to someone who was outside your organization yesterday — and how fast can you take it back?

Trust is only visible at the boundary

Inside your own walls, trust is an abstraction. Your employees are already in. The systems already talk. Nothing is tested.

Trust becomes observable at a boundary — the moment somebody who wasn't there before is let in. A customer who has never had an account. A partner's staff, who work for someone else and always will. Several thousand employees who belonged to another company until midnight. An auditor who needs to see evidence without seeing everything.

That act — letting an outsider in, under terms, with the ability to reverse it — is identity. Not a part of identity. The whole job. Which means digital trust isn't an atmosphere that surrounds your technology estate. It's a capability, with a clock on it, and the clock can be read.

Four moments read it for you, and all four run on dates you don't control.

Day one is a date somebody else set

Acquisitions make the point most sharply, because the deadline is a legal fact rather than a preference.

Bain's 2026 M&A Midyear Report puts deals above $10 billion at roughly 7 months from announcement to close, with another 24 to 36 months to realize the bulk of run-rate cost synergies, and notes that large deals frequently take 36 months or more from announcement to full integration. Deloitte, writing about banking integrations, says IT drives more than half of the synergies in many of those deals, and that full integration often takes years.

Put those together and the shape appears. Most of the value is in the technology integration. Most of the technology integration is measured in years. And the single piece of it that can't wait years — or weeks, or a day — is the trust decision: on day one, people who worked for someone else need to authenticate as part of your company and keep serving customers who didn't agree to an outage.

What makes it a trust decision rather than a provisioning one is what you're actually agreeing to. Federating to the acquired company's directory means accepting their authentication, their joiner-mover-leaver process, and their administrators — on day one, before anyone has audited any of it, and including whatever is already in that estate. Migrating everyone into yours means a slower day one and a harder quarter.

My view is that this is the highest-leverage identity decision an acquisitive company makes, because federating buys the window and migrating spends it, and which is right depends on things you can know before the deal exists: how long the two estates must coexist, whether the company is being absorbed or run separately, and whether anything revenue-facing needs a single view of both populations inside the first quarter. The firms that do this well aren't faster at the work. They decided the pattern years earlier.

Partners: a case I've already made

The partner version of this argument is one I wrote in The Collaboration Multiplier, and I'm not going to run it again here. That piece is about the operating model — who's inside your estate, what they can reach, and how fast you can get them out. It stands on its own.

What belongs in this one is the evidence, because somebody has finally counted the spread. Convert Commerce's Partnerships Benchmark 2026, a survey of 102 partnership professionals conducted between October and December 2025 across North America, EMEA and APAC, found that 76% of organizations complete partner onboarding within one to two months: 19% inside two weeks, 31% in three to four weeks, and 26% in one to two months. 24% take three months or longer. Partner activation was the single biggest partner-management challenge, named by 26% of respondents, ahead of internal alignment at 22%.

Nothing in that survey is about identity, and I won't pretend otherwise. I cite it because it's the clearest published picture of the thing this article asks you to measure: the same decision, taken by comparable companies, with a latency that varies by an order of magnitude. The fast quartile has a partner selling inside two weeks. The slow quartile is still onboarding a season later.

That variance isn't mysterious. It's whether the pattern existed before the partner did.

A region is a regulator's terms for trusting you

Entering a market looks like a legal question and a tax question. Underneath, much of it's a trust question with technical consequences.

Where the directory lives. Where authentication happens, and whose border it crosses. Whether staff in that country can be administered by a team somewhere else. What the local regulator expects you to be able to prove about who had access to what, and how quickly you can prove it. These aren't launch-week items. They're architecture, and reversing them after launch is a migration.

I'm labeling this as my own view, because I didn't find research I would stand behind on how often regional launches slip for identity reasons. But the pattern across the programs I've run is consistent: the region is chosen, the entity is formed, hiring starts — and only then does somebody ask how people in that country will sign in, at which point the answer has to be built rather than configured.

One measure, four speeds

The fourth moment is the fastest, and it's the one I wrote about in The Customer Experience Equation: a returning customer, brought back by an ad somebody paid for, handed to a password field at the moment of highest intent. I argued there that this is a growth problem wearing a security costume.

It's also this same measure at a different scale. A customer at a sign-in screen is someone you can't yet distinguish from a stranger, asking to be let in. The act is identical to federating an acquired directory. Only the clock is different:

• Seconds — a customer signing in, where the cost of hesitation is a visit that doesn't convert.
• Hours — day one after a close, where the deadline is legal and the audience is the people you just bought.
• Days — a partner going live, where the competitor is the other vendor in their portfolio.
• Quarters — a region, where the counterparty is a regulator and the decisions are architectural.

That's the shape of the thing. Digital trust isn't four problems; it's one capability read at four speeds, and an organization can be superb at one and hopeless at another. Most are. The sign-in flow gets tuned to the millisecond by a growth team with a dashboard, while the request to let a partner in sits in a queue nobody has ever timed.

Launches sit across two of those scales at once, which is why they catch people out. A launch rarely slips because single sign-on took a week. It slips because somebody discovers in the final month that the new product needs a different trust boundary than the old one — business customers who administer their own users, a free tier that must not share an identity space with the paid one, a partner-branded version that can't show your login page. Those aren't features you add late. They're the shape of the system, and the shape is a statement about who's trusted to do what.

Why it's always discovered late

It would be easy to call this a planning failure. It's more specific than that, and the specifics are what make it fixable.

Identity is downstream of rooms it's not in. The decision to enter Germany is made in a strategy review. The decision to acquire is made in a deal room under an embargo that deliberately limits who knows. The launch date is set in a product council. The partner is signed by a team measured on signings. In every case the date is set by people who aren't thinking about authentication and have no reason to — that's what it means for infrastructure to be invisible.

The date then arrives at identity as a fact rather than a question, usually with a plan already drawn. And the honest answer — "that depends on something we have never had to do before" — sounds like obstruction when it arrives that late.

The asymmetry is what makes it expensive. Deciding the federation pattern a year early costs a few weeks of unglamorous work nobody will praise. Deciding it the week after announcement costs the window, and the window is what the deal was buying. One of those mistakes appears in a roadmap review. The other appears in a board deck as "integration delays."

There's a structural version too, which was the subject of The Box Is Not the Program: if nobody can say who owns identity, nobody is on the distribution list when a date gets set. Being told late isn't bad luck. It's what happens to a function whose placement was never settled.

The half nobody measures: taking it back

Everything above is about extending trust. The other half of the definition is the part that makes speed safe, and almost nobody puts a number on it.

You can't responsibly extend trust you can't withdraw. The partnership ends, and their staff still have access. The acquisition gets divested two years later, and the federation that made day one painless is now a door into a company you no longer own. The contractor's engagement finishes. The regional entity closes. Each is the same event in reverse, and each is slower than anyone expects, because withdrawal was never designed — it was assumed.

This is also the honest answer to anyone who reads an argument about speed as an argument against care. Some things should take the time they take. A partner who wants deep access to systems holding other customers' data should wait while somebody thinks about tenancy. A region with a residency rule isn't a place to improvise. Federating to an estate nobody has audited is a real risk, not a theoretical one.

But notice what makes those cases safe: not slowness itself, but reversibility. Trust you can withdraw in an afternoon can be extended in a morning. Trust that takes two quarters to unwind deserves two quarters of deliberation before you grant it. The organizations that look fast are usually the ones that built the exit before they needed it.

Trust mechanisms are lead-time items

If this is right, the fix is procurement logic rather than security logic. You don't order a long-lead item when the project starts. You order it before, because the schedule assumes it's already there.

For digital trust the lead-time items are mechanisms, not products:

• A federation pattern. How an organization that's not yours gets access to systems that are yours — decided and walked end to end before the first acquisition or partner needs it, including how the federation is dissolved.
• A tenancy pattern. How customers, partners and staff are separated so the first unusual deal doesn't require a rebuild.
• A regional pattern. What stays local, what moves, and what that means for authentication and administration, settled before the region is chosen.
• A day-one pattern. What happens in the first 24 hours after a close, written while nobody is under pressure, with a named owner who can execute it without asking permission.

None of that's exotic. All of it loses to the quarter's roadmap, every quarter, until a date gets set and the work becomes urgent and expensive on the same afternoon.

The other half is being told, which is a process problem rather than a technical one. Four triggers are worth wiring in, and none of them requires anyone to break a confidence:

• A deal reaches diligence. Identity doesn't need the target's name to answer the question that matters: are we federating or migrating, and what does each cost in weeks? One person under the same NDA as the rest of the deal team turns day one from improvisation into execution.
• A region makes the shortlist. Not when it's chosen — while it's still one of three. The residency and administration questions are cheap then and expensive later, and occasionally they change which region wins, which is exactly the sort of input a strategy review should want.
• A partner reaches term sheet. The access model is a commercial term whether or not anyone writes it down. What they can reach, through whose identity provider, and how fast it can be revoked all get harder to negotiate after signature.
• A product decides its trust boundary. The moment a product council says "customers will administer their own users" or "there will be a free tier," an identity decision has been made. Somebody should be in the room to notice.

That's four distribution lists and one standing invitation. It converts identity from a function that receives dates into one that shapes them.

Two numbers

The phrase "the speed of trust" is Stephen M. R. Covey's, from his 2006 book arguing that trust moves at the speed of business — that low trust taxes every transaction and high trust pays a dividend. I think he was right and incomplete. In a digital business, trust isn't only a cultural quality that makes things faster. It's a mechanism with a measurable latency, and the latency is the thing you can manage.

So here are the two numbers that make digital trust testable, neither of which requires a maturity model.

Time to extend. The lead time between a market decision and the first outsider who can log in. From "we are entering Germany" to the first German employee signing in. From "we signed the partner" to their first rep working in your system. From "the deal closed" to the acquired company's staff operating as part of your company. Take the last four such decisions and measure them.

Time to withdraw. The same journey in reverse, measured honestly rather than from the policy document. From "the partnership ended" to the last of their people losing access. From "we divested" to the federation being gone.

Write them on the same slide, because the pair is the point. A short time to extend with an unknown time to withdraw isn't trust; it's exposure wearing trust's clothes, and it's the state most organizations are actually in. A long time to extend with a crisp withdrawal is a company being careful in the only defensible way — it's still losing windows, but it knows what it's paying and why.

What distinguishes the organizations I would copy isn't that both numbers are small. It's that somebody can say what they're without going away to find out, and that the people who set dates know them before they set one. A number nobody can recite isn't a measure. It's an intention, which is where this started.

So: 82% expect digital trust to matter more over the next five years, and roughly three quarters of them aren't measuring it. That gap doesn't close by adopting a framework. It closes the first time somebody puts two durations on a page and says what they're going to do about the larger one.