Transcription

HB

Hello, everyone, I'm Husnain Bajwa, or HB, and I'm here with George Jenkins. Welcome to our webinar today, and we'll get started in a few minutes. We're just going to let a few more people trickle in. 

Looking forward to your talk today, George. It should be an easy one. 

George

Yeah, thanks. Excited to be here. 

HB

Excited to hear about the dozens of New Zealanders that you've also met in your... 

George

So, in writing this presentation, I found there was a Wikipedia article for famous New Zealand Americans, and there is dozens. 

I don't know any of them. So it goes to show, you know, I have a bit of learning myself to do. 

HB

Well, I'm glad that it could take you to the Wikipedia article for New Zealand Americans, notable New Zealand Americans. I look forward to those questions showing up in the Jeopardy! answers database soon. 

George

Oh, ouch. Yeah. If we get any Q&A about famous New Zealand Americans, I'm sorry, you're on your own, HB. 

HB

Sounds good. Well, I think we can probably go ahead and start. Again, everyone, thank you for joining. My name's Husnain Bajwa, but I go by HB. I run product strategy at Beyond Identity. And I'm joined today by George Jenkins, our illustrious product security architect and man of many hats, extremely talented technical expert. 

And so really looking forward to his insights today as we talk about degrees of phishing resistance and how to think about modern phishing resistance in the context of technologies available today and where best to defend from adversaries. 

But yeah, George, why don't you kick it off? 

George

Yeah, hi. So, today, the topic is a competitive analysis between Duo and Beyond Identity. Like HB mentioned, my name is George Jenkins. I act in multiple, numerous roles here at Beyond Identity, all within the security function primarily. I work in product security, where I focus on the security of our product. 

I do research into protocols and mechanisms that we use to protect our customers, and overall, I help us build a better authentication solution. Full disclosure, I am an employee of Beyond Identity, so this is going to be an opinionated webinar. Our job here is to critically examine Duo, determine high-level capabilities and competencies, and contrast them with Beyond Identity. 

There's a reason why companies such as Snowflake, WWT, and Cornell University select us as their authentication provider. So let's start today by understanding where Duo came from in order to better understand Duo as a company today. Duo was founded about 13 years ago, primarily at a time where MFA was typically recognized to be sufficient based on the inclusion of the second factor alone. 

Their popularity skyrocketed out of the RSA seed debacle, where the seed used to create RSA secure ID tokens was leaked. So companies that had deployed these physical security tokens had to react quickly to prevent compromise. As MFA has evolved over the last decade, so have threat actors. 

Legacy MFA is attacked all the time and often is bypassed due to weak protocols and human factors. I believe we're reaching an inflection point where legacy MFA is being recognized as a second secure ID, especially in the age where MFA is being so relentlessly attacked. 

And this leaves Duo in an awkward position. Evolve and compete in the modern authentication market, or die a legacy phishable MFA company. So if you haven't heard the term legacy MFA methods before, they're typically all classified as having one major flaw. 

They're vulnerable to phishing attacks. Depending on the kind of implementation, exploitation does differ, but the same logical issues exist over the entire range of MFA types. The Duo Mobile Authenticator falls squarely within the legacy MFA classification. Doesn't matter if you're using one-time passcodes within the app, text messages, phone calls, push notifications, none of it is phishing resistant. 

It also doesn't matter if you're using the Duo Universal Prompt or the traditional Duo Prompt. Both can be easily attacked with off-the-shelf components. The need for phish-resistant MFA is also very well established at this point, with various government agencies asserting that phish-resistance MFA is strongly recommended. And in some cases, it's becoming required. 

So I have a quick demo to show you the genesis of a phishing attack. This one here is against Duo Verified Push. The attacker generally distributes a phish URL to the victim. The victim will send their credentials through the proxy that the attacker has provided. The proxy sends those credentials back to Duo and scoops them up so they can send them to the attacker. 

The push notification happens outside of this protocol, so it is not secure to phishing resistance. This is completely phishing resistance, and this is typically how any of those legacy MFA providers operate. Doesn't matter if it's OTP, doesn't matter if it's email OTP, doesn't matter if it's on a authenticator app, they all still use the same genesis. 

So to really drive home the point, here's an example of our research lab conducting an attack. This specific attack is a browser-based attack. It's called an adversary in the middle, where the password to the one-password account is supposed to be protected by Duo push notifications. 

The victim is on the left-hand side, and you can see that they're actually connected to an EC2 instance in AWS. It's running an RDP server as the attacker on the right. This example shows not only that we can capture the sensitive account recovery codes for one password, but we can also completely bypass Duo push notifications. At the end of the demo, you'll also see that the right-hand side, the attacker's view, maintains the active session into the victim's account. 

And we also display configuration for Duo itself, showing that it's using the Universal Prompt. There's an interesting bit of history regarding failure of Duo to support host name verification in the past. It's a critical control for FIDO, but it's out of scope for this demo right here. Okay, moving on. 

Let's take a look at more modern implementations that Duo support today. It's no surprise that we at Beyond Identity have a refined and opinionated view on what a passwordless system should be. 

Unfortunately, Duo doesn't have the same high standards for passwordless authentication. Duo's passwordless MFA offerings includes three primary mechanisms, of which only one really truly provides phishing resistance. They're all limited, and they are provided in a fractured ecosystem of tools, which also provides significant problems when you're trying to deploy a true Zero Trust Authentication strategy. 

As you might have gleaned from the previous slide, there are good and bad passwordless solutions. Bad passwordless solutions remove the phishable password but don't substantially change the threat surface for any significant fashion. An example of this is the well-known magic link delivered over email. Only solutions that provide strong cryptographic assurances, non-verifiable...non-disclosable factors, pardon me, and verifier impersonation resistance should be considered safe and effective within an enterprise deployment scenario. 

In any of the legacy MFA scenarios, the human plays a critical part. Genuine phishing resistant MFA takes the human out of the loop. I'll take you through this, but you need to ask MFA vendors hard questions about how they do this in a cryptographically provable way. We're going to look at it from a Beyond Identity perspective, since this is a competitive webinar after all. 

Beyond Identity uses the platform authenticator on the user's endpoint to ensure phish resistance. When an authentication attempt is started, the platform authenticator verifies both the target service domain and its TLS certificates are valid. The PA then verifies that the auth challenge is signed by the owner of the private key associated with the Beyond Identity auth service. 

If an adversary tries to put a proxy in between the Beyond Identity cloud and the platform authenticator, like we saw in the previous demo, the transaction will simply fail. Then the platform authenticator asks the user to validate that they have possession of the end user device by using the built-in device pin or biometric, both interact with the TPM hardware on the endpoint. The PA then signs an X.509 certificate with the private key that was stored in the TPM when the user and the device were officially registered. 

This completes the passwordless phish-resistant attacker-in-the-middle proof-of-authentication process. No humans were involved in anything except proving possession with their biometric or PIN. When the computers do the tricky stuff, we can take a probabilistic problem, credential phishing and MFA bypass attacks, and create a deterministic solution that stops a whole class of attacks. 

Now that we understand what is required to do passwordless well, we can take an opinionated look at Duo's passwordless solutions. As I mentioned earlier, Duo provide three primary passwordless types. Platform authenticators that use FIDO. Sorry, pardon me. 

Platform authenticators using FIDO2 are authenticators that are built into your end-user devices. If you've ever logged into a website and you've used Windows Hello, or Apple's touch ID, or Apple's face ID, you've most likely used a platform authenticator. In most cases, the cryptographic information used is stored using hardware protection, that is the key is stored using a TPM or a secure enclave. 

In Duo's implementation, there are a number of problems that prevent successful rollouts in an enterprise. Compatibility issues with Firefox mean that the platform authenticator is not even supported. Apple devices, users that use Apple devices, macOS, iOS, are forced to enable iCloud sync, meaning that keys that they create are synced between devices. 

This is great in a consumer scenario, where user experience is paramount, but it's a nightmare for enterprise. Passkeys, the term that we use for the cryptographic information that underpins a passwordless solution should ideally be bound strongly to the device. If they're able to move between devices, that means they're able to be disclosed. 

That means a breach of an iCloud account is all that is necessary to steal the keys associated with the user account. The second FIDO implementation, roaming authenticators, are typically physical security keys that need to be plugged into your computer to work. YubiKey is a very large vendor in the space that most people have heard of. 

They are extremely secure, but your users have to keep track of a physical key. That means you have to supply and maintain an inventory of physical hardware keys for your users. If you have a distributed workforce, this will become a problem. These physical keys can also be stolen. The final mechanism that Duo provide is something they call Duo Verified Push. Duo verified push is simply Duo Push with a code. 

There's really no significant security benefit in the solution, and it's delusional to think that adding a code to an already insecure launch mechanism changes the security posture of that mechanism in any tangible form. Even CISA have released guidance recommending against any kind of push MFA that uses number matching. Although at the time they were talking specifically about Microsoft's implementation, the same applies here. 

So to summarize, out of the three passwordless solutions that Duo have provided, only two of them really provide any kind of tangible security benefit for your organization. Enrolling a FIDO authenticator also presents what I like to call the enrollment problem. The end user must authenticate using a weak credential in order to enroll a more secure one. 

That means there's still a weak point in your authentication process that can be exploited and needs to be protected. Duo's ecosystem also presents very limited device posture checks, which we'll touch on in a second. Lastly, the threat of movable passkeys cannot be understated. If you're protecting corporate resources, passkeys that are able to move from device to device form a new threat and expand the scope of accounts that you need to protect in order to keep passkeys safe. 

Now, we take a far more refined approach toward security of passkeys within our platform. Beyond Identity is FIDO certified, and we use phish-resistant mechanisms to provide secure authentication. But we don't suffer from the same fundamental drawbacks that Duo do since we're a platform authenticator ourselves. 

The Beyond Identity Platform Authenticator talks directly to the TPM or the security enclave to create and store keys that cannot be disclosed or moved. They're fundamentally bound to the device they're provisioned for, making passkey inventories super simple and easy. Our device posture analysis leads the industry in flexibility and capability, allowing admins to create access policies that provide visibility all the way into the process table and file contents on the machine. 

So onto device posture checks. Duo had a certificate-based solution they called Duo Trusted Endpoints, but they recently deprecated it and replaced it with Duo Device Health. So that's what I'm going to be talking about today. Duo Device Health provides a range of capabilities for the administrator to block devices based on their configuration and posture. 

But unfortunately, and this is a problem we see in many other vendors in the security access industry, device posture is considered to be a series of extremely basic and limited checks. Almost every zero trust auth vendor in the industry can do checks like firewall on, or disk encryption on, or password set. 

Every passwordless vendor in the industry does these checks at authentication time. These are table stakes. They're nothing special. There are so many more settings that you can use to determine the risk profile of the device and to limit policy to only these parameters, show short-sightedness and a strategy failure, a failure to understand and adopt the shifting nature of device-centric security. 

Wow, I've written a lot of alliteration in this. I don't know. 

HB

It's beautiful. It's a beautiful prose. Don't worry about it, George. 

George

The mispronunciations are part of it, right? However, unfortunately for Duo, this requires the deployment of a second piece of software. This means you either have to deploy the software as an administrator to your fleets or you enforce that your employees install it themselves. Being a separate application, it is not uniquely tied to an authentication attempt in any significant way. 

This means if I'm a motivated user, I can bypass the checks. Duo Device Health is a completely separate application, like I mentioned. And this leads to several significant logical issues in this system. The information that the Duo Device Health responds to Duo has no guarantees of legitimacy or veracity. 

This means that a malicious user or third party can run a script on their own computer and spoof conditions required for access. In fact, there's an open-source project on GitHub that does just that. I've dropped the link to it right at the bottom on the left-hand side. Without any kind of continuous check, device health posture is only collected at authentication time. 

This means that a user can disable their firewall or modify other required configurations immediately after authentication, falling out of compliance near immediately, and it won't be detected. They also won't have their session terminated. Duo says that they're releasing a fix for this sometime in the future, but the marketing material they released was released in 2022, and they have no timelines for fix. 

Whereas Duo is still struggling to keep up on this point, Beyond Identity leads the industry in deep device posture checks. But we, even more importantly, do these checks continuously. That protects your organization from devices that fall out of compliance after authentication. If a situation arises where a user turns off their firewall, or if malware modifies their registry setting, our continuous monitoring will detect it and can orchestrate an appropriate response per admin-defined policy. 

A response may include terminating a Zscaler session or quarantining the device. All of our solutions are wrapped up in one single application. So you don't need to manage multiple pieces of software to provide a holistic solution. To wrap up, here's a demo of what can be achieved with Beyond Identity today, above and beyond the generic policies that most other vendors, like Duo and Okta, provide. 

That's the end of my presentation, so we'll move into Q&A now. 

HB

Sure. So, George, first things first, when you were on your NIST slide, you know, we were talking about phishing resistance. How old is this phishing resistance kind of initiative? And when you talked about verifier impersonation resistance, like, are these similar things? 

George

Verifier impersonation resistance is a component of phish resistance. We've known about the need for phish resistance as an industry for some time, but where it's really becoming a big hot-button issue is when large companies get breached or MFA is bypassed. 

Right? We had, just in the last couple of months, Caesars and MGM fall victim to MFA bypass attacks. If you're a government agency, you're hearing directly from NIST, from CISA that you need phish-resistant MFA. Even the office of the president is saying that phish-resistant MFA is important. 

HB

Sure. So, what's been driving all of this growth? Like initial access brokers, better tooling, like [inaudible proxies, like what...? 

George

You bet. So we had a question earlier about Evilginx 3. If you're unfamiliar, Evilginx 3 is a proxy. It is available in GitHub. There's actually a Evilginx Mastery course that you can buy for $300. 

The developer will lead you through how to conduct your own phishing attacks. There's a range of phishing templates available freely online. It means that teenagers can do this kind of thing. You don't need any specific technical knowledge to do it. You can do it yourself. 

We've done it ourself. We have a bank of exploits for a large number of competitors, end-user applications. Microsoft is generally the one that we like to talk about, right? Everybody knows Microsoft's got a storied history of being attacked via MFA bypass. Initial access brokers, you mentioned. 

The term means typically a actor that has access into third-party systems and is willing to sell it to you. So I can go on the dock where I find an initial access marketplace and pay them money to get access to their environment. It's a pretty lucrative business. 

HB

But it's surprisingly cheap, right? Because it's a global market. So you can buy these credentials. It's not like you're paying tens of thousands of dollars to get access to this. 

George

Not at all. A couple of months ago, there was a Group-IB report that came out about an initial access broker marketplace. For about $300, you can buy a completely managed phishing-as-a-service platform. The threat actors that provide this also have a open-air marketplace on the dark web where you can buy credentials for breached servers. 

It's a pretty slick place, right? For five dollars, you can get RDP credentials, and they'll test it for you. Imagine a table of descriptions of servers, and you can click a button, and it will tell you if the credentials are still good. And if you like the look of them, you can buy them for five dollars. 

It's commoditized. 

HB

So between these Evilginx-type services and the initial access brokers and professionalized phishing-as-a-service kind of models, I guess it's understandable that legacy MFA has become legacy MFA, right? And one of the questions that came in while you were talking was about Microsoft MFA and whether Microsoft MS Authenticator is also a legacy MFA technology. 

Do you want to just answer that? 

George

Yeah. Regarding the Microsoft Authenticator side, yes, there are deployment scenarios with Microsoft Authenticator that are absolutely legacy. Push notifications, one-time passcodes, number matching schemes. Yeah, Microsoft have done a great job of pushing end users towards a more secure solution. 

They have Windows Hello for Business that acts as a platform authenticator. It is okay, right? Same kind of problems that we see with Duo or we see with Okta with really limited device posture checks still happens with Microsoft, where you get limited five or six configuration attributes that will be evaluated at authentication time, and that's it. 

As an industry, we need to do a lot better, right? And I think we can approach the problem strictly in a lens of zero-trust authentication, where we need to communicate between different services, share signals, orchestrate responses, automate responses, and remove the human element from authentication as much as possible. 

Humans are great, they have a fingerprint, they have a face, but they can't judge phishing emails. If you've done any kind of KnowBe4 phishing tests, you'll know, you never hit zero. We never hit zero. Humans are flawed. 

Humans can be tricked. Now, what was the first part of that question? I think I answered the Microsoft Authenticator portion far more than that. 

HB

It was just, would you consider Microsoft MFA and MS Authenticator also legacy MFA methods? That's all. 

George

Okay, sure. Yeah. 

HB

And, fundamentally, a majority of Microsoft MFA is the Authenticator for cross-platform functionality. Obviously, the Windows Hello for Business for Windows machines as well as targeted usage of FIDO2 security keys, those can act as additional types of MFA, but those are definitely not the central point of Microsoft's MFA portfolio. 

George

Yeah. The disappointing part as a security professional, wearing my security hat rather than my Beyond Identity hat, is that we have OEMs moving in the correct direction. Microsoft, Apple, great. Great security for their platform authenticators, pretty bad in terms of orchestration. Terrible in terms of an environment where you have different OEMs. 

It's similar to how we saw FIDO2 evolve over the last decade. FIDO2 has been a very slow process. OEMs like Firefox have not caught up. So it has a ramification for end users that you'd like to be able to use a consolidated experience, but, really, the only vendor that does a great consolidated experience are Microsoft and Apple, and they do not share. 

I have Microsoft devices, I have Apple devices. There is no consolidated experience between them. 

HB

So when you're talking about these compatibility issues, this is the whole FIDO2 WebAuthn, so you're saying that there's remaining compatibility issues on browsers and WebViews George Yes, WebViews in particular. We are FIDO certified, right? 

We also supply FIDO authenticators. And we observe, in the wild, incompatibility issues with third-party software that uses WebViews. They are insidious in some cases, right? It's very hard to engineer modern authentication protocols into legacy software. So in some cases, it's not something that you can provide FIDO for. 

Either the legacy software has to be updated or you have to fall back to some other mechanism, which is a threat to a consolidated authentication ecosystem. If you fundamentally have to scale back the protection, you're building caves, holes in your security strategy. 

HB

And this is where a determined and use case-focused approach to phishing resistance benefits from having a dedicated download, the platform authenticator, from an enterprise phishing-resistant provider. 

George

Yeah. As part of our strategy, we really elevate the idea of a passkey as a credential object, right? Other vendors fail to see it in the same manner, which is really disappointing from a security perspective. 

These are objects. These are artifacts. And they need to be treated as the key material that they are. A good example is Okta, right? Okta provide a authenticator mechanism but don't show you which passkeys actually exist in your enterprise. 

Duo do a better job, but they lack the fluid interaction between what is happening on the device and what the content of the passkey contains, right? These two things don't exist in isolation. A passkey exists with the security of the device in mind, especially in the situation where you have Microsoft in your ecosystem. 

Other platforms do a better job, right? Apple, Android have key isolation features which provide a higher level of assurance to the key material being stored on the device. Windows essentially does not. So you also have to do your due diligence with the authentication provider, the MFA provider, are they isolating key material on the endpoint correctly to reduce the risk of compromise in any kind of endpoint compromise scenario? 

HB

So that's an interesting point. So you took it to endpoint compromise, and there was a lot of discussion about device posture. And you mentioned that the capabilities of device posture that are built into a lot of the authentication solutions today are not terribly robust. Can you contrast that with what other approaches have existed? 

Like, I've heard that people used VPNs previously and other technologies to get deeper insights into device hygiene and device posture. How do you see that evolving? Like, are you seeing more and more of the fleet insights needing to be brought forward? 

George

Absolutely. Yeah. And I think as an industry, secure access, MFA provider industry, we are moving in that direction. It's disappointing to see that the industry has consolidated around a limited number of checks, right? If you're telling me that my firewall is on, great. 

But what is my firewall doing? If I have rules in my firewall that allow sensitive ports, it's essentially as good as saying that it's off. I don't think it's the right strategy to coalesce around these limited checks. I think we need flexibility, we need extensibility. 

Every environment is different. You need to protect based on what your environment has deployed. So to centralize around the same pedestrian checks really kneecaps the strategy. Other vendors, other solutions, like a VPN, like ZTNA, I think, should be part of the overall security posture of the device. 

If I'm running a VPN, great. That could be bad or good. Let's assume that it's a company-provided Cisco VPN. Great. I probably do want that as part of my security strategy. The device posture mechanism has to be flexible enough to prove that it is running, detect when it's not, and has to be deep enough in the overall ecosystem to motivate change in a automated fashion. 

I don't want to just tell another flawed human that automated protocol has failed. I want to automate that response. 

HB

So going towards that, we had a question from the audience, from Guy. He asks, "As far as monitoring the endpoint posture, are you polling or event-driven?" I think this is implying a little bit of background knowledge, right? Like when you're trying to take in and create a multi-factor authentication solution that essentially has limitless factors that can be your own device posture components or integration components. 

What are the challenges of making it real time, and how is this done to make it most fresh and relevant? 

George

It's a very good question, Guy. Being an MFA provider, we are... Let me rephrase. Being a hardware-backed platform authenticator, we need to be on the device, which is great from a visibility perspective. 

You get unparalleled visibility, which you don't get with things like FIDO2. But you also have to be a good citizen on that device, which means that you have to be efficient, you have to be small, you can't hog memory, you can't hog CPU. You need to be essentially invisible to the user experience. So there are limitations on how much data you want to process, how frequently you want to process data collection. 

Currently, our strategy resolves around polling with differential times between checks. There are mechanisms within our platform that use event-based checks. A good example of that is integrations. To poll a integration, such as CrowdStrike, is inefficient. To be told that CrowdStrike has made a decision or has found something is far more efficient and far more fast. 

Going forward, event-based checks make the most sense for highly efficient real-time detection. So we're pursuing more event-driven mechanisms than polling. 

HB

Cool. So how do you see that sort of unfolding with... Everyone uses the term continuous. What's meaningful in a continuous context? Maybe it makes sense to describe what the world of authentication looks like when it's purely based on session idle timers. 

What are we talking about in terms of improvements? 

George

Yeah, session idle timers is interesting, right? Where we see a lot of questions from customers and prospects is what happens when you've been a part of that authentication process, and you've gone back to the SSO, and the SSO is granted a credential, and then we see the user authenticate to this range of applications, and posture change is what happens, right? 

The correct way to handle a scenario like this is to terminate sessions everywhere they exist. The bane of the C-cert is that that is really hard to do, especially when you're having to rely on something like an SSO. 

SSO providers have this concept of a single logout, but single logouts capabilities are historically very rare to come by. Big SaaS providers may support SLO. There is a terrible user experience associated with it, which is similar to a round robin of your device going to each of these service providers, terminating the session, coming back to the SSO, round-tripping. 

It's quite a mess. And it has never historically worked well. The big problem there is that how we remediate the length of sessions is tied to a session timeout. So if I issue a cookie as a service provider, that cookie is good for eight hours. If I log out or I close the browser, let's say, I don't log out, I close the browser, after five minutes, that cookie is still good for eight hours. 

Having timeouts is deterministic only in the event that the cookie expires, right? So we have accepted, for performance reasons, for historical reasons, that credentials when issued are good for a period of time. 

And there's good reasons around performance why we do that kind of thing. Now, in the context of, say, device posture, when you're having to do things like polling, there is a delta between when an event happens and when you detect it. So the smaller that that polling interval is, the more efficient your detection mechanism will be. 

It's driven as low as possible when you adopt a fully event-driven architecture. If you're listening to file events, you're listening to process events, this is generally what, like, EDRs do and how EDRs stay efficient. You can react just to deltas in the environment without having to incur the time between an event occurring and when you detect it. 

As a industry, we're making pretty limited inroads on applying the same concepts in the web. FIDO hasn't solved it, but there are efforts that make this a lot better. Ones that I am excited about is CAEP and RISC, which is the ability to share signals between service providers. 

I, unfortunately, am realistic. Right? Having seen the historical rollout of single logout with very well-known protocols like SAML and OIDC, I'm not sure we're going to see the same, like, wide penetration that we want. I think it's going to be more of a limited rollout, like SLO has been. 

But maybe that's just the security pessimism in me. 

HB

Cool. And when you're talking about these typical...what is a typical SSO session timer these days? And what is a typical refresh interval for, like, say, an MDM platform in the cloud that's doing, you know, policy verification? 

George

SSO sessions can be as low as a few minutes. Generally, they're not, right? Generally, our users want a flexible SSO session that lasts the entirety of their day. As a Security engineer, as an IT administrator, you want to have limited sessions because, historically, the one control that you do control is that timeout. 

So the smaller it is, the smaller the interval that a device can get breached and things can get stolen, but then you have people opening tickets and saying, "Hey, I've got to log in multiple times a day. It's a pain. I just want to get to work. Why are you making my job harder?" So we have this situation where security is pulling in one direction, user experience is pulling in the other, and user experience typically wins. 

As for MDMs, it can vary. MDMs, mature MDMs, use silent push notifications these days. An example being Jamf. Jamf does have a check-in interval, but based on user interaction in their cloud, it can push notification updates to endpoints near immediately. 

So we've caught up there when the interaction is driven by a human. It's not efficient. It doesn't, like, solve anything doing this in the cloud, outside of human interaction. So in every other circumstance, they are polling. 

Some are better than others. Jamf is great. Anyone that has worked with Intune, I hope you're a patient person because Intune is very well known as having long polling intervals. 

HB

No, that makes sense. So we're gradually moving towards, you know, sub-hour, 15 minutes, sub-15 minutes kind of intervals in this, like, continuous evaluation space, in your opinion. 

George

I don't think that your traditional identity provider or SSO are the right ones to solve this. Right? You need to consider it from a different perspective. When you anchor an identity and trust on that identity on a hardware component, on an endpoint, that's a really good place to start building this kind of strategy from. 

If I can fundamentally trust the endpoints, I have far less concern about the length of a session timer. The part that is difficult to collapse in this problem space is legacy web authentication. If I am tying a user identity to a cookie, I have very limited network signals around what I can determine. 

So when we see things like ZTNA, ZTNA is great. ZTNA gives us far more trust in that session, the user underpinning that session, the device that is receiving that session. We're having to engineer out the problem to solve it, right? 

It is not solved by the traditional web architecture. 

HB

So, if this new kind of phishing-resistant authentication is accessible, it provides all of these additional security benefits, how difficult is it to implement compared to legacy MFA? Is it an equivalent exchange? 

Is it relatively difficult to deploy? 

George

So that's quite a challenge, right? It depends on the provider that you select. In some cases, if you have a perfect environment with 10 Windows computers, Windows Hello will be very easy for you to support. If you're any kind of medium to large business, where you have developers on Macs and HR on Windows, you have different devices, you have different operating systems, maybe you're lacking an MDM, maybe you're lacking great inventory management, it becomes a lot more difficult to proceed with a strategy that supplies more modern passwordless authentication. 

And in those cases, legacy MFA is easier to deploy, but it comes with those drawbacks. You don't get the same level of trust in the endpoint, and it's totally phishable because it is operating in a restricted operating environment. We have taken the tact that to roll out passwordless authentication, it needs to be simple, right? You can use the same software on every endpoint. 

It doesn't matter if it's Linux, Windows, macOS, Android, iOS, it's all the same consolidated experience because that's how you have to treat passkeys in an enterprise. When you're trying to deploy new technology and you're having to rely on OEM solutions, as we mentioned earlier, and there's no interoperability, and they're all handled differently, and you get different security benefits from each one, you're improving your threat surface, but you're also evolving your threat surface. 

You've got other things to worry about now. 

HB

So there you go, folks, the honest Beyond Identity technical answer, that, you know, there is some complexity and consideration involved in selecting phishing resistance. We don't think that it's too much. We think it's hard to imagine a scenario where folks shouldn't deploy this, especially given the amount of high-profile breaches we've been seeing lately. 

But, again, if you're interested in honest, thoughtful answers, we're always available to talk and to talk tech. But yeah. George, any final thoughts before we conclude the webinar? I don't think we have any more questions. 

George

As a security professional, I really want to push people to adopt passkeys. If it's not us, that's still OK. Please adopt passkeys. Don't be scared of them. This is where the industry is heading. This is the future, and we need to really embrace it, speed its adoption, get out of these dire straits of legacy MFA that does nothing for us from a security perspective but drains our security budget. 

So thanks for joining me. Thanks for joining me and HB, and we hope you have a wonderful day. 

HB

Thanks. Really appreciate it, George.