How we authenticate online has changed dramatically over the past five years. Our increasing reliance on cloud services, for both core systems and Software as a Service applications, has led to a general move toward a Zero Trust methodology, whether as a deliberate IT strategy or simply organic drift. The technologies we use to provide this protection have changed over the past few years, and so we’ve written this post to help unpick the current state of play.
Want to speak to our security experts?
Click here or email: contact@reliancecyber.com
We’ve long known that passwords alone offer poor security, and advice and standards have changed over the years to fill the gaps. Nowadays, most of us are aware we shouldn’t be relying on passwords alone, and the use of Single Sign-On (SSO) and Multi-Factor Authentication (MFA) has become ubiquitous. In this post, we’ll be discussing how this is done within a contemporary tech stack.
The way digital identity is established and managed has undergone a paradigm shift, where juggling multiple passwords is being replaced by passkeys built upon robust standards like Fast IDentity Online 2 (FIDO2). This aims to prevent some of our biggest security threats, like phishing and credential theft.
Let’s make sense of these technologies
FIDO2 is an open standard developed by the FIDO Alliance, an industry consortium aimed at creating stronger, more usable authentication methods. Its primary goal is to protect individuals and organisations from cybercrime by using phishing-resistant cryptographic credentials to validate user identities.
These are known as passkeys. To a user a passkey seems similar to a password, but there is a lot more going on behind the scenes. Passkeys are tied directly to your device using public-key cryptography, meaning that even if they’re stolen they cannot be used elsewhere.
When a user registers for a service that supports FIDO2, their device (the authenticator) generates a unique cryptographic key pair: a private key and a public key. The private key is stored securely on the user’s device and never leaves it. It is protected by the device’s own security measures, such as a biometric sensor (fingerprint, face scan) or a PIN. The public key is sent to the online service and associated with the user’s account.
During sign-in, the service issues a unique challenge to the user’s device. The device uses the securely stored private key to cryptographically sign this challenge, proving both possession of the device and user presence (via the biometric or PIN). This signed challenge is sent back to the service, which verifies it using the stored public key. Because the private key is never transmitted, it cannot be stolen by phishing or a server-side data breach.
FIDO2 authenticators are the devices that generate and store the passkeys. They fall into two main categories:
- Roaming (or Cross-Platform) Authenticators: These are portable hardware devices that can be used across multiple machines. They connect via USB, Near-Field Communication (NFC), or Bluetooth. Examples include hardware security keys (e.g., YubiKey) or using a smartphone to authenticate on a separate laptop. They provide flexibility, allowing users to authenticate securely anywhere.
- Platform (or Bound) Authenticators: These are integrated directly into a user’s primary device. Examples include Microsoft’s Windows Hello, Apple’s Touch ID and Face ID, and Android’s fingerprint sensors. While these were traditionally bound to specific hardware, this is evolving. Major providers like Apple and Google, along with password managers, now offer synced passkeys. These allow a passkey created on one device to be securely available across all other devices tied to the user’s account within that ecosystem (e.g., an iPhone, iPad, and MacBook). This approach bridges the gap between the security of a platform authenticator and the convenience of a roaming one, without needing to re-register on each device.
A robust method for proving your identity is just the first step. With countless linked applications and services, proving who you are repeatedly is not just burdensome, it’s a barrier to productivity and a poor user experience. A federated identity unifies authentication to create a web of trust. Federation protocols allow a user’s verified identity to be securely shared across different systems, enabling the seamless experience of SSO. Two sets of standards govern this process for most systems and applications.
Security Assertion Markup Language (SAML) is the mature, foundational protocol that enables SSO within enterprise environments. For years, it has been the underlying technology allowing employees to sign in once to their corporate network and gain access to multiple internal and third-party applications without re-entering credentials.
A SAML transaction involves an Identity Provider (IdP) that manages and authenticates the user’s identity (e.g., Microsoft Entra ID, Okta). This is the authoritative source of truth. Then there is the Service Provider (SP) which the user wants to access (e.g., Salesforce, Concur, Adobe).
When a user wants to access a Service Provider (SP, such as Salesforce, Concur, or DocuSign) they are redirected to their IdP to authenticate. Once the IdP successfully verifies the user’s identity, it generates a digitally signed XML document known as a “SAML assertion.” This assertion contains information about the user and their authorisation status. The user’s browser then passes this assertion to the SP, which trusts the IdP’s signature, grants access, and logs the user in.
For organisations, SAML is a cornerstone of unified Identity and Access Management (IAM). It allows IT teams to centralise security policies, such as enforcing MFA or conditional access rules, across all SAML-enabled applications. This simplifies user provisioning and strengthens the implementation of a Zero Trust strategy, where every access request is scrutinised.
Let’s make sense of these technologies
For modern web and mobile applications, the standard is a combination of OAuth 2.0 for authorisation and OpenID Connect (OIDC) for authentication. OAuth 2.0 is an authorisation framework that provides an approach for users to grant third-party applications limited access to their data on another service without sharing their credentials.
OpenID Connect (OIDC) is a thin identity layer built on top of the OAuth 2.0 framework. Its ID Token provides a verifiable assertion from the authorisation server about who the end-user is and uses OAuth 2.0 to provide access tokens that grant permissions. The “Log in with Google” or “Sign in with Apple” experience is the main example of OIDC in action.
This model is hugely popular due to its mobile-first design philosophy, ease of implementation for developers, and its ability to leverage existing social identities, removing the burden on applications to manage user passwords. Together, SAML and OIDC/OAuth 2.0 form the critical infrastructure for a federated digital world, ensuring that a single, strong proof of identity can be trusted and reused across a vast ecosystem of services. With cloud applications and a distributed workforce, the traditional network perimeter is replaced by a Zero Trust strategy based around the user’s verified identity, that allows more granular and context-aware security enforcement.
As organisations moved assets into the cloud, they lost direct visibility and control. Cloud Access Security Brokers (CASB) address this by acting as a security policy enforcement point situated between users and their cloud applications (e.g., Microsoft 365, Salesforce, Slack).
A CASB does not replace the primary authentication systems discussed earlier; instead, it leverages the identity they establish. After a user successfully authenticates via SAML or OIDC, the CASB inspects the context of every subsequent interaction with the cloud service. It asks who the user is and what roles and privileges they possess, what resources they’re trying to access, and where they’re connecting from.
Based on the answers, the CASB enforces granular security policies in real-time. For example, it can require a step-up authentication challenge for a user logging in from an unfamiliar country, or it can block a user from downloading a customer database onto an unmanaged personal device. A CASB ensures that the trust established at login is continuously verified and is appropriate for the resources being accessed.
Taking this a step further Secure Access Service Edge (SASE) is a framework that converges networking capabilities (like Software-Defined Wide Area Networking, or SD-WAN) with a complete suite of cloud-native security services into a single, unified platform. This suite includes CASB, as well as Zero Trust Network Access (ZTNA), Secure Web Gateways (SWG), and Firewall as a Service (FWaaS).
With a SASE architecture, such as those provided by Zscaler and Cato Networks, the security model is centred around the user’s identity. When a user authenticates with their federated identity the SASE platform applies a security policy based on their identity, device posture, and the context of the access request. The user is then granted secure, policy-based micro-tunnels directly to specific applications they are authorised to use, whether those applications are in a public cloud, a private data centre, or on the web.
Access to anything else is implicitly denied. In this model, the strong identity provided by FIDO2 and federated protocols is not just a key to a single door; it is the master key that the SASE framework uses to grant, deny, or limit access across the entire digital estate on a dynamic, per-session basis. This is the practical application of a Zero Trust philosophy, moving security from a location-centric to an identity-centric model.
Preventative controls are only part of the equation, visibility and the ability to respond to threats at speed are also important. These controls are not just preventative measures; but also provide security telemetry that can be used for incident detection and rapid response.
Every event within these modern identity systems, such as a successful passkey validation, a failed biometric check, a device health attestation from a SASE agent, or a policy enforcement action from a CASB, generates an event log. When this is ingested into a Security Information and Event Management (SIEM) platform, such as Google SecOps or Microsoft Sentinel, it provides data for both real-time alerts and investigating historic events.
This transforms the nature of threat detection. Instead of seeing a low-confidence “login failed” alert, an analyst sees a correlated, high-confidence event: “a login failure from an unrecognised location on a non-compliant device attempting to access a critical finance application”.
This level of detail allows security operations teams to reduce alert fatigue and create highly specific detections, building detection rules to identify attacks such as MFA-fatigue attempts, impossible travel scenarios, or session hijacking that would otherwise be lost in the noise of traditional log sources. Security Orchestration, Automation, and Response (SOAR) platforms take this a step further, using these alerts from the SIEM to trigger automated playbooks that execute crucial response actions without human intervention.
So what should you be implementing?
While it’s undoubtedly a good thing that we’ve seen so many improvements across the authentication landscape, it makes it difficult to stay on top of best practices.
Firstly, it’s important to discontinue the use of SMS or call based authentication. Most of us have experience struggling through MFA implementations and difficult users, and we understand why these factors were implemented (often as backups), but many organisations still have them in place and they present a real threat to authentication processes. Please discontinue the use of these as backup factors.
When it comes to using an authenticator app, anything is a large improvement over telephony, but FIDO2 based authentication is much stronger than push based OTPs. For a while MFA notification fatigue seemed hypothetical, but at this point we’ve seen many real examples of users accepting requests to stop the notification spam. It only takes a user clicking “Approve” once to give access to that account, and threat actors are experts at rapidly turning a low degree of access into something more privileged or more persistent.
FIDO2 changes the authentication process to remove the threat of MFA fatigue. Instead of the service sending a simple, context-free “Approve/Deny” notification to the user, FIDO2 requires a direct, secure interaction between the device being logged into and the authenticator (such as your phone). This is typically handled by scanning a QR code or using Bluetooth, which creates a cryptographic link unique to that specific login session. The user must then perform user verification on their authenticator, typically with a biometric scan or PIN. This means an attacker cannot remotely trigger a flood of notifications for their own fraudulent session; the user can only ever approve the legitimate login attempt happening on the device right in front of them.
Our recommendation then becomes not if we should use passkeys, but how they should be implemented. This decision pits platform authenticators (like Windows Hello or Face ID) against roaming authenticators (like YubiKeys). For years, the conventional wisdom was that hardware tokens were superior. While they remain the pinnacle of security due to their physical separation, the trade-off in cost, logistics, and user friction is significant.
Bearing these factors in mind, our advice is to adopt a tiered approach. For the majority of your workforce, the security provided by platform authenticators is exceptionally strong and represents a huge security uplift. Their seamless integration removes adoption barriers and costs nothing to deploy. We then recommend reserving roaming hardware authenticators for users with elevated privileges or those at high risk, such as system administrators, executives, or key finance personnel. This strategy allows you to deploy phishing-resistant credentials at scale while applying the highest level of protection where it is most critically needed.
Finally, it’s worth remembering that these powerful passkeys are most effective when part of a federated identity strategy. The SAML and OIDC/OAuth 2.0 protocols are the frameworks that enable this. They take the proof of identity from a FIDO2 login and extend it across all your applications, delivering a seamless SSO experience.
Hopefully this guidance has been useful and untangled some of the complexity of this rapidly shifting authentication ecosystem. Like most problems in security, addressing the risk is rarely as simple as implementing a specific product or technology. Understanding the shift in identity management from individual logins to federated identities and how they interact with authorisation frameworks is essential for securing your modern technology stack. The tools to build a truly secure, identity-centric architecture are here, but their effectiveness depends entirely on proper implementation and ongoing support.
At Reliance Cyber we’ve helped both roll out FIDO2 as well as monitor our customers’ authentication processes for when it goes wrong. If you’ve got any other questions that we’ve not covered here please don’t hesitate to get in touch.
WRITTEN BY
Dr. Oliver Farnan, Head of Research, Reliance Cyber
Dr. Oliver Farnan has expertise in offensive security, advanced threats, and nation-state cyber policy. With a rich background in cybersecurity, Oliver has held diverse roles, including as an officer in the Royal Signals, a postdoctoral research position at Oxford University, and as the Global Head of Information Security for the INGO Oxfam. Holding a PhD in Cybersecurity, Oliver combines academic research with practical security operations, empowering organisations to effectively navigate emerging cyber threats.
About Reliance Cyber
At Reliance Cyber, we go beyond standard cybersecurity services, we become an extension of your team, working as a trusted partner to defend against the most advanced threats, including those at a nation-state level. Our approach is rooted in deep technical expertise, real-world threat intelligence, and a commitment to proactive security. By understanding the nuances of each organisation’s risk landscape, we craft tailored solutions that don’t just mitigate threats but actively enhance resilience. With Reliance Cyber safeguarding your digital environment, you can focus on driving your business forward with confidence.
For media inquiries or to request an interview, please contact:
Giulia Foss: giulia.foss@reliancecyber.com