Technology

Why Digital Identity Is Becoming Business Infrastructure

Sep 24, 2026 • 8 min read

A customer who cannot sign in cannot complete a purchase. An employee locked out of a system cannot serve that customer. A contractor with access that lasts too long can create a different problem. These events often sit in separate budgets, yet they share a common question: how does a company establish who someone is, decide what that person can do, and maintain confidence as the relationship changes?

Digital identity has traditionally appeared to be a narrow security function. It is now part of the infrastructure behind sales, service, hiring, payments and partnerships. The shift is visible in NIST’s digital identity guidelines, which treat identity proofing, authentication and federation as related but distinct tasks. A business can improve its login screen and still leave the rest of that chain weak. The practical challenge is to make trust dependable without asking every user to repeat the same burdensome checks.

When a company opens an account, it may need to establish that the applicant is a real person, that the information supplied belongs to them, and that the level of assurance suits the activity. A newsletter account and a loan application do not carry the same risk. Nor do a payroll administrator and a temporary supplier need identical access. NIST separates proofing from authentication for this reason: confirming an identity at enrolment does not settle how that person should sign in tomorrow, or whether a particular transaction needs a fresh check.

The distinction matters commercially. Repeated document requests can drive abandonment, while inadequate checks can expose a business to fraud or disputes. A sensible design asks what evidence is needed for each action, how long it should remain valid, and what happens when circumstances change. A lost phone, a new device, a change of role or a suspected account takeover can each require a different response. Building those recovery paths into the service is as important as making the first sign-in smooth.

Identity is also a continuing access decision. Employees join, move between teams and leave. Contractors need defined scopes and expiry dates. Customer permissions may change as products and regulations change. Treating all these events as one permanent approval invites privilege to accumulate. A clearer system records who approved access, which services it covers, and when it should be reviewed. Those records help a company resolve incidents and explain decisions to customers, auditors and partners.

Passwords remain familiar, but they can be reused, stolen or entered into convincing fake pages. The US Cybersecurity and Infrastructure Security Agency’s guidance explains why phishing-resistant multifactor methods offer stronger protection against that form of attack. Passkeys are one route. They use cryptographic credentials tied to a service and can let a user authenticate with a device rather than type a password into a website.

The appeal is wider than security. In its 2025 Passkey Index, the FIDO Alliance reported experience from nine member organisations that had deployed passkeys. It found high eligibility and stronger sign-in completion among the participating services. These are findings from a small, self-selected group of implementers, not a guarantee that every business will see the same results. They do show why authentication is increasingly discussed as a conversion and support issue as well as a defensive control.

Migration takes care. Many users still move between devices or share access to household services. A company must decide how accounts are recovered when a device is unavailable, how old authentication methods are retired, and whether a fallback creates a weaker route into the same account. Staff training and customer communication matter because a secure method can fail operationally if users cannot understand when and why it appears. The economics should include support contacts, failed transactions and fraud exposure, not just the licence cost of an authentication tool.

Credentials that can travel between organisations

Companies repeatedly ask people to prove qualifications, status or eligibility. The W3C Verifiable Credentials Data Model 2.0 sets out a way to express claims that an issuer can sign and another party can verify. In principle, a credential could let an organisation check an attribute without rebuilding the entire evidence trail from scratch. The standard describes a technical model; it does not, by itself, resolve who is trusted to issue a credential or whether a relying business must accept it.

That governance question is central. A valid signature says that a credential has not been altered and identifies its issuer. It does not prove that the issuer made a sound underlying decision, that the claim is still current, or that it answers the receiving organisation’s legal and operational requirements. Businesses need policies for revocation, expiry, disputes and changes in status. They also need a way to avoid collecting more personal information than the decision requires.

The European Commission’s work on the EU Digital Identity Wallet illustrates the potential scale of this approach: credentials and digital identification could be used across public and private services. Companies should avoid assuming that one wallet or credential type will serve every market. Interoperability depends on technical rules, legal acceptance, issuer coverage and user adoption. Pilot projects are useful when they test these conditions with real customer tasks instead of merely showing that two systems can exchange a token.

A business decision with several owners

Identity design touches security, product, legal, customer support and operations. Security teams may want a strong challenge at every risky step; product teams may want fewer interruptions. Privacy specialists will ask why each attribute is collected and retained. Operations teams need recovery routes that work at scale. These priorities can be reconciled through a shared risk model: identify important journeys, define assurance appropriate to each step, and measure where users encounter friction or fraud.

A useful scorecard would look at successful sign-ins, failed recovery attempts, support demand, suspicious activity and the time taken to remove unnecessary access. None of those measures alone captures success. A rising sign-in rate could hide an unsafe fallback; a fall in fraud reports could reflect weaker detection. Reviewing them together makes it easier to see whether a change improved the whole system.

Put the exception paths under scrutiny

Identity programmes often focus on the normal journey: a user arrives, presents a credential and gains access. The costly cases happen when that journey fails. A customer might have a new surname, lose a device or be unable to use a particular biometric method. An employee might need urgent access while the identity platform is unavailable. The exception path should specify what evidence is acceptable, who can approve it, how the decision is recorded and when temporary access expires. Otherwise a strong front door can be bypassed through a weak help desk process.

Accessibility is part of that design. An authentication method that assumes everyone owns the latest phone, can receive a text message, or can complete a screen-based challenge may exclude legitimate users. Offering alternatives creates a security design problem rather than a reason to disregard accessibility. Companies can define several routes with comparable assurance and test them with the people who must use them. Measuring abandonment by customer group and device type can reveal a problem that an overall success rate conceals.

The same principle applies to automated checks. A document verification tool may reject a genuine document because of lighting, damage or an uncommon format. If the appeal process is slow or opaque, the business can lose a customer while maintaining a technically correct fraud control. Human review is valuable when reviewers have clear criteria and can see why the system made its decision. It becomes a new risk when staff are pressured to override checks without evidence.

Make trust portable without losing accountability

Federation allows one organisation to rely on an identity assertion from another. That can spare users another password and reduce duplicated administration, but it creates questions about the reliability and scope of the assertion. A business should know when it was issued, how the person authenticated, which attributes were checked and what it may legitimately infer. A partner’s assertion that someone is an employee, for example, does not necessarily authorise access to confidential financial records.

Contracts can allocate responsibilities for incidents and changes, but the technical implementation must enforce those boundaries. If a partner loses its ability to verify people or changes its standards, relying organisations need a way to respond. Testing the termination of a trust relationship is especially important: can access be withdrawn promptly, and are active sessions handled as intended? This is where identity management begins to resemble supply chain management, with each participant dependent on another’s controls.

Measure improvement across the full journey

An identity programme should start with a small number of important journeys, such as opening an account, changing payment details or granting an administrator role. For each journey, record the risks, required evidence, time to complete, drop-off points and support demand. Then make one change at a time and review what happened to both legitimate users and suspicious attempts. This prevents a gain in conversion from hiding a loss in assurance, or a security gain from masking an unusable recovery process.

The investment case will vary by business. A retailer may care about checkout completion and account takeover. A professional services firm may focus on contractor onboarding and rapid removal of access. A regulated lender may need more evidence at enrolment and stronger records of decisions. The common foundation is a documented chain from proofing to authentication, authorisation, recovery and revocation. Once that chain is visible, technology choices can be judged by how they improve it.

Digital identity is becoming business infrastructure because it sits between a company and nearly every digital relationship it maintains. Better technology helps, but durable value comes from defining who may make a claim, how it is checked, what access follows and how mistakes are corrected. Firms that treat those questions as part of service design can build both stronger controls and a more usable experience.