Microsoft Authenticator passkey support to be native in January – Source: www.csoonline.com

Microsoft has positioned itself as a strong convert to passkeys, with a promise to deliver passkey support in its Microsoft Authenticator app in mid-January 2025.

Even though all enterprises will have access, not all are prepared to embrace passkeys, at least not by January. For CISOs whose organizations are not quite ready, Microsoft is giving them a lot of homework to do to stop Authenticator from enabling passkeys in their environment.

“Starting mid-January 2025, organizations with enabled passkey (FIDO2) policy and no key restrictions will have passkeys in the Microsoft Authenticator app,” according to a copy of the Microsoft posting. “If an organization prefers not to enable this change for their users, they can work around it by enabling key restrictions in the passkey (FIDO2) policy.”

But a Microsoft security official, Microsoft cybersecurity consultant Lukas Beran, posted a clarifying note on LinkedIn, a post that seemed to cause more confusion than clarification.

“With the general availability of passkeys in Microsoft Authenticator, the need to have key restrictions set to use passkeys in Microsoft Authenticator will disappear. So, by mid-January, passkeys will become a fully functional phishing-resistant authentication option equivalent to physical keys. Attestation is already supported now, and in mid-January, the preview phase will disappear and support without key restrictions will come,” Beran said. “Conversely, if you don’t want to support passkeys in Microsoft Authenticator for some reason, you’ll need to implement key restrictions and start actively blocking iOS and Android apps. If you plan to allow users to sign in with passkeys in Microsoft Authenticator, you don’t need to do anything and it will be fully functional by mid-January.”

CSO reached out to Beran to clarify his comments, but he did not respond. CSO also reached out to Microsoft to clarify both the statement and Beran’s post, and Microsoft’s PR agency responded, but ultimately declined to offer either a spokesperson to interview or a statement. 

Analysts and authentication experts were baffled by Beran’s comment about “actively blocking iOS and Android apps,” and wondered why there were no details about why such a disruptive action would be needed. Microsoft also declined to detail what “key restrictions” would need to be changed.

Dave Taku, the head of product management and user experience at RSA, said the statements do suggest that CISOs who are not ready to support passkeys by mid-January will have a good deal to work to do to change settings and avoid an issue.

Microsoft forcing customers do a lot of work if they don’t want to go in its preferred direction “does seem to be the implication. There is a history of that” with Microsoft, Taku said. “Nothing is necessarily easy in the Microsoft environment.”

Another longtime security executive, Gary Longsine, the fractional CTO at IllumineX, read both statements and said they lacked sufficient context to tell CISOs what they need to know about this change to support passkeys.

“It is a highly technical (note) using very obscure jargon” and “the post is vague and unhelpful,” Longsine said. “What this note seems to say is that there is this obscure technical element inside of the passkey architecture and you can change certain settings. It is not well written, and therefore I cannot tell you what it means. I am pretty sure it was directed at developers.”

As for Beran’s comments about app blocking, Longsine said that he believes the point was more about Active Directory settings.

“They will have to go into the Active Directory server and turn off the ability within the Microsoft Authenticator app. It’s not really about blocking all apps. It seems to be about blocking particular Authenticator mechanisms for those apps,” Longsine said, before adding an exasperated comment that CISOs might want to consider surrendering and simply accelerate their passkey plans. “It’s probably easier to start migrating to passkeys than figuring out the exception procedures.”

From an authentication perspective, it is all but universally agreed that passkeys deliver far more robust security than passwords and passphrases. What is more complicated is the way most enterprises plan on deploying passkeys.

To get end users, whether they are employees, contractors, customers, or overseas partners for supply chain, manufacturing, or shipping, comfortable with passkeys, just about all enterprises will retain existing passwords as a fallback for when the passkey fails. Analysts estimate that password retention may last anywhere from one to four years, depending on the enterprise’s vertical, geographies, and other compliance considerations.

That presents a bit of a risk reduction perception disconnect. Longsine argued that most CISOs, and even more likely, their CIO/CFO/CEO bosses, will expect immediate risk reduction when they make the passkey switch. In reality, Longsine said, they will see zero risk reduction until they eventually delete their passwords. As long as attackers can still use stolen credentials to gain access, the threat is as big as ever.

“You first have to migrate your whole user community” to passkeys, he said. “Only when you delete the passwords, that is when you get the security benefit.”

Longsine said that most enterprises are going to keep passwords as a backup for far too long, thereby expanding their risk instead of reducing it.

“Most enterprises are going to err on the side of accepting far too much risk,” Longsine said. “That means that it will take much longer than it should, and much longer than they need to.”

RSA’s Taku agreed, but he sees a difference between Active Directory passwords and SaaS app passwords in a passkey context.

“The Active Directory passwords, those are going to exist in the enterprise for, well, one to four years is a good estimation of that timeframe,” Taku said. “But with SaaS apps, that is where passwords cease to exist more quickly, from immediately to 12 months out. The Active Directory password is going to be the trickiest bit.”

Another point that many observers made about the Microsoft passkey move is the surprising abundance of industry cooperation. Consider last month’s announcement from the FIDO Alliance about passkeys, where the group detailed a new industry specification for passkeys that was adopted by many vendors, including Microsoft, Apple, Google and Samsung.

Longsine said that this bucks decades of history between Microsoft and some of these companies, where the firms rarely would agree to standards until the very last moment.

“No one has seen the level of cooperation between Apple, Google and Microsoft in regards to rolling out passkeys” in about 30 years, Longsine said. “These companies have always fought over the adoption of almost any standards. And because they are cooperating on passkeys, they are doing a lot of good thinking about how to migrate users to passkeys. How do you migrate the user community from one protocol to another?”

Taku again agreed. “I think (Microsoft) is playing nicer, but they were forced to by the industry,” Taku said. 

Another comment in the Beran post that caught the attention of some was when he wrote: “by mid-January, passkeys will become a fully functional phishing-resistant authentication option equivalent to physical keys.”

“They are making a bit of leap there, saying it is just as secure,” Taku said. “It is not as secure as a dedicated hardware security device.”

One interpretation of Beran’s comment is that he didn’t want to suggest that the two approaches implemented in a pure form were equivalent, but that he was comparing the two as they are typically implemented in enterprise environments, which includes fallback to much less robust authentication, such as passwords or even unencrypted SMS. 

Will Townsend, a VP and principal analyst for Moor Insights & Strategy, said that the two might indeed be comparable if both have weaker fallbacks.

“It’s like having a backdoor. Having those passwords resident creates an opening for a bad actor,” Townsend said. “I think Microsoft could do a much better job with the fallback. They could make a very strong recommendation for using stronger MFA [methods]. Eliminating unencrypted SMS would be a great start for sure.”