Skip to main content
U.S. flag

An official website of the United States government

Dot gov

The .gov means it’s official.
Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

Https

The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Use Cases

These use cases are designed for ICAM Enterprise Architects and business owners and describe some of the most common ICAM business processes.

Each use case includes a high-level summary of the scenario, individuals and systems involved in the use case, illustrations that show the required steps to achieve the end goal, and an icon that indicates the practice area and the service with which the use case most closely aligns.

For details about ICAM services, see the Services Framework.

While each use case describes a particular ICAM business process, the use cases are all interrelated. The use cases generalize the activities and technologies to make sure they apply across many agencies. The use cases don’t include agency-specific functions and process details because your agency should analyze your systems and processes to align with these broad use cases.

You can combine or build upon the ICAM use cases to support your agency’s scenarios and needs.

Three hexagons with the letters I, C, and A. The I is highlighted in red for Identity Management, with a red banner for the Creation service.

When you onboard an employee or contractor at your agency, you collect identity information from the individual and store parts of that information as identity attributes. These attributes serve as a digital proxy for the individual’s identity, also known as an enterprise identity.


Use Case

In this use case, an administrator needs to collect or manage identity data for an employee or contractor for the purpose of creating an enterprise identity record and maintaining it throughout its lifecycle.

Icon Key for the diagrams that follow.

1. Collect information
A diagram showing an employee or contractor providing identity information to an administrator with the authoritative source.
The administrator collects identity information from the employee or contractor.

This identity information may come from the individual, onboarding documents, or HR systems.
2. Create an enterprise identity
A diagram showing the authoritative source populating the identity information into a data repository, creating an enterprise identity in the authoritative source.
The administrator adds the identity information to the authoritative source, a data repository.

Result: An enterprise identity in the authoritative source for the employee or contractor.
3. Maintain the enterprise identity The following steps describe identity maintenance your agency should perform on a regular basis.
3a. Identify and aggregate identity data
A diagram showing the data repository with multiple enterprise identities for one individual, and an arrow indicating the change to a single consolidated enterprise identity.
Query your data repositories for any existing identities for an individual. Aggregate these attributes as a single enterprise identity for the individual.
3b. Update the enterprise identity
A diagram showing two paths to update an identity. Path 1 is the administrator updating the enterprise identity directly in the authoritative source. Path 2 is the employee or contractor updating their personal information in an agency application, and the application updating the enterprise identity in the authoritative source.
If an individual has updated personal information, there are two ways to update the enterprise identity:

  • The administrator updates the individual’s enterprise identity attributes directly in the authoritative sources.
  • The individual uses an agency application to update their personal information, and the application updates the individual’s enterprise identity attributes in the authoritative sources.
3c. Delete the enterprise identity
A diagram showing an administrator deleting an enterprise identity.
When you need to delete an enterprise identity, delete the identity attributes in the authoritative source.

Example

I want to create a new enterprise identity so that an individual may be established as a federal employee or contractor that will need to be identity proofed, credentialed, and granted access to agency services.


Back to Top

Three hexagons with the letters I, C, and A. The I is highlighted in orange for Identity Management, with an orange banner for the Identity Proofing service.

Before you can create a credential and assign it to an individual, that person must provide proof of their claimed identity. Identity proofing is the process by which a federal agency collects and verifies information about a person to establish an enterprise identity.

The location or information that a person needs to access informs the Identity Assurance Level (IAL), which determines the elements you should require from that person for identity proofing. There are three IALs; however, federal agencies require a minimum of IAL2 for employees or contractors with recurring access to government resources, so these use cases do not include IAL1.

This use case describes the high-level steps to proof an identity at IAL2 or IAL3. Depending on the required IAL, you may require increasingly more information from an employee or contractor or partner along with additional verification steps. The information provided by the employee or contractor is also known as identity evidence. Identity evidence may be physical, such as passports, driver’s licenses, and birth certificates.

  • IAL2 - first and last name, email address, and address of record, supported by appropriate identity documentation and verified as strong.
  • IAL3 - first and last name, email address, address of record, and fingerprints, supported by appropriate identity documentation and verified as superior.

For more information about identity proofing and IALs, see NIST SP 800-63-A (Section 2.2).


Use Case

In this use case, an administrator needs to collect or manage identity data for an employee or contractor for the purpose of creating an enterprise identity record and maintaining it throughout its lifecycle.

Icon Key for the diagrams that follow.

1. Collect identity information
A diagram showing an employee or contractor presenting information or data to an administrator.
IAL2 (In-person or remote) - The employee or contractor presents identity information, like first name, last name, and address of record.

IAL3 (In-person or supervised remote) - The employee or contractor presents identity information, like first name, last name, and address of record, and biometric data like fingerprints.
2. Verify the identity information
A diagram showing an administrator verifying information presented by an employee or contractor.
IAL2 - The administrator confirms the information provided is valid and current by comparing photo identification to the individual, or confirming contact information, ensuring it matches the provided documentation.

IAL3 - The administrator verifies all information with the issuing organization.
Result: The individual’s identity has been successfully proofed at IAL2, or IAL3.

Examples

  • I want to proof the identity of an employee or contractor to verify that the individual is who she says she is so that she can be issued a unique enterprise credential.
  • A prospective employee or contractor has filled out their information in an HR system and requires IAL3 proofing and minimum background investigations. The prospective employee/contractor is then scheduled for in-person proofing. The prospective employee/contractor brings required identity documentation; the information is verified using approved documentation and biometrics are captured.

Back to Top

Three hexagons with the letters I, C, and A. The I is highlighted in orange for Identity Management, with an orange banner for the Provisioning service.

You can assign access entitlements to individuals, roles, and groups. These entitlements define an employee or contractor’s access to agency services, so you’ll need to assign entitlements before an employee or contractor can access an agency service.


Use Case

In this use case, an administrator needs to assign entitlements to an employee or contractor.

Icon Key for the diagrams that follow.

1. Initiate the request
A diagram showing an employee or contractor requesting entitlements from an administrator.
An individual requests entitlements, or joins a team with specific access requirements.

The requestor may be the employee or contractor, their supervisor, HR, or a security team member.
2. Review the request
A diagram showing an administrator comparing an entitlement request with access requirements.
The administrator compares the employee or contractor’s requested entitlements with the relevant access requirements.

If the employee or contractor qualifies for the requested entitlements and has a mission need for access, the administrator approves the request.
3. Assign the entitlements
A diagram showing an administrator assigning entitlements to the employee or contractor.
The administrator assigns the entitlements to the employee or contractor.

Any time the employee or contractor’s role or relationship changes, the administrator updates the entitlements accordingly, including removing entitlements as needed.

Examples

  • I want to indicate that an employee or contractor requires and is allowed access to an agency service so that they can access the service when needed.
  • An employee is hired to be part of the financial review team and requires access to financial applications. The employee has a role assigned to their enterprise identity record and associated with their identity attributes.

Back to Top

Three hexagons with the letters I, C, and A. The C is highlighted in green for Credential Management, with a green banner for the Issuance service.

After you identity proof an individual, you’ll issue some proof of that individual’s claimed identity. A credential (like a physical card) is a type of authenticator that serves as a tool for an employee or contractor to gain access to agency services.


Use Case

In this use case, an administrator needs to issue a credential to an employee or contractor.

Note: The preferred credential for employees and contractors is a PIV card. For cases where you cannot issue a PIV card, you must use a combination of factors to reach at least an Authenticator Assurance Level 2 (AAL2) credential.

For more information about authentication and AALs, see NIST SP 800-63-B (Section 4).

Icon Key for the diagrams that follow.

1. Initiate the request
A diagram showing an employee or contractor and a sponsor or supervisor initiating a credential request with an administrator.
An individual presents a valid government issued ID.
2. Review the request
A diagram showing an administrator verifying the presented credential with the organization that issued it.
The government ID is verified with the organization that issued it.
3. Generate and assign the authenticator(s)
A diagram showing an administrator generating and assigning an authenticator to the employee or contractor.
Generate and assign the authenticator to the individual.

Example

I want to issue an enterprise credential, unique to an employee or contractor, so that they are able to access federal buildings and protected resources to which they require access.


Back to Top

Three hexagons with the letters I, C, and A. The C is highlighted in green for Credential Management, with a green banner for the Maintenance service.

A derived credential is a credential derived from an existing credential, with a different form factor, such as a credential on a mobile device. Derived credentials have the same IAL as the existing credential and the same or lower AAL.

When an employee or contractor requires authentication but cannot leverage an existing credential, they can use a derived credential. To be eligible for a derived credential, the employee or contractor must already have a valid credential with Authenticator Assurance Level (AAL) 2 or 3.


Use Case

In this use case, an employee or contractor interacts with the agency services to register or request a derived credential.

Icon Key for the diagrams that follow.

1. Initiate the request
A diagram showing an employee or contractor initiating a derived credential request to an enterprise identity management system.
A request for identity data is initiated to the identity manager.

This identity manager could be a person or system, depending on the organization.
2. Authenticate the existing credential
A diagram showing an employee or contractor authenticating an existing credential to an enterprise identity management system.
The identity manager identifies relevant sources of data on the individual.

Sources could include HR systems, security data, and personal databases.
3. Generate the derived credential
A diagram showing an enterprise identity management system generating a derived credential for an employee or contracter.
Generate the derived authenticator and note the change in the user's enterprise identity record.

Examples

  • I want to provide an employee or contractor, who has already been issued an enterprise credential, a derived credential so that they can authenticate to enterprise applications.
  • An employee or contractor travels quite a bit as part of their job. Accordingly, they are frequently limited to using a small tablet or their phone to stay connected while on the go. In this case, a derived credential is needed for purposes such as accessing secure agency websites or an agency VPN from their mobile device.

Back to Top

Three hexagons with the letters I, C, and A. The C is highlighted in green for Credential Management, with a green banner for the Maintenance and Revocation services.

Active credentials require regular maintenance. This use case describes the most common credential maintenance activities:

  • Reset a credential - An employee or contractor forgets the password or PIN associated with a credential and requests a reset.
  • Renew a credential - An employee or contractor’s credential is expiring or their identity information changes, so they request a replacement credential. You must renew a credential prior to the expiration date; otherwise, the employee or contractor must go through the issuance process again.
  • Revoke a credential - An employee or contractor is no longer eligible for their credential (like separating from the issuing agency). The sponsor, supervisor, or administrator requests a revocation of all associated credentials and enterprise accounts.

You should periodically review your employee or contractors’ eligibility for credentials to identify potential orphaned data.


Use Cases

Icon Key for the diagrams that follow.

Reset a Credential

In this use case, an administrator needs to reset a password or PIN for an employee or contractor credential.

1. Initiate the request
A diagram showing an employee or contractor initiating a password or pin reset request to an enterprise identity management system.
An employee or contractor forgets their password or PIN, and requests a reset.

If the request is valid, the identity management system approves the request.
2. Issue a reset
A diagram showing an enterprise identity management system issueing a password or pin reset to an employee or contracter.
The system issues a password/PIN reset, which may be a temporary password or a link to a web-based reset form.
3. Reset the credential
A diagram showing an employee or contractor resetting a password or PIN.
The employee or contractor resets their password or PIN.

Renew a Credential

In this use case, an administrator needs to issue a new credential to replace one that will expire soon or has outdated identity information.

1. Initiate the request
A diagram showing an employee or contractor initiating a credential renewal request to an enterprise identity management system.
An individual requests a renewal for an employee or contractor’s credential.

This individual may be the employee or contractor, their supervisor, or an administrator with approval authority.

This could also be an automated process triggered by schedules or specific events.
2. Review the request
A diagram showing an enterprise identity management system reviewing a credential renewal request for an employee or contracter.
The identity management system reviews the request and verifies that the employee or contractor qualifies for a renewed credential. If so, approve the request.
3. Replace the credential
A diagram showing an enterprise identity management system issueing a new credential to an employee or contracter.
The system issues a new credential to the employee or contractor, and updates the associated enterprise identity record.

Revoke a Credential

In this use case, an administrator needs to revoke an active credential.

1. Initiate the request
A diagram showing an employee or contractor or a sponsor or supervisor initiating a credential revocation request to an enterprise identity management system.
An individual sends a separation notification or a notice of a lost or compromised credential, requesting revocation.

This individual may be the employee or contractor, their supervisor, HR, or a security team member.
2. Disable the credential
A diagram showing an administrator of an enterprise identity management system invalidates the credential.
The administrator invalidates the credential.
Depending on your agency, an individual or a system may perform this task.
3. Return the credential
A diagram showing an administrator returning the invalidated hardware or physical credential to the supervisor or sponsor.
If the revoked credential is physical or hardware-based, the administrator returns the credential to the appropriate individual.

This individual may be a supervisor, HR, or security team member.

Examples

  • An employee or contractor may have attempted to use a credential and input the PIN information incorrectly several times up to an agency-defined limit and has locked their account or credential. The employee or contractor requests a PIN reset. The employee or contractor is directed to an unlock service; has to verify information again to prove they are the same person issued the original credential; and follows prompts to unlock their credential, generating a new PIN in the process.
  • Reset - I want to verify the identity of an employee or contractor that has already been issued a credential and reset their PIN or password so that they can continue to access enterprise resources.
  • Renew - I want to verify the identity and eligibility of an employee or contractor, who has a previously issued credential that is near expiration, so that they may be issued a new enterprise credential to maintain their ability to access enterprise resources.
  • Revoke - I want to remove access to enterprise resources for an employee or contractor so that they can no longer use the protected resource.

Back to Top

This use case corresponds to the Authentication and Authorization service areas of Access Management.

This use case describes the steps to authenticate individuals and authorize access to agency services. Agency services can be anything from applications and files to physical facilities.


Use Case

In this use case, an Access Control System (ACS) Administrator needs to grant access to an employee or contractor who has an enterprise identity and active credential and needs to access a logical or physical resource. These steps assume the employee or contractor already has credentials to support authentication as well as the access entitlements to support authorization decisions.

  • Authentication - I want to verify the claimed unique identity of a given employee or contractor so that the system can verify the right individual is attempting to access an agency service.
  • Authorization - I want to allow access for only employees and contractors that meet established requirements so that only the people who should have access do have access.

Icon Key for the diagrams that follow.

1. Access Attempt
A diagram showing an employee or contractor attempting to access a agency service through an access control system.
An employee or contractor attempts to access an agency service.
2. Authenticate the employee or contractor
A diagram showing an employee or contractor presenting either an IAL2 or IAL3 authenticator to an access control system.
The employee or contractor presents an authenticator to the ACS that meets the protected resource’s minimum assurance requirements:
  • AAL2 (two-factor) - Something you know + something you have, like a one-time passcode.
  • AAL3 (two-factor + hardware) - Something you know + something you have, like a one-time passcode generated by a hardware-based authenticator; or a PIV credential. For more information about AAL values, see NIST SP 800-63B Section 5: Authenticator and Verifier Requirements.
3. Determine the access entitlements and access requirements
A diagram showing an access control system determining the access entitlements and access requirements.
Upon successful authentication, the ACS identifies 1) The employee or contractor's access entitlements associated with the protected resource, and 2) The protected resource's access requirements.
4. Process the access information
A diagram showing an access control system processing the employee or contractor access entitlements to the protected resources's access requirements.
The ACS compares the employee or contractor’s access entitlements to the protected resource’s access requirements to decide whether to authorize access.
5. Grant access
A diagram showing an access control system granting access to an employee or contractor.
If the employee or contractor meets the protected resource’s access requirements, the ACS grants access to the protected resource.

The ACS logs the access attempt and decision for auditing purposes.

Example

An employee on the financial review team attempts to access a government financial application that is secured by a single sign-on (SSO) solution. The employee clicks a link to the financial application and is redirected to the SSO portal. The employee authenticates using his/her provided credential, which the SSO determines to be valid. The SSO solution or the financial application system finds the employee’s enterprise identity account and compares the roles assigned to those allowed by the financial application. The resulting determination is that the employee has authenticated to the required assurance level and has the appropriate entitlements to access the system and is subsequently logged on.


Back to Top

Three hexagons with the letters I in red, C in green, and A in blue, with a gray banner for the Attribute Exchange service in Federation.

Federal employees and contractors often need to access protected services managed by other federal agencies. Federation is the means by which an agency can accept authentication assertions and associated identity attributes from systems within their agency and at other agencies. This allows federal employees and contractors from across agencies to access protected resources and streamlines the user’s experience.

Agencies can pass assertions to share attributes about employees and contractors.


Use Case

In this use case, an employee or contractor from Agency A attempts to access a federated service at Agency B. This use case assumes the employee or contractor already has an account or entitlements to access resources at Agency B, or that they will be provisioned.

For more information about granting access to protected resources, see Use Case 7. Grant Access.

Icon Key for the diagrams that follow.

1. Request access to federated service
A diagram showing an employee or contractor from Agency A requesting access to a federated service at Agency B.
An Agency A employee or contractor requests access to a federated service at Agency B.

The employee or contractor selects the Agency A authentication service.
2. Redirect to Agency A for authentication
A diagram showing an employee or contractor access request is redirected from Agency B access control system to the Agency A authentication service.
The Agency B system redirects the employee or contractor to the Agency A authentication service.

Agency A authenticates the employee or contractor.
3. Perform transparent transaction
A diagram showing Agency A authentication service passing identity attributes to the Agency B access control system.
Agency A passes identity attributes and transaction data to Agency B via a signed assertion.
4. Agency B grants access
A diagram showing Agency B access control system granting access to an employee or contractor from Agency A.
Agency B consumes the assertion data, optionally correlating it with an established account or local identity and makes an access control decision.

The Agency B system redirects the employee or contractor to the federated service.

Examples

  • I want to allow other federal agencies’ employees and contractors (who meet specific requirements) to access some of my agency’s resources, which facilitates cross-government collaboration and information sharing.
  • An employee or contractor from Agency A visits a shared service operated by Agency B to service all federal government users. At the homepage, the employee/contractor selects their Agency A icon and is redirected to their Agency A SSO portal. They log in using their Agency A managed credentials and are redirected back to the Agency B shared service.

Back to Top </div> </div>

IDManagement.gov

An official website of the General Services Administration

Looking for U.S. government information and services?
Visit USA.gov Edit this page