Configuring Account Binding Policies for Self-Service Account Recovery

Account binding

Account binding is the process of connecting a person to an account in a directory such as Microsoft Entra, Okta, Duo, or OneLogin.

Nametag compares accounts in a directory with a person’s information on their government-issued ID, which they present when verifying their identity. This document contains additional details about the identity verification process.

There are three different types of data from government-issued IDs that can be used in order to match a person to their directory account:

1. Name
2. Name and birth date
3. Profile photo

Each user group in a directory can receive different sets of rules, or a default rule can be set for all accounts in a given directory.

Account binding frequency

The account binding process occurs once per directory account. Once the binding has been established between a directory account and a Nametag person, the process does not need to be repeated.

Once an account has been bound to a person, they will be allowed to perform self-service account recovery (password and MFA resets, account unlocks) as configured in your administrator console.

Selecting account binding policies

There are three different types of account binding. If the required account binding data is present for a given user (like a birth date or photo), that person will be able to complete the self-service process.

These policies dictate the minimum assurance required for specific account actions, like password or MFA resets. Nametag automatically uses the highest-assurance data that’s available for an account; this data may come from the verified identity, a directory account, or the API.

This logic ensures that account access is only granted in cases where verified identity data is present and meets the necessary assurance levels (i.e. names that are unique enough to stand on their own).

Tradeoffs to consider

Each policy has a set of tradeoffs that should be considered when configuring group rules. These are ranked on a five-star scale, with five stars representing the best benefit or outcome possible for that item. Each team will need to select the policy that best suits their needs.

	Assurance	End user experience	Admin experience
Name	★★★✫✫	★★★★✫	★★★★★
Name & birth date	★★★★✫	★★★★✫	★★★✫✫
Photo	★★★★✫	★★★★★	★★★✫✫

Assurance represents the level of confidence that the data is effectively protected against potential security threats. This increases as the account binding becomes more secure, which happens as additional data is added.

End user experience refers to the ease with which an end user should be able to gain access to their account(s). It might be friction during enrollment or during recovery, depending on the situation. This often results in frustration with the help desk.

Admin experience refers to the ease that an administrator will have setting up the necessary infrastructure for this to work. This process may include administrative changes in a directory, process changes, internal rollouts to employees, etc.

Name

The name policy offers an effective, high-assurance binding for the vast majority of accounts. It requires no action on the part of the end user, but it does leave a minority of them ineligible for account binding.

In some cases, Nametag is able to determine with confidence that a legal name is the same as a commonly known nickname, like “Dave” for “David.” This allows people who may have a different legal name than the name listed on their directory account. These models also take into account cultural contexts, supporting a wide range of international names and their common alternatives.

Self-service recovery will not be permitted for accounts where it is determined that the name alone is not unique enough to provide the necessary assurance level.

Types of names that are difficult to match and likely will not permit self-service recovery:

• Name is not statistically likely to be unique enough to verify with the government ID alone
• Name has no commonly known nicknames or alternatives
• Name does not belong to a person (e.g. Front Desk)
• Legal name is in a different language or is otherwise fully separate from the directory name

Name & birth date

Directories sometimes contain birth dates, which increase assurance when combined with a person’s name to provide two pieces of data that must be verified. This is because while common names may not be unique, a name and a birth date is more likely to be unique. If this information can be found, it’s added to Nametag through the directory sync and required to match the ID scanned by a person during verification. This applies to all directory accounts which have birth date, regardless of group rules.

In some cases, the addition of a birth date automatically makes certain people eligible for self-service recovery whose names alone were not unique enough.

Birth dates can also be added to Nametag from an external source, like an HR system, using Nametag’s API or directly in the console. This step can be optionally performed for all users.

Profile photo

Profile photos can be added through the API or Admin Additions, which are explained in this section of the document. The profile photo is validated against the image on the ID document, as well as any photos that have already been provided (like selfies during verification requests). As with birthdates, this provides a data attribute that can replace name matching, making self-service recovery available for accounts that may be ineligible due to common name issues with name matching.

Nametag requires that the valid profile photo matches the verified selfie, which further protects directory accounts against impersonators; even in the unlikely case that an attacker presents a fraudulent ID that Nametag doesn’t identify as illegitimate, the attacker would still be stopped because the profile photo wouldn’t match.

If an administrator or owner tries to upload an image of a face that does not match the faces in previous photos for that individual, they will receive an error. Nametag expects consistency in the photos of a person, looking to match biometric information with previous photos to ensure that it is the same individual each time.

Uploaded photos can only be replaced until they are used in a successful comparison, after which the chain of photos is establish and none of them can be replaced.

Please note: If you are using profile photo, it is important that your company is confident that the source of these photos is reliable and accurate (like your HR system).

Configuring account binding policies

Nametag provides group-based account binding policies for each connected directory. Account binding policies can be configured for MFA reset, Password reset, and Locked account unlock (Okta only) for any given directory group.

The different reset rules are independent from one another, meaning that the restrictions set for groups in the MFA section do not impact restrictions set in the password reset rules, and neither affect the locked account unlock rules. Each section below explains how these rules apply.

Name

When selected, an acceptable name match is sufficient to bind an account and allow self-service recovery. This includes any name deemed unique enough by the Nametag model.

In addition to requiring a name match, the following data attributes must also match if they are provided in Nametag (either through the API or Admin additions):

• Birth date
• Profile photo

Name & birth date

When selected, an account must pass name matching and be augmented with a matching birthdate. When a birthdate is not present, self-service recovery is not possible for the account.

In addition to requiring a name match, the following must also match if they are provided:

• Profile photo

Profile photo

When selected, the profile photo must be present and it must match the image on the ID. Name matching is not performed.

The following must also match if it is provided:

• Birth date

Disabled

This setting is appropriate for groups who should not have permission to reset their own passwords or MFA tokens, or to unlock their own accounts (Okta only). When selected, the specified reset type is not available to users in that group.

An example of an appropriate use for this setting might be password resets for privileged-level accounts. Automated password resets for accounts in an executive directory group may not be something that a conservative security organization would permit.

All accounts

The default setting for a directory’s self-service policies applies to all of the accounts and groups in the directory. This is a good option for teams who want to set one recovery policy that applies to everyone at the company.

Catch-all rule for others

If a group rule has been configured, you’ll see this setting change to Catch-all rule for others. This setting acts as a kind of fallback that applies to any accounts that do not match by group rules set above it. This applies to any individual whose account is not in a group with a recovery policy.

Adding account data to Nametag

Data attributes can be added to Nametag in two ways:

1. Nametag API
2. Admin Additions

Nametag API

Data can be added to Nametag accounts through Nametag’s open API. More information on strengthening accounts with additional data attributes can be found in this section of the API documentation.

Admin Additions

Administrators and owners can manually add data to individual accounts directly on the Accounts pages in Nametag.

Profile photos can be uploaded using the blue plus sign on the missing image circle. Images must be under 7 MB and uploaded in either PNG or JPG format. If a profile photo is added that does not match the photos taken for this account in the past, a warning will appear and the photo will not be updated.

Birth dates can be added from here as well.

Review an account’s self-service eligibility

If an individual is not eligible for self-service recovery, it is because they do not meet the necessary requirements to satisfy the policies set for their directory.

This is displayed right below the account information and explains which self-service actions are available for that individual. These are the things they will and will not be able to do from your company’s custom self-service site.

Reset process for employees

Once you’ve configured these policies, employees can follow these instructions in order to reset their accounts.

In addition, they will be able to skip the ID scan in subsequent requests when using the same device and only provide a selfie to verify themselves. This selfie step continues to prevent fraudsters from accessing accounts, even if the original device is unchanged.

If an employee does not meet the necessary requirements for self-service account recovery (i.e. the self-service policies for their groups/directories), they will complete the identity verification process before landing on the recovery site and seeing a message that they are ineligible. At this point, they should contact the helpdesk.

Employees must verify their identities before receiving ineligibility messages for security reasons. If an individual is unable to prove that their identity is valid and they work for your company, they are not privy to any information about an account or its validity.

In conclusion

Selecting the right account binding policy for your team involves understanding the trade-offs between assurance levels, user experience, and administrative ease. It’s also an important part of setting up your directory integrations, ensuring that self-service account management is only available to desired groups of accounts.

Nametag’s default name policy is an effective, secure account binding solution that automatically allows self-service account recovery for the majority of people. It requires no action on the part of the end user, but may leave a small minority of accounts with common names ineligible until additional data is provided (like a birth date or profile photo).

Additional data can be added to an account at any time, ensuring that account binding continues to get stronger as information is added to Nametag. As detailed in this document, there are multiple ways that an account can be augmented.

Your ultimate goal is to find the right policies to keep company accounts secure while still making it easy for your employees to access and recover their accounts when they need to.

Glossary

Account binding

The underlying logic that dictates how self-service recovery policies are executed; based on identity and account data

Data attribute

This is a piece of data about an individual. It might be a photo, their name, birthday, or a profile photo. These data attributes are used to determine a person’s access to self-service recovery

Directory account

An account, usually in a company’s directory provider(s) like Entra or Okta, that belongs to an employee of the business and has its own access credentials (MFA devices, passwords, etc.)

Nametag person

A person’s verified Nametag identity based on data captured from their government-issued ID and from a selfie