Deploy passkeys at work

♪ ♪ Alex: Hi. My name is Alex Sokolov. I am an Engineering Manager in the Enterprise Services team. Today I would like to talk about deploying passkeys at work. I will recap what passkeys are, why they are especially important at work, and then I will talk about the new tools that you can now use to address your unique requirements in managed environments.

Passkeys are a replacement for passwords. They are faster and easier to sign in. Just use Touch ID or Face ID to authenticate and you're done. They are much more secure because they’re guaranteed to be strong and unique for each app or website and are extremely resistant to phishing attacks. And when you use the built-in password manager in iOS, iPadOS, and macOS to store your passkeys, passkeys are securely synced across Apple devices using iCloud Keychain, so they are instantly available across your devices. “passkey” is lowercase because it’s a common noun just like the word “password,” and it’s an industry standard term used by the FIDO alliance, Google, Microsoft, and others. If you need a quick recap on how passkeys work, watch our “Meet Passkeys” session from WWDC22 and come back. When passkeys were introduced, you learned in detail about all the ways passkeys are better than passwords, so today let’s talk about how passkeys uniquely protect your employee accounts at work by defending against common attacks by hackers.

Three of the biggest things enterprises have to worry about today are phishing attacks, credential theft attacks, and two-factor authentication bypass attacks. Let’s explore each of these. Phishing attacks on employees are one of the top attacks that enterprises have to defend against day in and day out. And it’s often the initial foothold for attackers in major breaches.

According to the 2022 Verizon Data Breach Investigation Report that looked at over one billion phishing attempts, 2.9% of employees actually click on phishing links, a finding that has been relatively steady over time. And at this rate, it is more than enough for criminals to continue doing it. This problem obviously gets worse as your company size increases. Only three people in a company of 100 would click on a phishing link. But this number is 15 in a company of 500 and 29 in a company of 1,000. You might think those numbers are not that bad, but remember, a successful phishing attack on just one or two accounts is often the initial entry point for a full breach. Anytime a user is typing something, they can be tricked into typing it into the wrong place. With passkeys, there is nothing to type, and each passkey is intrinsically linked to the website or app it’s used for. These users can never be tricked into using their passkey on the wrong website. With passkeys, credential phishing is gone. It seems like every week there is a new article about a server breach where attackers were able to steal user passwords from a server. 40% of breaches in 2022 involved the use of stolen credentials, according to the same report that analyzed almost 4,000 breaches. With passwords, there is a hash stored on a server, and hashes can be stolen and potentially cracked, revealing the plaintext passwords to the attacker. They can then use the password from breach A to attempt to log into services B and C and so on. This makes server breaches and credential attacks a virtuous cycle for attackers. Passkeys break this cycle because the only thing stored on the server is a public key. With passkeys, there is nothing worth stealing from the server. And you might think the answer is to layer on additional factors, but two-factor authentication doesn’t protect you in the way that many people think. Attackers are increasingly tricking users to bypass the three most popular forms of two-factor authentication, also known as 2FA. SMS codes can easily be phished, just like passwords. Time-based, onetime passwords can also be phished in the same way. And while push notifications cannot be phished, they are susceptible to push fatigue attacks. A recent attack exploited that exact 2FA vulnerability. The hacker kept sending continuous push notifications to an employee and eventually tricked them into accepting one. Additional factors were layered on top of the password because it was fundamentally broken in multiple ways. Passkeys are not just another Band-aid. They replace the broken primary factor with a new primary factor that is secure by design. With passkeys, the primary factor is no longer broken. Layering on a vulnerable second factor such as SMS, TOTP, or push notification adds no extra security to an account already protected by a passkey. If you’re excited about the security benefits of passkeys, but worried all this great security comes at a cost, you’re not alone. You are used to having to make tradeoffs between security and usability. Let’s look at a side-by-side comparison of the experience of creating a new password versus creating a new passkey. As you can see, creating a passkey is significantly faster and easier than creating a password. Just Face ID and you’re done. Now that we’ve looked at creation, let’s compare the experience of signing back in. With a password, the user has to remember and type in the password. With a passkey, they just Face ID and they’re done. A password manager can help improve the experience, but even the best password manager can’t compete with the user experience of passkeys. You are used to having to make tradeoffs between better security and a better user experience. Passkeys achieve something rare: great security and a great user experience. Since this is a lot to digest, let me recap the unique benefits of passkeys for businesses. No phishing. Passwords and popular forms of 2FA you use to protect your employees today are often phishable. Passkeys are phishing resistant. No credential theft from servers. Password hashes can be stolen from servers in a breach. With passkeys, there is nothing worth stealing from the server because it only stores a public key. And great user experience. With passwords, employees have to deal with annoying password complexity and password rotation requirements. With passkeys, they just use Face ID or Touch ID and they’re done. Passkeys are a win-win– a more secure credentials to protect accounts at work paired with a user experience your employees will love. While IT administrators at organizations want to deliver the same great experience with passkeys at work, you have unique requirements in managed environments. Let’s talk about these requirements and how you can address them. First, you want to manage the Apple ID accounts that use iCloud Keychain and passkeys. Then, you also want to sync passkeys only to devices you manage, not personal devices of your employees. Of course, you want to ensure passkeys created for work get stored in the iCloud Keychain associated with the Managed Apple ID that IT manages, not the user’s personal Apple ID. This also lets you ensure passkeys are stored in iCloud Keychain, as opposed to somewhere else. Next, you want to prove to relying parties that passkey creation occurs on managed devices. And last, you want to turn off sharing of passkeys, because you don’t want employees sharing work credentials with each other. I’m excited to talk about the new tools you can use to address these requirements. I will talk about three topics: using Managed Apple IDs, controlling where passkeys sync, and requiring work passkey creation on managed devices. Managed Apple IDs are owned and managed by your organization. They are created in Apple Business Manager or Apple School Manager. I’m excited to say that Managed Apple IDs support iCloud Keychain in macOS Sonoma, iOS 17, and iPad OS 17. With Managed Apple IDs, your users get all the benefits of using passkeys on all their devices with iCloud Keychain, and you get to manage their accounts. Passkeys stored in iCloud Keychain of Managed Apple IDs cannot be shared. To learn about other great improvements to Managed Apple IDs, watch “Do More with Managed Apple IDs” session. In addition to managing Apple IDs, IT administrators also want to control which devices the passkeys are synced to, and only allow it on devices they manage. Apple Business Manager and Apple School Manager have new access management functionality. There are two different controls administrators can use. The first one allows IT administrators to control which devices employees can sign into with their Managed Apple IDs– on any device, which is the default option, on managed devices only, which provides higher security and works for cases where users bring their own devices to work, or on managed supervised devices only, which is the highest level of security for organizations that provide devices to their employees. IT administrators can also further control which devices to allow iCloud content, including passkeys in iCloud Keychain, to sync on with the same three convenient options: on any device, managed devices only, or managed supervised devices only. With these controls, IT administrators can ensure that passkeys used for work only sync to managed devices. Device management servers will need to implement support for this functionality, and of course it works out of the box with Apple Business Essentials. Now let’s talk about how IT administrators can manage passkeys on the devices at work to make sure certain passkeys stay on work devices only. You want to require passkey creation for work on managed devices. Specifically, you want to ensure that the passkeys are stored in iCloud Keychain of Managed Apple IDs, providing syncing of passkeys across all their devices, and prove to relying parties that passkeys are created on managed devices. You can do this with the help of declarative device management. You can learn all about improvements in declarative management in our “Explore Advances in Declarative Device Management” session. But for now let’s focus on a specific new configuration to manage passkeys. Declarative device management has a new enterprise passkey attestation configuration that can be used to securely generate a passkey for a user on a device when they visit the site specified in the configuration. The configuration references an identity asset. The associated identity is then used to perform a standard Web Authentication attestation of a generated passkey. The Web Authentication relying party can then verify this attestation and allow access to the relevant sites. In the next few slides, I will walk you through this process. What this means is that you can restrict certain passkey creation to only occur on managed devices. And paired with syncing controls that I just spoke about before, you can also control what devices these passkeys sync to. This feature is available on iOS, iPadOS, and macOS. This is an example passkey attestation configuration. It has a reference to an identity asset that is provided by the server in the set of declarations sent to the device. When the configuration is activated, the asset will be resolved, and the resulting identity will be stored in the keychain. The "RelyingParties” attribute indicates where this identity will be used for Web Authentication passkey attestation. Let’s look how an organization would configure a device. First the MDM server sends the passkey attestation configuration and identity asset to the device and ensures it activates. Upon activation, the identity certificate is provisioned from the corporate certificate authority server. At some later point, the user visits a website. The website requests a passkey for access. Relying parties can indicate that they would only accept new passkeys created with enterprise attestation and reject all other passkeys. The device generates a new passkey, attests to it using the provisioned identity certificate, and returns it to the website. The website can then verify the attestation by checking that the device certificate inside the Web Authentication enterprise attestation payload chains back to the certificate authority of the organization. This attests to the relying party that the passkey is created on a device managed by this organization. In order for this to be possible, the relying party must know which CA certificate to trust for the organization. This could be achieved a variety of ways, including by the org admin uploading a copy of the CA certificate to the relying party. The relying party only validates the attestation at the time of passkey creation. From that point on, the passkey can be used with that relying party without the need for further attestation. Passkeys created in this manner will be stored in the iCloud Keychain of the Managed Apple ID. This is not hardware attestation. If that’s what you’re looking for, you can learn about Managed Device Attestation in the “What’s New in Managing Apple Devices” session. Relying parties will need to look at the attestation statement inside Web Authentication passkey creation response. First check if AAGUID matches the value on the screen to see if it came from an Apple device. Then look at the packed attestation statement that consists of three items. There is a number identifying a cryptographic algorithm. This should always be set to -7 for ES256 on Apple platforms. Then there is a byte string containing the attestation signature. And last, there is an array with the attestation certificate and its certificate chain, if any, each encoded in X.509 format. You can learn more about attestation statements in the official Web Authentication documentation by searching for "Web Authentication Packed Attestation Statement.” With this new declarative device management passkey attestation, IT administrators can create specific attested passkeys for work that relying parties can recognize and trust. And this will also ensure that these passkeys get stored in the iCloud Keychain associated with the Managed Apple ID, not the user’s personal Apple ID. With Managed Apple IDs supporting iCloud Keychain, Access Management functionality in Apple Business Manager and Apple School Manager, and managing passkeys with declarative device management configuration, you can address all your requirements for passkeys at work. Now let’s take a look at passkeys in action. An IT administrator in my organization invited me to manage our network on Tailscale together. Let’s see how easy it is to use a passkey to sign up. First I choose a name for the passkey. Then I tap “Create a passkey and join.” My passkey will be saved in the iCloud Keychain of my Managed Apple ID so I can use it on other devices. And finally, I simply tap “Continue” and use Face ID to sign in. This is it; I can now manage my organization’s network. By the way, my organization also requires to create the passkey on a managed device, so if I accidentally tried to create it on my personal phone, I would see an error saying that my device is not managed by my organization. This is of course achieved using passkey attestation. Now back to my work phone, signing back in is even simpler. I tap “Sign in with passkey” button, and as you can see, my phone remembers the passkey that I used on this website before. So I simply hit “Continue” and use Face ID to sign in.

To wrap it up, let’s review the new features you can use to deploy passkeys at work. You can use passkeys with Managed Apple IDs while managing what devices they sync to and controlling passkey creation with Web Authentication enterprise attestation. With passkeys, you can protect your company from phishing and credential theft attacks while providing your employees with a user experience they’ll love. All of these improvements were informed by your incredibly valuable feedback, and we're looking forward to hearing what you think. Thank you. ♪ ♪