Digital Transformation Fails at the Login Screen

More often than not, that something is identity. Not the strategy, not the platform choice, not the migration. The login screen, and everything sitting behind it.

The pattern is consistent enough to be worth naming, because it is avoidable and because fixing it late costs several times what fixing it early would have.

Three Symptoms of the Same Problem

Organisations usually experience this as three separate complaints, raised by three different departments, none of whom connect them.

Customers dropping out at sign-up. Marketing reports it as a conversion problem. The remedy proposed is usually more marketing.

Staff managing separate accounts across systems. Operations reports it as a productivity irritation. The remedy proposed is usually training.

Legacy systems that cannot share a user. IT reports it as a technical constraint. The remedy proposed is usually a replacement project.

All three are the same underlying fact. There is no single, authoritative answer to the question of who this person is, so every system has invented its own.

Once that is true, each new platform in the transformation programme adds another identity silo rather than resolving any. The programme makes the problem worse while appearing to make progress.

Why a Customer Identity Platform Changes the Sequencing

The correction is not a bigger integration budget. It is a change in the order of work.

Ory publishes an approach to consumer-facing identity at scale, and the argument for adopting a customer identity platform early rather than late is a sequencing argument rather than a feature one, because every subsequent system can then be built against a single source of truth instead of inheriting another fragmented one.

That is the distinction worth putting to a board. Identity is not a workstream within transformation. It is a dependency of every other workstream.

The standards underneath this are mature, which removes a common objection. RFC 6749 has defined the framework for delegated authorization since 2012, introducing an authorization layer that separates the client from the resource owner and issuing tokens with defined scope and lifetime.

This is not an emerging technology decision. It is an architectural one that most organisations are simply making by default rather than deliberately.

The Federation Question Most Programmes Miss

Where identity gets genuinely difficult is the boundary between organisations, and transformation programmes almost always cross one.

A partner portal, an acquired subsidiary, a white-labelled service, a supplier network. Each requires that identity assertions travel between systems under separate administration.

NIST guidance on federation and assertions describes an identity provider conveying authentication attributes, and optionally subscriber attributes, to separately administered relying parties, and notes that relying parties may use more than one identity provider.

Separately administered is the phrase that costs money. Two organisations means two change schedules, two certificate rotations and no shared maintenance window.

Programmes that design for federation from the outset absorb an acquisition in weeks. Programmes that bolt it on afterwards spend quarters on it.

There is a related detail that catches consumer-facing services out. MDN documents that a cookie with SameSite=Strict is sent only for same-site requests, and that SameSite=None requires the Secure attribute or browsers reject it.

Which means an architecture that authenticates on one domain and serves the service from another is making a browser-level decision about whether customers stay logged in. That is a strategic consequence of a technical default, and it is exactly the kind of thing discovered in week eleven of a twelve-week project.

The Regulatory Dimension

Identity is also where data protection obligations concentrate, and that raises the cost of getting it wrong late.

Customer credentials and profile data are personal data by definition, and where that data is processed is a legal question rather than an infrastructure preference.

Under EU law, Chapter V of the General Data Protection Regulation, covering Articles 44 to 50, lays down the rules governing transfers of personal data to third countries, as set out in EU regulation documents applying that framework.

For any business trading across borders, that makes the location of the identity store a board-level consideration. Retrofitting data residency into a live identity system is among the more expensive corrections available.

Organisations that can self-host or select a region answer this question once. Organisations that cannot answer it in every enterprise sales cycle they enter.

What Changes When Identity Goes First

Four things, in the experience of programmes that have reordered the work.

Integration effort falls, because each new system authenticates against one existing thing rather than negotiating with several.

Sign-up friction becomes a solvable problem rather than a structural one, since the flow lives in a single place that can actually be changed and measured.

Internal account sprawl stops growing, which reduces both the operational burden and the security exposure of orphaned accounts.

And enterprise sales cycles shorten, because the security questionnaire has real answers rather than roadmap commitments.

None of that shows up in a transformation business case, which is precisely why identity keeps getting scheduled last.

The Practical Recommendation

Audit how many places a customer record currently exists before approving any new platform. The number is usually higher than the sponsor expects.

Treat identity as phase one rather than as an integration task within phase three.

Design for federation on the assumption that an acquisition, partnership or white-label arrangement will arrive within three years, because one usually does.

And settle the data residency question before signing anything, rather than during the first enterprise deal that asks about it.

Transformation programmes are judged on what they deliver. They are constrained by what they were built on top of, and for most organisations that foundation is the login screen nobody costed properly.

Promotional material:

Summary: Transformation programmes rarely fail on strategy. They fail because identity was scheduled last, leaving every new platform to inherit a fragmented user model.

Pull quotes:

• "Identity is not a workstream within transformation. It is a dependency of every other workstream."
• "The programme makes the problem worse while appearing to make progress."
• "Separately administered is the phrase that costs money."

Photo by Markus Spiske: https://www.pexels.com/photo/laptop-screen-in-close-up-shot-8247921/ 

‍