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.

FICAM Architecture

U.S. General Services Administration Logo U.S. Federal Chief Information Officer Council Logo


FICAM Architecture version table
Version Number Date Change Description
3.3 6/20/2023 Combined separate architecture pages into a single web page. Updated change table to reflect all version updates.
3.2 9/30/2022 Editorial updates.
  • 1. Consolidated use cases into a table format.
  • Combined services framework and services description.
  • Updated access management services description to differentiate authentication from authorization and include an overview of difference access models.

Map FICAM playbooks to FICAM Roadmap Part B content. **Version 3.2 sunsets FICAM Roadmap Part B content**.

3.1 1/6/2021 FICAM Architecture v3.1 incorporates updates proposed by the Federal CISO Council ICAM Subcommittee.
  • Clarified introduction, goals, and objectives section.
  • Added Privileged Access Management as Access Management Service.
  • Added Identity Governance as Governance Services.
  • Streamlined use case language and order.
  • Updated system component examples.
  • Updated standards and policies.
  • Updated graphics.
3.0 11/27/2019 Version 3.0 for the Architecture represents the baseline changes to FICAM Roadmap Part A released in 2016. Version 3.0 sunsets FICAM Roadmap Part A content.
2.0 12/2/2011 Revised to include new Part B:Implementation Guidance
  • Chapter 6: ICAM Implementation Planning
  • Chapter 7: Initiative 5: Streamline Collection and Sharing of Digital Identity Data
  • Chapter 8: Initiative 6: Fully Leverage PIV and PIV-I Credentials
  • Chapter 9: Access Control Convergence
  • Chapter 10: Initiative 7: Modernize PACS Infrastructure
  • Chapter 11: Initiative 8: Modernize LACS Infrastructure
  • Chapter 12: Initiative 9: Implement Federated Identity Capability
  • Inclusion of Glossary appendix
  • Editorial and formatting corrections
  • Terminology updates to maintain consistency between Parts A and B
  • Updates to content related to the Federal Public Key Infrastructure to reflect infrastructure upgrades since original publication.
1.0 11/10/2009 Initial publication of the document, including:
  • Chapter 1: Introduction
  • Chapter 2: Overview of ICAM
  • Part A: ICAM Segment Architecture
  • Chapter 3: ICAM Segment Architecture
  • Chapter 4: ICAM Use Cases
  • Chapter 5: Transition Roadmap and Milestones

Introduction

FICAM is the federal government’s implementation of Identity, Credential, and Access Management (ICAM).

ICAM is the set of tools, policies, and systems that an agency uses to enable the right individual to access the right resource, at the right time, for the right reason in support of federal business objectives.

This version of the FICAM Architecture encompasses the enterprise ICAM policies, technologies, and system approaches for government employees, contractors, and authorized partners. Citizen interactions with the federal government - or consumer ICAM - are not covered under this version of the FICAM Architecture.

The following diagram is a high-level view of the ICAM practice areas and supporting elements.

A diagram with definitions and icons for identity, credential, and access management and definitions for federation and governance.

The FICAM Architecture includes government-wide enterprise architecture views with the flexibility to support each agency’s unique business or mission needs. Use the FICAM Architecture as a tool to continuously improve upon your agency’s approach and align with federal security and privacy initiatives.

Copy the graphics and text throughout this playbook to use at your agency to drive ICAM awareness, strategy developments, and communications.

What Is ICAM?

ICAM is the set of tools, policies, and systems that an agency uses to enable the right individual to access the right resource, at the right time, for the right reason in support of federal business objectives.

Agencies implement ICAM services and solutions to unify their IT services, improve physical access control, and improve information security and decisions. Understanding the building blocks of ICAM is key to understanding the FICAM Architecture. ICAM has three practice areas and two supporting elements. The supporting elements enhance the capabilities of the practice areas.

What Is the FICAM Architecture?

FICAM is the federal government’s enterprise approach to design, plan, and execute common ICAM processes.

The FICAM Architecture is a framework for an agency to use in ICAM program and solution roadmap planning. The FICAM Architecture focuses on enterprise identity processes, practices, policies, and information security disciplines.

A federal enterprise identity is the unique representation of an employee, contractor, or enterprise user, which could be a mission or business partner, or even a device or technology managed by a Federal agency to achieve its mission and business goals (OMB Memorandum 19-17).

Who Is the FICAM Architecture for?

The FICAM Architecture is for agency personnel. An enterprise architecture is primarily used by:

  • Senior Federal IT and Agency Stakeholders to understand the concepts for identity and access management services and the basic use cases supporting business objectives.
  • Program Managers to find common definitions and frameworks for use in planning.
  • Enterprise and Application Architects to use a common framework for designing and governing IT systems, applications, and implementations.

There are four main governmentwide initiatives to help agencies implement and manage an Agency ICAM program and technology.

  1. Planning and Configuration Guidance The FICAM Architecture and accompanying playbooks provides an overall guide for meeting federal ICAM requirements in an efficient and secure way. It focuses on enterprise identity processes, practices, policies, and information security disciplines. Playbooks offer stakeholders overarching strategies and tactical approaches for implementing technical FICAM topics.
  2. Interagency Forum and Subcommittee: The Federal Chief Information Security Officer (CISO) Council is a primary resource for identity management, secure access, authentication, authorization, credentials, privileges, and access lifecycle management. The ICAM Subcommittee aligns identity management activities of the federal government and supports collaborative government-wide efforts.
  3. Approved Products Lists (APL): The Federal Information Processing Standard 201 (FIPS 201) Evaluation Program not only tests commercial products for use in Personal Identity Verification (PIV) credentialing systems, physical access control systems (PACS), and public key infrastructures but also publish APLs. Federal acquisition professionals rely on these APLs to purchase commercial products that fully comply with federal ICAM mandates.
  4. Federal Public Key Infrastructure (PKI): The Federal PKI is a network of certification authorities (CAs) that issue PIV credentials and person identity certificates; PIV-Interoperable credentials and person identity certificates; and other person identity certificates. CA-issued digital certificates, which employ cryptography, close security gaps in user identification and authentication, encryption of sensitive data, and data integrity.

What Is the History of the FICAM Architecture?

The FICAM Architecture was created in 2009 to provide a common ICAM segment architecture for federal agencies. The FICAM Architecture was the primary foundation of what later became the FICAM Roadmap and Implementation Plan enhanced with complementary implementation sections.

In 2015, ICAM experts from across the federal government collaborated on an updated FICAM Architecture. This update was intended to be more concise, easy to understand, and visually appealing while reflecting the latest updates in cybersecurity, enterprise architecture, and ICAM policy and technology.

This site contains the current version for the FICAM Architecture. The FICAM Roadmap and Implementation Guidance v2.0 is superseded by both the FICAM Architecture updates and other complementary modernized playbooks developed by ICAM committees across government.

Goals and Objectives

The Goals and Objectives identify the aims and outcomes of a federal agency enterprise ICAM program. The goals and objectives align with ICAM functions and map to government-wide policies, cross-agency priorities, and strategic government initiatives.

Goals are aspirational statements designed for senior government leaders, agency executives, and agency ICAM program leadership responsible for setting program strategy. Objectives are action areas where agency execution strategies, action plans, and performance metrics can be developed based on alignment with mission needs.

The visual below presents the three goals, each with its own objectives.

Three boxes that define the goals and their corresponding objectives.

Goal 1: Modernize security policies and solutions to make risk-based decisions, automate identity and access management processes, and move access protections closer to government data.

  • 1.1 Review, update, and maintain comprehensive ICAM policies and technology solution roadmaps to inform and enforce enterprise strategic planning, risk management, and modernization.
  • 1.2 Adopt and use cloud-ready systems that provide an efficient and secure way to access resources.
  • 1.3 Monitor and respond to user behavior and events by using data as a strategic asset to make adaptive and risk-based decisions.

Goal 2: Enable missions to efficiently deliver services to federal and contractor employees and resources.

  • 2.1 Establish and manage identities for all enterprise users and resources.
  • 2.2 Design enterprise solutions to manage access to information and resources.
  • 2.3 Use enterprise identity information discovery and enterprise centralized access management.
  • 2.4 Leverage federated solutions to accept identity and authentication assertions made by other agency and mission partners when efficient.

Goal 3: Provide enterprise-level solutions within agencies to improve operations and promote cost-effective and efficient use of resources.

  • 3.1 Streamline ICAM governance and program management within each agency to optimize execution, ensure consistency, and align intent across the enterprise.
  • 3.2 Evaluate, rationalize, and migrate to modern, cloud-smart solutions for ICAM services.
  • 3.3 Promote interoperability and efficiency across the federal government by buying and building ICAM solutions that use open, commercially adopted standards.

Services Framework and Service Descriptions

The Services Framework is a tool designed for ICAM program managers and information technology enterprise architects. It identifies the services that provide functionality within the scope of ICAM and assists in distinguishing between business requirements and technical solutions. The services framework includes the five practice areas and services within.

Practice Area Visual

The graphic below illustrates the five ICAM practice areas and provides a list of services that fall within each area.

Five boxes that each correspond to a FICAM practice area or supporting element. Each box lists the agency services that correspond to that area. You can find the services and definitions in the following pages.

Identity Management

An orange box with the list of Identity Management services defined later in the body text of this page.

Identity Management is how an agency collects, verifies, manages attributes, and entitlements to establish and maintain enterprise identities for federal government employees, contractors, and authorized mission partners. This service does not apply to public or consumer identity management.

An enterprise identity record is the set of attributes or characteristics that describes a person within a given context:

  • Your identity within your agency’s Human Resources (HR) system is different from your personal identity at your bank.
  • A person’s identity as a government contractor is different from their identity as an Army Reservist.

Although your identity remains the same over time, it evolves as your attributes change, such as when you get a promotion, change your name, receive additional training, or retire.

Agencies should manage identity attributes as centrally as possible and distribute them as needed. Examples of identity attributes include:

  • Core identity attributes - First name, last name, and address of record.
  • Contact attributes - Physical location, government phone number, and government email address.
  • Authorization attributes - Clearance, training, and job codes.

An entitlement is a specific type of authorization attribute that refers to an application permission. Entitlements management is the act of managing those permissions. An agency may group multiple entitlements into a specific role or group to streamline provision and de-provision activities as well as for auditing and reporting purposes. For example, a new employee may require access to ten core enterprise applications on the first day of work. An agency can create a new employee group with new employee entitlements and automate provisioning of the ten core applications rather than treat them as individual access requests. Attributes and entitlements are created or aggregated through a number of manual and automated mechanisms. Mechanisms may include:

Attributes and entitlements are created or aggregated through a number of manual and automated mechanisms. Mechanisms may include:

  • Use a single sign-on tool to aggregate application access entitlements.
  • Allow employees to update contact attributes in an employee record.
  • Automate integration between a training system and an identity governance and administration tool to create and update annual security training.

Identity proofing is how an agency verifies an enterprise identity. The complexity of this process depends on the Identity Assurance Level (IAL) required for an identity. Federal agencies require a minimum IAL3 for employees and contractors. For example, a federal employee or contractor presents identity attributes via a driver’s license or utility bill. The agency verifies the identity documents and the individual’s photo (biometric).

An identifier is a unique attribute used to locate an identity in a system:

  • While your agency may issue Personal Identification Verification (PIV) cards to multiple people named John Smith, each individual has a different PIV card number.
  • While your agency may have more than one employee named Jane Smith, each employee has a unique email address tied only to their identity.

The Identity Management services in the Federal ICAM architecture include Creation, Identity Proofing, Provisioning, Maintenance, Identity Aggregation, and Deactivation. These services are sometimes collectively known as Identity Lifecycle Management.

Service Description Keywords
Creation Establish an identity made of attributes that define a person or entity. Identity Record, Authoritative Source
Identity Proofing Use identity attributes to connect a digital identity to a real-world entity. Source Document Validation, Remote Proofing, In-Person Proofing
Provisioning Create, manage, and delete accounts and entitlements. Identity Lifecycle Management, Workflow, De-provisioning, Account Management, Account Creation, Entitlements Management
Maintenance Maintain accurate and current attributes in an identity record over its lifecycle. Identity Lifecycle Management, Updating, Attribute Management
Identity Aggregation Find and connect disparate identity records for the same person or entity. Identity Reconciliation, Identity Resolution, Account Linking
Deactivation Deactivate or remove enterprise identity records. Identity Lifecycle Management, Suspension, Archiving, Deletion

Credential Management

A green box with the list of Credential Management services defined later in the body text of this page.

Credential Management is how an agency issues, manages, and revokes credentials bound to enterprise identities.

A credential is a data structure that authoritatively binds an authenticator to an existing identity using one or more identifiers.

Types of authenticators include:

  • Something you know, like a password or PIN.
  • Something you have, like a private key or One-Time Password (OTP) generator.
  • Something you are, like a fingerprint or an iris.

The Authenticator Assurance Level (AAL) determines the authenticators associated with a credential. Federal government-wide policy requires a minimum AAL2 for employees and contractors.

Examples of credentials include:

  • An agency-issued smart card, such as a PIV or Common Access Card (CAC), that includes a picture and cryptographic key pairs to assert your identity at a federal facility.
  • A combination of credentials, such as a username/password with an OTP generated by a mobile application, to assert your identity to a federal web application.

Unlike identities, credentials can expire. If an enterprise identity continues past a credential’s expiration date, the issuing agency can issue a new credential.

The Credential Management services in the FICAM architecture include Sponsorship, Registration, Generation & Issuance, Maintenance, and Revocation.

Service Description Keywords
Sponsorship Formally establish that a person or entity requires a credential. Sponsor, Authorizing Official, Affiliation, Request
Registration Collect the information needed from a person or entity to issue them a credential. Enrollment
Generation & Issuance Assign a credential to a person or entity. Activation, Token, Authenticator
Maintenance Maintain a credential throughout its lifecycle. Renewal, Reset, Suspension, Reissuance
Revocation Revoke a credential from a person or entity, or deactivate an authenticator. Termination

Access Management

A blue box with the list of Access Management services defined later in the body text of this page.

Access Management is how an agency authenticates enterprise identities and authorizes appropriate access to protected services.

Policy administration is a combination of laws, regulations, rules, and agency policies that secures access to agency services. Your agency determines the requirements for an individual to access each resource category; they can be as simple or as complex as needed.

Examples of access requirements include:

  • “Grant access to anyone on this list of people.”
  • “Grant access to any agency employee or contractor with an authenticated PIV card.”
  • “Grant access to anyone who is a federal employee, GS-12 or higher, cleared Top Secret, trained in first aid, and certified as a project manager.”

In providing access services, it can be challenging to conduct an application discovery and inventory for both physical and logical access. For logical access, see the Application Inventory and Identity Risk Analysis section of the Enterprise Single Sign-On Playbook.

Authentication

Authentication is how you verify the claimed identity of someone trying to access an agency resource. Typically, you’ll verify an identity using an authenticator associated with a credential. To determine the appropriate authenticator level, use the Digital Identity Risk Assessment Playbook

Authentication is generally a two-step process:

Step 1. Authenticate the credential:

  • Did a trusted organization issue the credential?
  • Has the credential expired?
  • Has the credential been revoked, voided, or tampered with?

Step 2. Ensure the individual to whom the credential was issued is the same individual presenting it:

  • Do the photo and attributes on the credential match the person who presented it?
  • Does the person know the PIN for the credential?
  • Does the person have the private key on the smart card for the certificate presented to a website?

Authorization

Authorization is how you decide whether you should allow someone to access an agency resource. Access requirements usually dictate whether you’ll allow someone to:

  • Read or modify a certain document.
  • Access an agency website.
  • Enter an agency facility or location.

Usually, authorization occurs immediately after authentication. When you log in to a service, you present your credentials. The service then confirms that your credentials are valid (authentication) and grants or denies you access based on your assigned permissions (authorization).

Authorizations are based on progressive, fine-grained access models. Most agencies implement role-based access and move toward more fine-grained access such as attribute-based or risk adaptive access control, as outlined in the Federal Zero Trust Strategy. While there are defined access models, vendors may implement them in different or overlapping ways. Ensure your agency develops use cases and understands how a vendor meets the use case.

Granularity Access Model Description Example
Least Access Control Lists(ACLs) A static list of entities with their access rights. Allow Jane Doe access to email application
More Role-Based Access Control (RBAC) Access based on a user’s static pre-defined role. Jane Doe is assigned the user role “New Employee” which grants access to email and sharepoint.
More Attribute-Based Access Control (ABAC) Access based on a user’s assigned attributes which may be static or dynamic. Allow Jane Doe to access email if on a government device (device attribute) and in the United States (location attribute).
Most Risk Adaptive Access Control (RAAC) Access based on dynamic risk factors. If Jane Doe is in assigned work location, allow email access from any managed device. If Jane Doe is not in assigned work location, only allow email access from a government device.

Each authorization model has benefits and limitations. The policies and access requirements defined by agency business owners help define the model that best suits their needs. More robust access control models, such as ABAC, can help agencies with improved automation, and they are increasingly adopted by cloud-native and cloud-friendly services.

The Access Management services in the FICAM architecture include Policy Administration, Authentication, Authorization, and Privileged Access Management.

Service Description Keywords
Digital Policy Administration Create and maintain the technical access requirements that govern access to protected agency services. Policy Decision, Policy Enforcement
Authentication Verify that a claimed identity is genuine based on valid credentials. Validation, Two-Factor, Multi-Factor
Authorization Grant or deny access requests to protected agency services based on access requirements, identity attributes, and entitlements. Policy Decision, Policy Enforcement
Privileged Access Management Protect access to accounts that have access permissions that can affect IT system configurations and data security (e.g., superusers, domain administrators, or global administrators). Privileged Identity Management, Privileged Account Management, Administration, Superuser

Federation

A gray box with the list of Federation services defined later in the body text of this page.

Federation is the technology, policies, standards, and processes that allow an agency to accept digital identities, attributes, and credentials managed by other agencies.

Federation has many different applications, including:

  • Accepting an authentication transaction from another organization:

Agency A authenticates one of its users and passes identity attributes and transaction details to Agency B. Agency B grants access to an application for that identity.

  • Accepting specific characteristics (i.e., attributes such as identifiers) describing an individual from another organization:

An individual can use their agency-issued credential containing an internal identifier(s) to directly log in to a different agency’s online service. The online service registers the identifier(s) in its system for future use.

The Federation services in the FICAM architecture include Policy Alignment, Authentication Broker, and Attribute Exchange.

Service Description Keywords
Policy Alignment Develop relationships and a common understanding between parties by establishing authorities, policies, standards, and principles. Trust Relationship
Authentication Broker Transform an authentication event into an alternative format, such as an assertion, containing claims about the entity and the authentication transaction, to grant access to a resource. Assertion Service, Federation Assertion, Security Token Service
Attribute Exchange Discover and acquire identity or other attributes between different systems to promote access decisions and interoperability. Attribute Definition

Governance

A navy box with the list of Governance services defined later in the body text of this page.

Governance is the set of practices and systems that guides ICAM functions, activities, and outcomes.

To perform effective governance, agencies must collect data about ICAM functions from many sources, such as policies and entitlements stores, and analyze this data. Proper data analytics help agencies monitor compliance with established information security policies.

If your agency identifies problems during data collection and analysis, you should remediate these issues as quickly as possible. Real-time monitoring and risk mitigation are crucial to ensure employees and contractors have only the appropriate access, following the principle of least privilege.

The Governance services in the FICAM architecture include Identity Governance, Analytics, and Mitigation.

Service Description Keywords
Identity Governance The systems, solutions, and rules that link enterprise personnel, applications, and data to help agencies manage access and risk. Management Framework, Rules and Procedures, Access Reviews and Re-certifications
Analytics Leverage continuous analytics data to identify if someone has entitlements that conflict with access requirements. Data collection, Monitoring, Review, Data Certification, Auditing and Reporting
Mitigation Correct the problems and address risks, discovered by analysis, that may occur during standard operations. Redress, Remediation

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.

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.


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-63A (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.

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.

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-63B (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.


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.

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.

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.


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.

Reference Example

This reference example include sample enterprise ICAM tools (e.g., solutions, applications, and software) aligned with ICAM service areas that illustrate ICAM functionality at an agency. The reference examples are designed for enterprise architects, security engineers, and solution architects to facilitate discussions regarding the technology solutions to integrate with enterprise applications and the business requirements.

The system’s components are representative examples only. Some solutions chosen by your agency may span across more than one service area.

The following figure is an example for a small selection of system components only. You can modify the graphic or incorporate it as is and target state system components for enterprise roadmap planning.

A diagram that shows example components for each service area, and relationships between practice areas.

Authoritative Sources

An authoritative source is a trusted repository of identity attribute data. It’s possible to have multiple authoritative sources for attributes.

Authoritative sources systems components may include:

  • Human Resource systems such as payroll, time and attendance, and benefits administration
  • Agency or government-wide Learning Management Systems
  • Agency or government-wide Personnel Security systems for security and suitability
  • Directory services, including on-premise or cloud-based directory services
  • Other external or internal sources

Identity Management Systems

Identity management systems are how an agency manages the identity lifecycle.

Identity management system components may include:

  • Identity Governance and Administration tool for provisioning and workflow
  • Role management or role manager applications
  • Identity correlation or aggregation
  • Directory management
  • Virtual directories

Credential Management Systems

Credential management systems are how an agency manages an authentication token bound to an identity.

Credential management system components may include:

  • PIV credential service provider solutions
  • Other non-PKI credential service provider solutions
  • Federated certification authorities
  • Private certification authorities
  • Key management services
  • Enterprise certificate manager
  • Multi-factor authentication managers for software and hardware tokens
  • Password managers

Access Management Systems

Access management systems are how an agency leverages credentials to authenticate individuals and authorize access to protected resources.

Access management system components may include:

  • Enterprise Single Sign-On (SSO) applications
  • Web access management applications
  • Physical or facility access control systems
  • Privileged access management applications
  • Access policy and access rules repositories
  • Policy enforcement points
  • Policy decision points
  • Virtual private networks
  • Cloud access security brokers
  • Network access management tools

Governance Systems

Governance is the set of components to centralize management, develop insights, and assist in managing ICAM areas and services. Applications across all service areas include auditing such as standard audit logs or configuration of auditable events. Governance includes the aggregation of individual auditing and reporting into centralized tools to perform real-time or near real-time analysis, identify anomalies, and trigger mitigations for anomalous authentication or authorization events. Tools are increasingly incorporating machine learning or adaptive algorithms.

Governance systems components may include:

  • Identity Governance and Administration (IGA) solutions to perform access re-certifications
  • IT Service Management (ITSM)
  • Security information and event monitoring (SIEM)

Agency Endpoints

Agency endpoints are resources that an agency needs to protect, including physical and digital resources.

Agency endpoints may include:

  • On-premise applications
  • Cloud-based applications and platforms
  • Agency private networks
  • Government cloud email services
  • Government facilities

Policies and Standards

See the ICAM Policy Matrix for the latest set of ICAM policies and standards.

IDManagement.gov

An official website of the U.S. General Services Administration

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