Passkey use cases

The first application is a standard streaming service. You come to this application in order to view your favorite movie, TV series, or other forms of content. Generally speaking, there’s not huge repercussions if a streaming account is compromised: changes could be made to an account name, additional users could be authorized, or your recommendation algorithm could be thrown off. With these minimal risks, accounts for streaming services should be allowed to rely on low assurance authenticators.

Another factor to consider is the concept of account sharing, where multiple members of a household want access to stream from their personal devices. In the current paradigm, a password would be shared between household members, which could be stolen, leading to unwanted access to an account. Some passkey providers will allow MDC’s to be shared and managed to specified members of a users contact list, mitigating the risk of unwanted access through compromised or phished passwords.

Beyond connecting with people you know, social media sites allow users to follow and receive content from high profile accounts. Some examples of these high profile accounts are celebrities, journalists, and politicians. The integrity of these high profile accounts should be maintained, as they often have large follower numbers, who may place a lot of weight on the words and content coming from these accounts.

A recent example of this is the 2020 Twitter hack, where an attacker was able to share Bitcoin scams through accounts from politicians, CEOs, and celebrities.

If an account falls within the realm of high profile, then these users should consider the use of high assurance devices. High assurance devices will ensure the utmost security, to prevent an account takeover that leads to malicious content being shared to the profile’s followers.

This doesn’t necessarily mean that every social media account should be forced to leverage high assurance devices; instead the guidance is to be interpreted as allowing for certain accounts to specify their desire to only utilize high assurance authenticators for access to their accounts. Normal users of a social media site should be free to continue to utilize low assurance authenticators for use in their accounts.

This application allows customers of a financial service to view their account and execute financial transactions. This application can still be considered high risk due to the possibility of financial loss to a user who has their account compromised.

If an account in this application was compromised then it’s possible that:

Due to the risk, it makes sense to mark this application as high assurance, but there is another consideration. The financial service company doesn’t want to require that all of their users purchase specialty hardware in order to use their accounts nor do they want to provide users with such hardware from a cost perspective. The financial services company wants to ensure that the use of their application is seamless and available to all of their customers.

You may want to consider allowing for the use of low assurance authenticators but prompt the user for additional authentication factors such as a password, or a custom authenticator app to execute transactions over a certain threshold. It’s important to note that the password is not the leading factor, and a leaked password will not lead to a compromised account. An attacker will still need control and possession of an authenticator to gain access to an account.

Now that we have a firm understanding of consumer passkey use cases, let’s explore enterprise scenarios.

The first application that we are going to explore is the tool that allows financial advisors to view accounts, and execute transactions on behalf of their clients. This application is only usable by certain internal employees at a financial services company, and is not publicly facing.

If an account to this application was compromised then it’s possible that:

Because this application is highly sensitive, we’ll note that the application requires high assurance authenticators. The intent is that financial advisors are only able to login to this application using SDCs, in the form of security keys that their employer will distribute.

The next application is one that allows employees to view their benefits from personal devices. It’s useful in situations where an employee is curious about company holidays, their number of vacation days remaining, or information related to their health insurance. The application doesn’t allow for the employee to make any changes, and contains no sensitive health related information.

There is not much inherent risk if one of these accounts were compromised. No confidential company data, or personal information is disclosed in this application.

Because the potential risk associated with this application is low, it may be fine to consider the use of low assurance authenticators. This means that the enterprise may not need to distribute security keys to all of their employees, and will allow them to use the authenticator in their personal devices.

The last use case revolves around securing an enterprise’s software supply chain. An enterprise may be producing software where not all of the code is being produced in-house. In these instances the enterprise might contract out to a development shop to create custom code. In order to integrate this code into the enterprise’s final product, the contracting service will require some level of privilege to push code changes into an internal repository, or into a deployment slot on some enterprise controlled infrastructure.

An attacker could target the code, or the deployment pipeline in order to compromise the product. To ensure that nothing malicious is added into the enterprise environment, a company may require the use of high assurance authenticators that are provided to the contracted services company, which will be required to access the enterprise environment. This will ensure a greater degree of assurance that any request or change is coming from a valid user.