Login.gov-Inherited-Credential_RFI-Att.1_2026-10-01.pdf

General Services Administration Federal Acquisition Service

Technology Transformation Services

1800 F St NW | Washington, DC | 20405

Login.gov’s Inherited Credential Products BPA

DRAFT Statement of Work

DRAFT

1.0 Background and Introduction

Login.gov is a trusted, shared authentication platform that adheres to the highest standards of security, privacy, and user experience. Launched by General Services Administration (GSA) Technology Transformation Service (TTS), Login.gov is designed to provide citizens with a secure singular digital account that can be used across a multitude of government sites.

Login.gov is a critical piece of the U.S. Government’s plans to decrease costs through shared services, increase cybersecurity, and improve customer experience across the government.

Login.gov requires a capability to evaluate and integrate third-party Identity Assurance Level 2 (IAL2) verified identity information into the Login.gov identity proofing workflow by inheriting preexisting IAL2 credentials.

To comply with OMB Memorandum M-26-18, Scaling Use of Login.gov to Deliver a Universal Sign-on for Public Services, agencies must support the governmentwide expansion of Login.gov for covered public-facing digital services. This effort will help reduce fragmentation among federal authentication solutions and provide the public with a more consistent, secure, and convenient means of accessing agency services.

2.0 Scope

The contractor shall provide Login.gov the ability to evaluate and integrate third-party IAL2-verified identity account information from existing accounts that have been identity proofed at IAL2 and are protected at Authenticator Assurance Level 2 (AAL2) using authenticators bound to the account holder. A successful federated authentication will result in a new Login.gov credential being created that is owned and maintained by Login.gov. This scope is intended to distinguish the use and potential reuse of existing IAL2 account information maintained by the contractor or another full-service Credential Service Provider (CSP) from new, transaction-based IAL2 identity proofing performed within the Login.gov workflow.

In addition, the contractor shall provide all necessary products, personnel, resources, technical interfaces, and implementation and integration assistance, as well as other services, to implement and integrate its product into the Login.gov workflow, and to meet all general, security, privacy, and other requirements. The products and services utilized in the performance of these requirements must maintain compliance with all applicable federal laws and regulations, including current NIST SP 800-63 requirements and its successors.

https://www.whitehouse.gov/wp-content/uploads/2026/08/M-26-18-Scaling-Use-of-Login.gov-to-Deliver-a-Universal-Sign-on-for-Public-Services.pdf

3.0 Requirements

3.1 General Requirements

Login.gov consumes multiple Application Programming Interface (API) based services that transmit data using common, secure transport mechanisms and standard data formats. The identity verification data and services utilized in the performance of this requirement must maintain compliance with all applicable federal laws and regulations. The contractor’s identity verification data and services must meet all of the following requirements.

Login.gov requires a scalable, secure, and federally compliant Digital Identity solution delivered as Software-as-a-Service (SaaS) with associated services. The solution must support operational risk management, auditability, and compliance with current and future applicable federal cybersecurity and privacy mandates, including, but not limited to, the Privacy Act; Office of Management and Budget (OMB) M-19-17, Enabling Mission Delivery Through Improved Identity, Credential, and Access Management; M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust; M-25-22, Driving Efficient Acquisition of Artificial Intelligence in Government; Executive Order 14144, Strengthening and Promoting Innovation in the Nation’s Cybersecurity; and GSA Security and Privacy Requirements for IT Acquisition Efforts CIO-IT Security-09-48. Additionally, Login.gov requires contractor collaboration to develop, test, and implement new capabilities to deter and prevent fraud.

ID Requirement

3.1.1 Services shall be able to receive requests and provide responses via Application Programming Interface (API), with data encoded in JSON, YAML, or a format agreed upon by Login.gov.

3.1.2 All products and services shall be existing, commercial software products and services.

3.1.3 All products and services shall be certified with current NIST SP 800-63 and its successors in good standing at the following xALs: IAL2, AAL2, and potentially comply with the requirements of FAL2.

3.1.4 Cloud computing products and services (such as

Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS)) that create, collect, process, store, or maintain federal information on behalf of GSA are required to be FedRAMP Moderate or equivalent authorized.

3.1.5 The contractor, products, and services shall maintain a Kantara Initiative Trust Mark in good standing, to the extent such status demonstrates recognized conformance, oversight, and operational maturity for the proposed identity verification services.

3.1.6 Services shall reach users living inside and outside of the United States.

3.2 Inherited Credential Data Access and Integration

Login.gov accepts, classifies, authenticates, and validates identity evidence documents from a variety of sources in accordance with current NIST standards. Login.gov requires a solution that can resolve a Login.gov user's information to an identity that has been proofed at Identity Assurance Level 2 via inherited credential. The following requirements shall be met.

3.2.1 The contractor shall provide secure, compliant access to IAL2-verified identity data from the contractor's existing member base, subject to applicable privacy, security, and legal requirements.

3.2.2 The contractor shall support technical integration for secure data exchange, attribute matching, and identity resolution workflows.

3.2.3 The contractor shall be able to evaluate identity attributes including, but not limited to: full name, email address, address, address history, date of birth, phone number, Social Security number, ID type, ID number, ID jurisdiction, ID expiration date, ID issuing date, ID image, biometrics record, location of proofing, associated fraud signals, and date of last proofing event at IAL2. All identity attributes used in the evaluation must be returned or retrievable by Login.gov in real time as part of the user data flow exchange.

3.2.4 The product shall not require users to create new accounts and will only be used for active or existing accounts.

3.2.5 The contractor shall support testing of data exchange protocols, attribute matching algorithms, and inherited proofing workflows by providing access to lower environments and mock personally identifiable information (PII) to validate the integration.

3.2.6 The contractor shall provide secure APIs and integration mechanisms enabling Login.gov to query the contractor's identity database for prior verification events and attributes. Login.gov shall have access to and be able to see the proofing data (documents, selfies, PII, proofing date, etc.) for investigation purposes.

3.2.7 The contractor shall provide documented, secure protocols for transmitting identity attributes and verification evidence.

Secure protocol requirements are documented in GSA IT Security Procedural Guide: SSL/TLS Implementation CIO-IT Security-14-69.

3.2.8 The contractor shall provide the capability to match identity attributes across contractor and Login.gov systems with documented confidence thresholds.

3.2.9 The contractor shall create a process and logic for determining whether a contractor-verified user meets the requirements to leverage inherited proofing (e.g., has an SSN, has a U.S. address).

3.2.10 The contractor shall create an audit and logging capability that provides comprehensive logging and audit trails for all identity verification transactions, data access, and system interactions.

Systems must maintain 12 months of audit logs online and 18 months in cold storage, in accordance with GSA IT Security Procedural Guide 01-08, Audit and Accountability (AU).

3.2.11 The contractor shall ensure users understand and consent to data sharing between the contractor and Login.gov.

3.2.12 The contractor shall provide a scalable environment for evaluating inherited proofing with a large existing verified user base

3.2.13 The contractor shall not monetize, commercialize, sell, license, transfer, share, disclose, reuse, repurpose, mine, aggregate, enrich, train on, or otherwise exploit any data, user data, metadata, logs, telemetry, behavioral data, authentication data, transaction data, derived data, or findings obtained, generated, inferred, or accessed under this contract. Such information shall be used solely for performance of this contract and for no other purpose. The Contractor shall not use such information to train, tune, validate, improve, or enrich any artificial intelligence, machine learning, statistical, analytics, fraud detection, identity verification, risk scoring, or commercial model or service, whether owned by the contractor or any third party, without prior express written authorization.

3.2.14 The contractor shall provide an automated method to check if a user already has an account within their system using one or all of the following PII attributes: full name, phone number, and/or email address.

https://www.gsa.gov/system/files?file=SSL-TLS-Implementation-%5BCIO-IT-Security-14-69-Rev-7%5D-06-12-2023.pdf https://www.gsa.gov/system/files?file=SSL-TLS-Implementation-%5BCIO-IT-Security-14-69-Rev-7%5D-06-12-2023.pdf

3.2.15 The contractor shall design, implement, document, and maintain health check capabilities for all application programming interfaces, services, and supporting components delivered under this contract.

At a minimum, the contractor shall provide API health check endpoints that allow authorized government personnel and approved monitoring tools to determine the operational status, availability, and readiness of each API endpoint or service.

3.2.16 The product shall support major and minor releases for mobile, tablet, and desktop device operating systems (iOS, Android, iPadOS, Windows, Linux, macOS) released in the last 4 years. The product shall be updated to support new operating system versions within 90 days of release.

3.2.17 The product, if web-based, shall be compatible, performant, and reliable on desktop, tablet, and mobile browsers with more than a 1% browser share on analytics.usa.gov. The Product shall provide recommendations or suggest fallback options for users on unsupported browsers.

3.2.18 The contractor shall support a SSO Integration for the internal tooling/dashboard with GSA Auth.

3.2.19 The contractor may provide a risk signaling API to provide Login.gov with information about accounts that have been purchased by Login.gov and later closed or suspended due to fraud and other high-risk activity.

3.2.20 The contractor shall provide the names of the algorithm(s), software, and software version utilized during the creation of the IAL2 credential.

3.2.21 The contractor shall provide documented AAL2 and FAL2 assurance information necessary for Login.gov to evaluate inherited proofing eligibility, including assertion structure, assurance levels, authenticator type or category, account and authenticator status, authentication date/time, issuer, subject identifier, audience, expiration, and any events that may affect assurance, such as authenticator reset, account recovery, suspension, or fraud indicators.

3.2.22 The contractor shall support a process to ensure that any inherited credential is validated at or increased to the government-defined IAL2 level, as defined in NIST SP 800-63-4, before the credential is used to authenticate to Login.gov or any relying application.

3.2.23 The contractor shall implement a binding verification process to ensure that a user is strongly authenticated and bound to the external CSP account before that credential may be inherited and used for Login.gov authentication. This could be multi-factor authentication, biometric facial match comparison, or another government-approved authentication and identity binding method.

3.2.24 The contractor shall implement controls to detect and prevent continued use of an inherited credential when an associated account has been flagged as fraudulent by Login.gov. If a credential associated with a flagged fraudulent account is subsequently linked to another authentication account, the system shall identify the linkage and prevent the credential from being used unless and until it is reviewed and approved through an authorized remediation process.

3.2.25 The contractor shall implement a solution that enforces a policy of no more than one IAL2 credential per identity/SSN for any credential transmitted to Login.gov.

3.2.26 The contractor must have a reporting dashboard capable of displaying attribute frequency alerts, trend reports, and performance metrics based on behavioral biometrics signals. The dashboard shall clearly identify the proofing data (documents, selfies, PII, fraud signals, etc.) from credential creation and any additional data collected since creation for investigation purposes. The contractor shall work with the government to establish SSO for the dashboard.

3.2.27 The reporting dashboard shall display document and selfie images available for download.

3.2.28 The service must validate that all attributes collected from a legitimate applicant during the inherited credential process belong to the single resolved identity using issuing or authoritative sources.

3.3 Inherited Credential Co-Branding/User Experience

Development

To ensure that the integration of inherited credential services remains consistent with the established Login.gov user experience, the contractor must prioritize transparency, usability, and brand cohesion. The following requirements establish the standards for a co-branded implementation that seamlessly incorporates third-party verification into the broader identity journey while upholding federal branding guidelines and maintaining clear user communication throughout the process:

3.3.1 The contractor shall deliver a co-branded implementation that includes Login.gov branding within the user-facing workflow.

3.3.2 The contractor shall support any Login.gov redesign initiatives.

3.3.3 The contractor shall maintain consistent government branding and user experience throughout the inherited credential process.

3.3.4 Any user-facing interface that explains the inherited credential process must be reviewed and approved by the government and shall include edit options.

3.3.5 The contractor shall allow Login.gov to customize the look, feel, and user-facing content of all applicable user interface elements, including but not limited to colors, typography, logos, headings, body text, instructional text, error messages, buttons, links, form fields, labels, and other interactive elements.

The contractor shall document the customization process, including which elements are configurable, how changes are made, any limitations, and any required approvals prior to deployment.

3.3.6 The product shall allow all end-user-facing solutions to be served at a custom domain defined by Login.gov.

3.3.7 The product may comply with Section 508 and meet or exceed WCAG 2.1 A and AA for any internal-facing dashboard and products used by Login.gov employees. The contractor shall remediate any accessibility issues discovered by the government.

3.3.8 The product shall comply with Section 508, as described in the ICT Accessibility 508 Standards, and meet or exceed WCAG 2.1 AA for any end-user-facing experiences. The contractor shall provide an ACR/VPAT or other such artifacts documenting its ICT accessibility compliance and must remediate accessibility defects identified by the government according to an agreed remediation schedule.

3.3.9 The product shall support within the Login.gov system boundary, at a minimum, English, Spanish, French, and Simplified Chinese, and have the capability to add additional languages as needed by Login.gov.

https://www.access-board.gov/ict/ https://www.access-board.gov/ict/

3.3.10 The product shall allow (preferably in a self-service manner) Login.gov to customize all text (with support for special characters required for language localization) displayed to users and customize alt text readable by a screen reader.

3.3.11 The product shall allow (preferably in a self-service manner) Login.gov to customize the look and feel (such as colors, font, and logos) of all content displayed to the user, including selectable elements such as buttons or links. All elements shall follow USWDS 3.X guidelines and all successors.

3.3.12 The product shall be routinely tested with end users for usability, and the contractor shall provide artifacts from usability testing or other end-user research methods. This documentation shall be provided initially and upon request.

3.4 Inherited Credential Fraud Detection and Prevention

Support

To safeguard the integrity of the inherited credential workflow, the contractor shall proactively collaborate with Login.gov to identify, deter, and mitigate identity fraud. This effort involves continuous evaluation of risk signals from the contractor's system, alongside rigorous testing and documentation of prevention mechanisms. The following requirements outline the contractor’s responsibilities for maintaining a robust security posture and continuously enhancing fraud detection capabilities through data-driven insights and pilot testing:

3.4.1 The contractor shall collaborate on the development and testing of capabilities to deter and prevent identity fraud within the inherited credential workflow.

3.4.2 The contractor shall support evaluation of fraud signals and risk indicators from both contractor and Login.gov systems.

3.4.3 The contractor shall provide documentation of fraud prevention mechanisms and risk mitigation strategies.

3.4.4 The contractor shall recommend enhancements to their product’s fraud detection capabilities and ensure compliance with all fraud requirements under NIST SP 800-63A Section 3.2.

3.4.5 The contractor shall continuously evaluate fraud events, fraud trends, and identified vulnerabilities associated with its inherited credential solution to determine whether product updates, configuration changes, process improvements, or enhanced fraud detection controls are warranted. When fraud is identified, the contractor shall assess the relevant product https://designsystem.digital.gov/ functionality, identify potential root causes or control gaps, and recommend enhancements to remediate or reduce the likelihood of similar fraud in the future.

3.4.6 The contractor shall provide a fraud point of contact (POC) that will respond to fraud-related inquiries within 2 business hours for a high priority request and 8 business hours for a low priority request.

3.4.7 The contractor shall perform a fraud review of suspected fraud accounts upon request by Login.gov. If fraud is found, the contractor shall provide a report that will include but is not limited to: a summary of the mechanisms used to perpetrate the fraud, mitigation steps, relevant patterns or signals, or other relevant information.

3.4.8 The contractor shall inform Login.gov of any fraud incident, to include but not limited to: a list of the affected accounts, a summary of the incident, updated credential information, mitigation steps, proofing document images, and relevant patterns or signals. A fraud incident is defined as fraudulent account creations, account takeovers, or a cyber attack affecting 100 or more Login.gov-linked accounts in one 24-hour period.

3.4.9 The contractor shall notify the government when any contractor accounts linked to Login.gov accounts are identified or suspected as fraudulent. The government shall also be notified when accounts are unsuspended, and the contractor shall provide the results of the investigation.

3.5 Inherited Credential Identity Resolution and Attribute

Validation Login.gov resolves legitimate applicants to a single identity within a population, and validates that all attributes entered by an applicant match those of the resolved individual using an Identity Resolution and Attribute Validation (IRAV) Service. The inherited credential must be validated in a similar manner prior to Login.gov adoption. The intent of these requirements is to ensure that the Contractor possesses the necessary capabilities and performs appropriate monitoring, validation, and compliance checks. However, these capabilities and associated processes are expected to be internal to the CSP, unless otherwise specified.

The Government may request relevant information, documentation, reports, or evidence of compliance from the Contractor as needed. However, the Government does not require continuous or direct access to the underlying information, systems, or internal CSP processes unless explicitly stated elsewhere in the SOW.

3.5.1 The contractor must ensure that identity resolution and attribute validation requests include, at a minimum, data indicating whether the identity was resolved and the attributes were validated, along with detailed reason(s) for the determination.

3.5.2 The contractor must ensure that the identity resolution service can disclose its training and performance testing data, including population demographics and real-world evidence submitted through its system.

3.5.3 The contractor must ensure that the identity resolution service can validate the following attributes:

● The SSN provided is valid/exists

● The SSN provided matches the first and last name provided

● The full date of birth (DOB) provided is verified

● The DOB matches the SSN provided

● The SSN is not listed as deceased (Master Death File)

● If the SSN was issued before the DOB

● If the SSN is randomly issued

● If the SSN is associated with multiple individuals

3.5.4 The contractor must ensure that the identity resolution service has the capability to complete a synthetic identity check.

3.5.5 The contractor must ensure that the identity resolution service has the capability to identify fraud alerts and/or reports of fraud associated with the applicant’s identity.

3.5.6 The contractor must ensure that the identity resolution service has the capability to identify suspicious activity associated with the applicant’s PII elements.

3.5.7 The contractor must ensure that the identity resolution service performs checks against the U.S. Department of the Treasury's Office of Foreign Assets Control (OFAC) sanctions lists, including the Specially Designated Nationals (SDN) list and the Consolidated Sanctions List, to ensure that applicants are not prohibited individuals or entities. The service must integrate automated tools and data formats provided by OFAC (e.g., XML, CSV) to facilitate these checks within the identity proofing process.

3.6 Address Validation and Identity Verification

As part of identity proofing, Login.gov confirms an applicant’s address of record and, if possible, ties that record to an applicant using an Address Validation and Identity Verification Service. The inherited credential must be validated in a similar manner prior to Login.gov adoption. The address of record takes one of many forms and may include, but is not limited to: postal address, cellular phone, landline phone, and email address. The contractor must provide identity verification solutions that have the capability to meet the following address validation and identity verification requirements across all populations Login.gov serves. In cases where the postal address extracted from the identity document does not match the address input by the user during the account creation process, the address validation checks must be run against both addresses. The contractor shall meet most of the requirements:

3.6.1 The contractor must ensure that the address validation service accepts an applicant's address of record, as defined in NIST SP 800-63-4 and its successors, along with other identifying information.

3.6.2 The contractor must ensure that the address validation service validates that an applicant’s address of record matches the applicant's identifying information using issuing or authoritative sources.

3.6.3 The contractor must ensure that the address validation service validates that an applicant’s address of record matches the applicant via identity verification processes.

3.6.4 The contractor must ensure that the address validation service validates the following attributes regarding the applicant’s postal address:

● Zip code matches the state

● The applicant’s occupancy of the address

● Address is deliverable

● Identity/risk of address (non-residential/commercial property; institution

[prison, school, halfway house])

● Applicant last name matches the address

● Ownership of the property

● Applicant first and last name matches street address

● Applicant first and last name matches city and state

● Age of address, frequency of address use

3.6.5 The contractor must ensure that the address validation service validates and records the following attributes regarding the applicant’s phone:

● If the phone number is active with the applicant

● Phone’s service type (VoIP, prepaid, etc.) and carrier

● If the phone number was the origination phone used to spoof another phone number

● If SIM card information has changed in the last XX days

● when the phone number was first seen/first associated with the applicant

(age of phone)

● If the phone number is currently being forwarded

● If the primary subject associated with the phone number is deceased

● If the phone number has been ported (provide period of time)

● If the phone number has been spoofed within the past XX days

● If the phone number’s last seen date (last date associated with the applicant) is older than XX days

● If the phone number provided matches the name and address provided by the applicant

3.7 Behavioral Metrics

Login.gov requires the ability to monitor identities across multiple dimensions, such as time, geolocation, pattern of use, and attribute changes, for indicators of potential fraud and report them back as risk signals. The inherited credential must be validated in a similar manner prior to Login.gov adoption utilizing data points such as attributes listed at https://developers.login.gov/attributes/, device fingerprints, IP addresses, etc. The requirements below must be applied during both the first-time registration of unknown individuals/entities (such as devices) and authentication for previously known individuals/entities. The contractor shall meet most of the requirements:

3.7.1 The contractor must be able to identify potential fraud during registration of previously known individuals.

3.7.2 The contractor must be able to identify potential fraud during authentication of previously known individuals.

3.7.3 The contractor must be able to identify potential fraud during account management actions of previously known individuals.

3.7.4 The contractor must be able to identify and provide device hardware information, including but not limited to the device’s make, model, chip manufacturer, age, etc.

3.7.5 The contractor must be able to identify and provide the device’s software specifications, including, but not limited to, the device’s operating system, browser data, JavaScript, SDK information, version numbers, etc.

3.7.6 The contractor must be able to identify and provide a comprehensive set of device configuration details for each session, including, but not limited to, the device’s time zone or location, phone settings for time zone or location (clock configuration), system default language, browser default language, keyboard configuration, and screen resolution. At a minimum, the contractor must capture and return attributes such as user agent, browser or system languages, color depth, screen resolution, time zone, availability of session storage, availability of local storage, availability of IndexedDB, support for IE-specific AddBehavior, availability of Open Database (OpenDB), CPU class, platform, DoNotTrack setting, a comprehensive font inventory with order preservation, high-entropy font detection without external plugins, canvas fingerprinting results, WebGL fingerprinting results, browser plugins (including IE), ad-block detection status, and indicators of tampering with languages, screen resolution, or the operating system. The contractor must provide this information in a structured, machine-readable format.

https://developers.login.gov/attributes/

For example, when returning information about detected fonts, the contractor may utilize a JSON object that lists all fonts and performance metrics, such as:

{"fonts": {"value": ["Arial Unicode MS", "Gill Sans", "Helvetica Neue"], "duration":

89}}

3.7.7 The contractor must be able to identify and provide network data, including, but not limited to:

IP address(es) (input, true, proxy, DNS) IP address Internet service provider IP address organization IP address connection type IP address geolocation (city, state, region, country, latitude, longitude) IP address risk score/reputation/prevalence TOR usage VPN, proxy, and private browsing detection

3.7.8 The contractor must be able to identify geolocation travel between events (‘impossible travel’).

3.7.9 The contractor must employ device fingerprinting capabilities, including but not limited to detecting instrumentation (e.g., Frida), factory reset timestamps, location spoofing, cloned apps, emulators, rooted or jailbroken devices, browser details, IP attributes, proxy and VPN usage, and anomalies such as tampering or anti-detection browsers.

3.7.10 The contractor must have the capability to analyze and report on session timing and interaction counts, including, but not limited to, time spent on each page, time between user actions (e.g., clicks, scrolls, or keystrokes), inactivity periods, and patterns of interaction (e.g., sequential vs. erratic behavior) to identify behavioral anomalies and potential fraud indicators.

3.7.11 The contractor must be able to identify when pasted inputs are utilized.

3.7.12 The contractor must have the capability to analyze mouse movements and flag abnormal or machine-like behavior.

3.7.13 The contractor must have the capability to analyze the speed of keystrokes.

3.7.14 The contractor must have the ability to identify device gyroscopic orientation and flag abnormal behavior.

3.7.15 The contractor must have the capability to identify patterns among behavioral biometric attributes. Examples include, but are not limited to: number of emails per device, number of addresses per email address, number of accounts per address, velocity of a device within distinct time periods, etc.

3.7.16 The contractor must have the capability to build, amend, and apply customized rules to production data in real-time (specific behavioral biometrics/device behavior).

3.7.17 The contractor may have the capability to provide a historical association of the user’s digital footprint, producing a trust and/or risk score of the user’s digital identity.

3.7.18 The contractor must have the capability to detect bot behavior or indicators.

3.7.19 The contractor may have the capability to detect device anomalies including but not limited to: malware, device emulation, rooted devices, remote control, browser tampering, etc.

3.7.20 The contractor must have an AI/ML capability to flag suspicious behavior or patterns based on preponderance of behavioral biometrics inputs.

3.7.22 The contractor may have the capability to perform link analysis visualization across the user base based on behavioral biometric inputs (IP, device, etc.).

3.7.23 The contractor must have the capability to perform attribute-related velocity checks to flag whether identity attributes (either as individual elements or as a collection) have high rates of recent search activity or recent usage across global systems.

3.8 Additional Fraud Capabilities

3.8.1 The contractor must be able to identify email domain information, including whether the email domain is disposable, its reputation, and its popularity. The contractor must also identify the following email handle information: association with user; age/creation date; reputation; syntax (floating dots, gibberish, enumeration, known patterns, etc.); and whether it is auto-generated.

3.8.2 The contractor must have generative AI/ML capability to recognize and flag suspicious email patterns (n-grams, gibberish, enumeration, domain, etc.) and prevent email domain spoofing attacks.

3.8.3 The contractor must have an internal risk decisioning/rules engine capable of leveraging algorithms and machine learning techniques to integrate and analyze extensive datasets.

4.0 Security

The assessment and authorization of the contractor's identity verification solution will depend on the type of data being transmitted to the system, the length of time the data is stored within the system, and other factors identified by GSA IT security officials. Contractors will be required to be FedRAMP Moderate.

The contractor is responsible for providing all necessary documentation and resources to manage and comply with the IT security assessment and usage authorization of its solution.

Additional information on the process surrounding assessments and authorization of IT systems can be found in the GSA IT Security Procedural Guide: Security and Privacy Requirements for IT Acquisition Efforts CIO-IT Security-09-48. GSA may choose to cancel the BPA and terminate any outstanding orders if FedRAMP authorization (Joint Authorization Board [JAB] Provisional or Agency) is revoked and the deficiencies exceed agency risk tolerance thresholds.

The contractor shall comply with all of the following security requirements:

4.1 Common Requirements for All Deployment Options

4.1.1 The contractor (and/or any subcontractor) shall comply with GSA IT Security Procedural Guide: Security and Privacy Requirements for IT Acquisition Efforts CIO-IT Security-09-48.

4.1.2 Cloud computing products and services (such as Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS)) that create, collect, process, store, or maintain Federal information on behalf of GSA are required to be FedRAMP authorized.

If a contractor is an "Agency in Process," it shall achieve full FedRAMP Moderate (or equivalent) authorization within 6 months of contract award.

4.1.3 The contractor shall implement the controls contained within the FedRAMP Cloud Computing Security Requirements Baseline and FedRAMP Continuous Monitoring Requirements for Moderate (or equivalent) impact systems (as defined in FIPS PUB 199). These documents define requirements to meet minimum federal information security and privacy requirements for Moderate (or equivalent) impact systems. The FedRAMP baseline controls are based on NIST Special Publication 800-53, Revision 4, “Security and Privacy Controls for Federal Information Systems and Organizations,” and include a set of additional controls for use within systems providing cloud services to the federal government.

4.1.4 GSA may choose to cancel the contract and terminate any outstanding orders if the contractor has its FedRAMP authorization revoked and the deficiencies are greater than GSA risk tolerance thresholds.

4.1.5 GSA will leverage the CSP’s FedRAMP Assessment and Authorization package to document and assess the Customer Responsibility Matrix (CRM) controls for which GSA has responsibility for the agency’s instance of the https://www.gsa.gov/system/files?file=Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev8%5D-10-14-2024.pdf https://www.gsa.gov/system/files?file=Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev8%5D-10-14-2024.pdf https://www.gsa.gov/system/files/Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev9%5D-1-15-2025.pdf https://www.gsa.gov/system/files/Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev9%5D-1-15-2025.pdf https://www.gsa.gov/system/files/Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev9%5D-1-15-2025.pdf

CSP’s SaaS or PaaS offering. The CSP shall support GSA’s Leveraged FedRAMP assessment and authorization process of CRM controls as specified in CIO-IT Security-06-30: Managing Enterprise Cybersecurity Risk, as necessary.

4.1.6 Maintenance of the FedRAMP Authorization will be through continuous monitoring and periodic audit of the operational controls within a contractor’s system, environment, and processes to determine if the security controls in the information system continue to be effective over time in light of changes that occur in the system and environment. Through continuous monitoring, security controls and supporting deliverables are updated in agreement with FedRAMP guidelines and submitted to the Connect.gov Portal or repository designated by the FedRAMP program.

4.1.7 The submitted deliverables (or lack thereof) provide a current understanding of the security state and risk posture of the information systems. The deliverables will allow the Federal Departments/Agencies leveraging the services providers’ cloud offering to make credible risk-based decisions regarding the continued operations of the information systems and initiate appropriate responses as needed when changes occur. Contractors will be required to provide updated deliverables and automated data feeds as defined in the FedRAMP Continuous Monitoring Plan.

4.1.8 Controlled Unclassified Information (CUI), data, and/or equipment will only be disclosed to authorized personnel on a need-to-know basis. The contractor shall ensure that appropriate administrative, technical, and physical safeguards are established to ensure the security and confidentiality of this information, data, and/or equipment is properly protected. When no longer required, this information, data, and/or equipment will be returned to government control, destroyed, or held until otherwise directed. Destruction of items shall be accomplished by following NIST Special Publication 800-88, Revision 1, “Guidelines for Media Sanitization.” The destruction, purging, or clearing of media specific to the CSP will be recorded and supplied upon request of the government.

4.1.9 The contractor shall provide a Cyber-Supply Chain Risk Management (C-SCRM) Plan 60 days after award and biennially thereafter. See GSA C-SCRM Plan template.

The contractor must participate in GSA’s C-SCRM Program, including maintenance of a SCRM Plan and monitoring via third-party vendor risk illumination tools (e.g., Interos and BitSight).

4.1.10 Account management systems must leverage or integrate with existing GSA account management solutions or processes, as applicable and defined in the GSA IT ICAM Roadmap (see GSA Order CIO 2183.1, “Enterprise Identity, Credential, and Access Management (ICAM) Policy”).

The service’s and contractor’s federated authentication solution shall support SAML 2.0 and/or OpenID Connect integrations. OpenID Connect is the preferred protocol for GSA Auth.

The service and contractor shall support SCIM protocol or publish a RESTful API for GSA to create and manage GSA and customer agency end user accounts. This includes creation, assignment of roles, and termination.

4.1.11 All remote access from internal users/systems to the external information system must be routed through GSA’s managed network access control points, subjecting it to security monitoring.

4.1.12 OMB M-21-07 Completing the Transition to Internet Protocol Version 6 (IPv6)

A description of how the system will transition to IPv6, as required by OMB M-21-07, must be included as part of the system’s SSPP.

IPv6 applies to this acquisition. Reference NIST SP 500-267 and NIST SP 500-281 for additional guidance on IPv6 requirements. A Supplier’s Declaration of Conformity (SDOC) is required, as outlined in the two previous NIST documents. The template for the SDOC can be found at the following URL:

https://www.nist.gov/publications/usgv6-profile-suppliers-declaration-conform ity

4.1.13 FIPS PUB 199 Moderate and High impact systems must implement processing across geographically disparate locations to ensure fault tolerance. Cloud Infrastructure-as-a-Service (IaaS) architectures shall implement a multi-region strategy (multiple availability zones in a single region are not sufficient).

4.1.14 Implemented encryption algorithms and cryptographic modules shall be FIPS-approved and FIPS PUB 140-3 validated, respectively.**

● Digital signature encryption algorithms

● Block cipher encryption algorithms

● Secure hashing algorithms

For web services connections, implement end-to-end encryption terminating the connection at the web server; connections terminated at a load balancer, firewall, and/or WAF shall employ re-encryption techniques to ensure end-to-end encryption.

All associated URLs must have their second-level domain HTTP Strict Transport Security (HSTS) preloaded and have no weak ciphers, have no weak protocols, and preload .gov domains. (see Binding Operational Directive (BOD) 18-01, Enhance Email and Web Security).

SSL/TLS implementations shall align with GSA IT Security Procedural Guide 14-69: SSL/TLS Implementation.

**Federal Policy requires implementation of FIPS PUB 140-3/140-2 validated encryption modules and FIPS-approved cipher suites. Encryption of GSA sensitive data (e.g., PII, PCI, authenticators, other business-sensitive data) at rest and in transit shall be performed with FIPS-validated encryption modules wherever possible; exceptions require an Acceptance of Risk (AOR) signed by the GSA CISO and AO.

4.1.15 The service and contractor shall support OAuth 2.0 or mutual certificate authentication for non-user account access. See GSA IT Application Programming Interface (API) Security CIO-IT Security-19-93.

4.2 Deployment: Mobile Applications and Mobile Code

For any mobile applications and client-side mobile code:

4.2.1 The contractor shall deliver a secure software self-attestation form as specified in OMB M-26-05, Adopting a Risk-based Approach to Software and Hardware Security, using the most recent self-attestation common form.

4.2.2 The contractor shall provide either:

● Mechanisms to validate the integrity of mobile applications and client-side mobile code or

● The ability for GSA to self-host such code.

4.2.3 If any application is developed for or on behalf of GSA, the contractor (and/or any subcontractor) shall meet the requirements identified in Section 6:

https://insite.gsa.gov/system/files/SSL-TLS-Implementation-%5BCIO-IT-Security-14-69-Rev-7%5D-06-12-2023.pdf https://insite.gsa.gov/system/files/SSL-TLS-Implementation-%5BCIO-IT-Security-14-69-Rev-7%5D-06-12-2023.pdf https://insite.gsa.gov/system/files/Application-Programing-Interface-%28API%29-Security-%5BCIO-IT-Security-19-93-Rev-2%5D.pdf https://insite.gsa.gov/system/files/Application-Programing-Interface-%28API%29-Security-%5BCIO-IT-Security-19-93-Rev-2%5D.pdf https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf https://www.whitehouse.gov/wp-content/uploads/2026/01/M-26-05-Adopting-a-Risk-based-Approach-to-Software-and-Hardware-Security.pdf

Mobile Application - IT Security and Privacy Requirements in GSA IT Security Procedural Guide: Security and Privacy Requirements for IT Acquisition Efforts CIO-IT Security-09-48.

4.2.4 Systems must adhere to GSA's requirements regarding IT Standards, CIO-IT Security-07-35: Web Application Security, and CIO-IT Security-17-81: Web Browser Technologies Hardening, as applicable, to ensure only approved code (including mobile code) is used.

5.0 Privacy

Login.gov is committed to preserving end-user privacy and protecting user data. The contractor shall provide all necessary information, documentation, and resources to ensure that its identity verification products and services comply with all applicable federal privacy laws, regulations, and GSA policies. The contractor shall comply with the following privacy requirements.

5.1 The contractor shall work with the COR, a GSA Privacy Analyst, and Login.gov staff on all privacy-related matters. These matters include, but are not limited to, identifying, evaluating, and determining how to mitigate privacy-related risks; creating and maintaining privacy-related documentation; and inspecting the service to ensure adherence to any privacy-related rules.

5.2 The contractor shall provide a draft Privacy Impact Assessment (PIA) within 14 days of a BPA call order award.

5.3 The contractor shall work with a GSA Privacy Analyst and Login.gov to finalize the Privacy Impact Assessment within 28 days of a BPA call order award. The contractor shall work with a GSA Privacy Analyst and Login.gov to maintain the Privacy Impact Assessment throughout the life of the call order.

5.4 The contractor shall provide a table of data (i.e., Data Table) collected by the service, descriptions of each data field, and how each data field is used to provide the service within 28 days of BPA call order award.

5.5 The contractor shall open their systems for inspection by GSA or a 3rd party to ensure compliance with all data policies within 5 business days of any request. GSA may perform up to one yearly audit, and additional audits after any security or privacy incident. The contractor shall provide support for each audit.

https://www.gsa.gov/system/files/Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev9%5D-1-15-2025.pdf https://www.gsa.gov/system/files/Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev9%5D-1-15-2025.pdf https://www.gsa.gov/system/files/Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev9%5D-1-15-2025.pdf

5.6 The services and contractor must comply with data collection, retention, and privacy policies as specified by Login.gov.

5.7 Data cannot be retained or shared, either as individual data or in aggregate, even if that data is anonymized, except (subject to the contracting officer’s prior approval in each case) as necessary to provide the solution in accordance with this contract, or as necessary to comply with the law or a valid and binding order of a governmental or regulatory body (such as a subpoena or court order). Unless it would be in violation of a court order or other legal requirement, the vendor will give the Government reasonable notice of any such legal requirement or order, to allow the Government to seek a protective order or other appropriate remedy.

5.8 The contractor shall not use data provided by Login.gov to enrich this or other services. Likewise, no indirect enrichment or creation of new relationships with existing vendor data is allowable.

5.9 The service provider and contractor shall apply these same policies to any upstream services (e.g., services used for document or core attribute verification).

The service provider shall provide details of all external services utilized to provide the service, including the nature of usage, data transmitted and received, and information received from the service.

All external services processing GSA CUI data, including device data and derivative data, will require evaluation by GSA.

5.10 All privacy requirements outlined in GSA IT Security Procedural Guide:

Security and Privacy Requirements for IT Acquisition Efforts CIO-IT Security-09-48 shall apply to the solution.

5.11 Personally Identifiable Information (PII) is in scope for this acquisition and is expected to be stored in the vendor's cloud solution. The vendor shall prepare a Privacy Threshold Assessment (PTA) to document whether PII is in scope or to determine which categories of information will be stored, processed, or transmitted by the system, which must be provided to the GSA Privacy Office for review. The use of any information that is subject to the Privacy Act will be in full accordance with all rules of conduct applicable to Privacy Act Information.

PII (should it come into scope) will require adherence to the following guidelines:

https://www.gsa.gov/system/files/Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev9%5D-1-15-2025.pdf https://www.gsa.gov/system/files/Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev9%5D-1-15-2025.pdf https://www.gsa.gov/system/files/Security-and-Privacy-Requirements-for-IT-Acquisition-Efforts-%5BCIO-IT-Security-09-48-Rev9%5D-1-15-2025.pdf

● The vendor’s information system must be authorized at least at the FIPS PUB 199 Moderate level.

● For any system that collects, maintains, or disseminates PII, a Privacy Impact Assessment (PIA) must be completed by the contractor and provided to the GSA Privacy Office for review along with other Authorization to Operate (ATO) documents.

● If the system retrieves information using PII, the Privacy Act applies, and a System of Records Notice (SORN) must be published in the Federal Register.

● If PII is collected from individuals by the system, a Privacy Act Statement (i.e., Privacy Notice) must be provided to users prior to their use of the application on what data is being collected and why, as well as the authority for the collection and the impact of not providing some or all of it. The Privacy Act Statement must be available to the individual directly on the form used to collect the information. Providing a link back to the Statement from the form is acceptable.

5.12 The contractor shall be responsible for properly protecting all information used,…