What should teams do when strong authentication is too costly or complicated to scale?

Teams should move toward standards-based authentication that can be deployed consistently across large user populations and multiple services. The key is to avoid bespoke approaches that increase support burden and reduce adoption. Open specifications and certified devices help organisations balance security, interoperability, and usability without creating fragmented access experiences.

Why Standards-Based Authentication Scales Better Than Bespoke Controls

When strong authentication becomes too expensive or too hard to deploy everywhere, the practical answer is not to weaken the control, but to standardise it. Standards-based methods reduce integration variance across applications, devices, and user populations, so teams can enforce one consistent sign-in pattern instead of maintaining multiple custom flows with different support burdens.

This matters because authentication only scales when the experience is predictable enough for users and support teams. A bespoke approach often looks flexible at first, but it usually creates fragile exceptions, inconsistent recovery paths, and more opportunities for bypasses or misconfiguration.

Open specifications and certified devices are especially useful when the organisation needs both interoperability and assurance. They let teams deploy a control once and reuse it across services, which is easier to govern than designing a unique authentication pattern for every platform or business unit.

What Teams Should Optimise For During Rollout

The main decision is not simply “stronger versus weaker,” but whether the method can be rolled out repeatedly without creating a different workflow for every team. Standards-based authentication is most valuable when it lowers the cost of adoption, reduces help desk friction, and still gives security teams a clear control baseline.

That is why open, widely implemented protocols and certified authenticators tend to outperform one-off integrations. They improve consistency across browsers, mobile devices, laptops, and third-party services, and they make it easier to retire legacy methods without forcing each application owner to invent its own sign-in logic.

Teams should also think about recovery and fallback at the same time as primary sign-in. If recovery is awkward, users will pressure teams to keep weaker alternate paths alive, which undermines the point of strong authentication in the first place.

How to Avoid Fragmented Access Experiences

Fragmentation usually appears when each service chooses its own login method, its own device assumptions, or its own exception handling. The result is more training overhead, more support tickets, and more user workarounds, all of which make adoption harder and security less reliable.

A better pattern is to make the identity layer consistent and let services consume the same authentication capability through shared standards. For teams choosing a platform or rollout model, NHIMG’s IAM and Identity Provider Buyer’s Guide is useful because it frames SSO, MFA, lifecycle, and vendor fit as one operating decision rather than a set of disconnected products.

For the actual sign-in mechanism, teams should favour methods that are already designed for broad interoperability. NHIMG’s Passwordless and Passkeys Guide is directly relevant when the goal is to replace brittle legacy sign-in with something that can be deployed at scale and recovered safely.

Risk and Threat Considerations

Weakly standardised authentication does not just increase support effort, it also increases attack surface. The more bespoke the deployment, the easier it is for legacy paths, fallback methods, and partial rollouts to remain in place after teams believe they have “upgraded” security.

Failure mechanism: Attackers look for the least consistent path, such as legacy authentication, uneven MFA coverage, poorly governed recovery, or per-application exceptions that bypass the intended control. Once one path is easier than the others, it becomes the path of least resistance for abuse.

Impact: The organisation keeps paying for a complex control but does not get uniform protection. That creates uneven assurance, more account takeover exposure, and a persistent gap between policy and real-world authentication behavior.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	The question is about scalable strong authentication and interoperable deployment.
Recommendation — Use phishing-resistant authenticators and AAL-based assurance to standardize enterprise sign-in.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	The subject concerns enterprise user authentication at scale.
	IA-5 — Authenticator Management	Scaling strong authentication depends on managing authenticators and recovery consistently.
Recommendation — Implement organization-wide authentication controls for user access. Manage authenticator lifecycle and recovery centrally to avoid inconsistent exceptions.
ISO/IEC 27001:2022	A.5.15 — Access control	Standardized authentication supports controlled access across multiple services.
	A.8.5 — Secure authentication	The question directly concerns choosing a secure, scalable authentication approach.
Recommendation — Define a consistent access control model that can be applied across services. Adopt secure authentication methods that can be deployed consistently.

Practitioner Guidance

What to prioritise: Start with the authentication methods that can be deployed across the most services with the fewest exceptions. If a control cannot be rolled out consistently, it is usually too expensive to be the primary enterprise pattern.

What to verify: Confirm that the chosen method has a workable recovery path, supports your major device populations, and can be enforced without per-application custom logic. If either recovery or enforcement is fragile, adoption will stall and workarounds will appear.

Common mistake: Treating “strong authentication” as a product choice instead of an operating model. The real test is whether the control survives scale, support pressure, and service diversity without splintering into exceptions.

Practitioner takeaway: At scale, the best authentication control is the one teams can deploy uniformly, support predictably, and retire legacy paths around without creating a parallel world of exceptions.