Logging into endless accounts and apps is a fundamental, and often onerous, part of the citizen experience. We’re inundated with the need to remember and frequently update passwords, and to access security codes, which adds an extra layer of admin to already busy lives. One Login can greatly reduce stress for the public through better-designed services. But its potential to transform should be treated with a healthy dose of pragmatism.
One Login has been successful precisely because it is constrained. With the ongoing rollout of the system across central government, galvanised by the 2027 mandate, there is a golden opportunity to rethink and redesign some core public services without repeatedly rebuilding infrastructure.
Yet its transformational potential must be tempered and grounded in reality. Any hopes and dreams that extend beyond its original scope—such as joined-up government or cross-government data sharing—face a quagmire of legal, organisational, and political challenges.
The real impact, however, of moving from anonymous, stateless transactional interactions to known-user interactions is very real. By viewing One Login as a powerful enabler of known-user journeys, departments can make better design decisions to enhance the citizen experience.
Misunderstanding the role of One Login
One Login was designed for authentication, with optional identity proofing. It enables a shared, privacy-preserving foundation for individual services such as Companies House, DVLA, DBS, DWP, GOV.UK app, and the Private Rented Sector Database (which we built and integrated with the Ministry of Housing, Communities and Local Government (MHCLG)). Its scope is intentionally narrow, with a strong focus on privacy preservation.
What One Login does not do is authorisation, create universal identifiers, or, crucially, automatically share data across services. These constraints are deliberate. They reduce risk, prevent inappropriate correlation between services that people would reasonably expect to remain separate, and help maintain public trust.
For example, the fact that someone has used a service related to benefits, criminal records, compensation, or licensing should not automatically be visible to other parts of government without a clear legal basis and user consent. These boundaries are intentional, but they are often misunderstood.
The two common One Login traps
In practice, teams may fall into one of two traps:
- Some assume One Login will unlock joined-up government by default, and quickly run into legal, organisational, and political barriers that sit well outside the platform’s remit.
- Others treat One Login as purely a technical integration to satisfy the mandate, changing little more than the sign-in screen while leaving transactional, form-heavy journeys untouched. This is where much of the pain (and opportunity for improvement) sits.
Both approaches miss the point. Overreach leads to disappointment. Underuse locks in the same service patterns for another decade.
A shift in the economics of service design
Before One Login, any service that wanted secure accounts or identity verification had to design, build, and operate its own solution. This resulted in 191 different ways for people to set up accounts and 44 different sign-in methods, wasting people’s time and costing the taxpayer money.
The sheer level of work involved—months of delivery effort, ongoing operational costs, complex security considerations, and support issues such as password resets and account recovery—was simply too high a barrier.
Many teams, therefore, and understandably, defaulted to anonymous, one-off transactions, even while recognising the benefits of continuity.
Typically, these are services with:
- Multi-step applications
- Regulated processes
- High support demand driven by lack of visibility
In these cases, design effort is best spent on clarity rather than breadth. Clear logged-in entry points that show status, history, and next actions matter more than complex personalisation. Confirmation-based journeys work where data ownership and consent are clear. Context-aware prompts make sense within a service boundary, not across unrelated services. These data guardrails help avoid cross-department data issues that raise eyebrows (and blood pressure).
It is also important to be explicit about boundaries. One Login provides authentication, but authorisation remains the responsibility of each service. Identity can be verified, but entitlement must still be determined locally. Identifiers are service-specific by design, with limited reuse across agreed sectors.
Design thinking should lead these decisions, but it needs to lead within constraints.
Familiar patterns of designing around known identity
Some services already provide account-style access where multiple related journeys share a coherent user record. Application-based services allow users to check progress, update information, or resume without starting again, much like filling in an online form for banking, insurance, or even returning to a shopping cart. Submission or payment histories are visible within a single service. Confirmation-based flows replace long re-entry forms once trust has been established.
What this does not yet look like is a single citizen dashboard spanning departments, automatic eligibility checks across policy areas, or silent data sharing between unrelated services. While there is interest in exploring more joined-up entry points, for example, through the GOV.UK App or the One Login account area, this work is currently constrained by the same technical, legal, and privacy boundaries discussed earlier and is not the primary focus today.
At a very basic level, the One Login account currently shows service cards for each service a user has accessed using their One Login credentials. These do not expose data from those services. Instead, they provide a simple, privacy-preserving way for users to return to the services they have already used. Being clear about this distinction helps prevent overclaiming and avoids design decisions that would undermine trust.
One Login benefits, without hype
When done well, identity-led design delivers benefits that are visible early.
Early adopters of One Login are already seeing tangible improvements. Identity checks are completed more reliably, more users self-serve end-to-end, and demand shifts away from paper and manual fallback processes. And savings are generated by removing friction in individual journeys.
For citizens, it reduces repetition, provides clearer visibility of progress and next steps, and makes interactions feel more predictable. For operational teams, it reduces duplicate or incomplete submissions, cuts manual follow-up, and lowers support demand from users chasing updates. At a system level, it avoids the repeated cost of rebuilding authentication and identity infrastructure, strengthens centralised fraud controls, and supports more coherent services without eroding privacy protections.
What it does not do, on its own, is deliver joined-up government.
Clearing up misconceptions around One Login
Some misconceptions are worth addressing directly. Authentication is not authorisation. Known identity is not a universal identifier. Logging in once does not grant access elsewhere. Privacy constraints are intentional, not accidental. And the hardest barriers to joined-up services are legal and organisational, not technical.
Naming these realities clearly helps senior leaders make better decisions.
Looking beyond the mandate
For departments, the shift is to treat One Login adoption as a design decision rather than a delivery milestone. The focus should be on making individual services genuinely usable for known users before aspiring to cross-service coherence. That means investing in service-level data models and being honest about what is achievable in the next year or two.
For central bodies, there is an opportunity to provide clearer guidance on appropriate confirmation-based journeys and sensible limits to personalisation.
One Login removes much of this barrier. By providing authentication and identity as shared capabilities, stateful services are now more viable than ever – especially for application-based services, regulated interactions, or journeys where users need to return multiple times.
This shift does not create system-wide transformation. It is a practical opportunity for individual services where it matters most: such as DBS allowing users to easily view their digital certificates after application, or enabling content personalisation in the GOV.UK App.
The benefits of services designed for known users
A few significant shifts occur when services are designed around known users rather than anonymous visitors.
One-off submissions become account-based interactions. Users can sign in, see what they have done, and understand what happens next. Repeated data entry gives way to confirmation and progression, avoiding the all-too-familiar frustration of starting again from scratch.
For everyday life admin that is stressful or time-consuming, such as childcare, managing licences, or running a business, these shifts are high-impact and, in some cases, life-changing.
While this is not joined-up government, it is a tangible improvement that people will feel.
Designing within the real constraints
Recognising what One Login can and cannot do is important, as it draws a clear line around when a service should be stateful and when it should not.
Some services need to be treated as places users return to, not forms they disappear into. Known identity enables continuity within a service without inferring or correlating activity across departments. This state is owned and managed by the service itself, rather than from a centralised point.
Crucially, not every service should become stateful. The opportunity lies in being selective. Which services and journeys genuinely benefit from continuity and lead to better outcomes, and how sector identifiers can and cannot be used. Mandate timelines also need to align with delivery reality, without implying that One Login itself equates to joined-up services.
The 2027 deadline is a moment for departments to decide whether they are locking in transactional services for another decade, or using a shared foundation to build services people can return to.
One Login will not transform government on its own. But used well, it removes many of the excuses for not improving individual services.
Looking to explore One Login?
We have deep experience with One Login and in designing public services, and we would love to help you move forward with clarity. Discover more.
