REQUEST FOR INFORMATION (RFI)

General Services Administration (GSA)

Federal Acquisition Service (FAS)

Technology Transformation Services (TTS)

Login.gov Inherited Credential Requirement

1.0Purpose

The purpose of this RFI is to identify vendors offering inherited credentials that are potentially suitable for Login.gov's needs, and to obtain industry feedback on draft requirements and other considerations.

Important Information:

Not a Solicitation: This RFI is only a notice, not a request for an offer or proposals. This RFI is issued only for information and planning purposes and does not constitute a solicitation.

Information received will be used to determine the availability of technically capable and otherwise responsible firms. Responses to this notice are not offers and cannot be accepted by the Government to form a binding contract.

No Commitment: This notice does not represent a commitment by the Government to issue a solicitation or award a contract related to this notice. The release of this RFI should not be construed as such a commitment or as authorization to incur cost for which reimbursement would be required or sought. The information provided in the RFI is subject to change and is not binding on the government nor does it restrict the government as to the ultimate acquisition approach.

Future Participation: Not responding to this RFI does not preclude participation in any potential future Request for Proposals/Quotations (RFP/RFQ), if any is issued.

Information Handling: Any information submitted by respondents to this RFI is strictly voluntary.

All submissions will become Government property and will not be returned. Interested vendors are responsible for adequately marking proprietary, restricted or competition sensitive information contained in their response, which shall be clearly marked on every page that contains such.

Potential Exchanges: GSA is under no obligation to respond or provide feedback to any respondents to this RFI, or to contact respondents for clarification of any information submitted in response to this RFI. However, the Government may choose to correspond or meet with potential RFI respondents. If conducted, these exchanges would only be intended to get further clarification of potential solutions and/or to discuss potential innovations/modernization to the Government’s requirements.

2.0Background The General Services Administration (GSA), Technology Transformation Services (TTS) applies modern methodologies and technologies to improve the public's experience with government by helping agencies make their services more accessible, efficient, and effective.

TTS builds, provides, and shares technology applications, platforms, processes, personnel, and software solutions with federal agencies to help them better serve the public.

As part of GSA TTS, Login.gov provides secure authentication and identity verification services to federal agencies and the public. Many federal services require users to complete identity proofing at Identity Assurance Level 2 (IAL2) or similar assurance levels before accessing sensitive benefits, health, financial, or personal information. Login.gov requires a capability to evaluate and potentially integrate third-party IAL2-verified identity information into the Login.gov identity proofing workflow via inherited credential. Traditional identity proofing can be time-consuming, costly, and burdensome for users. Users are required to submit identity documents, provide personal information, complete biometric, complete document checks, verify addresses, and potentially participate in in-person proofing. These steps may create friction, increase abandonment, and impose additional burden on individuals who have already completed high-assurance identity verification with a trusted provider. Login.gov is therefore exploring the following:

1. Inherited credential as a strategic identity modernization capability. Under this model, a user who has previously completed a qualifying identity proofing event with a trusted credential service provider (CSP) may be able to leverage that prior verification when accessing Login.gov-enabled federal services.

3.0Draft Requirements The attached draft requirements (Attachment 1) detail the Government's contemplated needs for inherited credentials. They should not be considered final and are subject to change.

Interested parties are encouraged to provide feedback on the draft requirements so they may be further refined. The Government reserves the right to incorporate or omit any feedback provided by industry in any potential future distribution of these requirements.

4.0Requested Information Interested parties who are CSPs and believe they can provide suitable inherited identity credentials should provide the information below.

4.1Company information

● Company name

● Company address and website

● Company point of contact (name, title, email, phone)

● SAM Unique Entity Identifier (UEI)

● CAGE Code (if applicable)

● Business size and any socioeconomic designation(s)

● List any GSA MAS contracts, GWACs, or other governmentwide contract vehicles your company or a reseller/partner holds, including contract numbers and applicable SINs.

4.2Experience Provide details of your experience delivering identity verification and inherited credential, solutions, including but not limited to:

● Experience providing similar capabilities at scale, including relevant experience with high-volume public sector, financial services, identity provider, or fraud-prevention customers.

● Relevant Government past performance, including contract award numbers.

4.3Scope The Government is conducting market research on inherited identity credentials. For the purposes of this market research, the Government's interest is in an inherited credential solution that is integrated within the Login.gov platform and fully co-branded with Login.gov.

4.4Capability

● Can your solution provide inherited credentials as a standalone capability without requiring procurement or deployment of a broader platform or orchestration suite?

Identify the minimum required components and any optional components.

● Can your solution be integrated into an existing infrastructure as a targeted component, delivering device identifiers and risk indicators into a customer's existing workflows and systems without requiring use of a native engine or broader platform? Describe your integration model and any conditions or dependencies.

● Describe your solution's ability to meet the draft identity credential requirements in Attachment 1. Identify any requirements you can fully meet, partially meet, or cannot meet, and explain any conditions, limitations, or alternative approaches. Attachment 1 contains several areas requesting statements of the solution's capability; ensure your response provides your solution’s capability for each item.

● For the capabilities in Attachment 1, indicate which are currently available, planned/on your roadmap, or not supported, and note any differences across web, iOS, Android, and agentic/autonomous-agent detection.

● Describe your solution’s typical latency for device identification and risk-signal return under high-volume production conditions. Indicate what request volumes and peak conditions you consider high-volume, and describe your ability to support sustained high-volume and seasonal peak traffic without rate limiting.

● Provide information on your current reproofing requirements. Login.gov requires reproofing at 5 years, and it would be useful if, after the proof date, that Login.gov is able to allow users to re-inherit, assuming they have a refreshed proof at the CSP.

● There are many ways to meet IAL2 requirements (trusted referees, biometrics, non-biometric pathways, trusted referees). Please outline the requirements you utilize to validate at an IAL2 level. How do you verify IAL2 identities in accordance with NIST standards?

● How many users do you currently have that are proofed at an IAL2 or higher level?

● What is your current brand recognition to include commercially available solutions, market presence, adoption, product maturity, and proven implementation experience?

● What are your current fraud detection and prevention tactics you use in your solutions?

● 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.

Does the solution meet these standards and would the contractor be willing to provide artifacts that show them meeting the standards?

● Do you have standard SLAs for software updates based on potential fraud vectors?

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

4.5FedRAMP/Security/Data

● For each event describe what information is generated, what is returned to the customer, and what your solution retains, including where and for how long by default.

Can this setting be changed?

● Login.gov is requiring FedRAMP moderate for this requirement. Identify any security or compliance certifications or authorizations relevant to federal deployment that your solution holds including status and scope and when it will reach FedRAMP Moderate status.

● Login.gov is requiring Kantara Trust Mark in good standing for this requirement, Identify any security certifications or compliance standards relevant to federal deployment that your solution holds including status and scope.

4.6Pricing

● Login.gov anticipates that a FFP implementation and maintenance CLIN will be included. What costs are associated with implementation, integration, support, maintenance, and upgrades?

● For inherited credentials, Login.gov is anticipating the billing for this contract will be done on a passed transaction basis. For example, a user selects they have a proofed account and their information is sent to the contractor. The contractor verifies their account is valid and would be paid for a valid transaction. If the information comes back as invalid or not confirmed the Government would not pay for that transaction. Please provide an anticipated unit cost or provide a range for unit costs based on this strategy.

● Are there any other pricing strategies the Government should consider?

4.7Feedback

● Identify any assumptions, dependencies, data inputs, feedback loops, or data-sharing requirements not otherwise addressed in this RFI that are necessary for the proposed solution to perform as described.

● Provide feedback on Attachment 1, including any requirements you believe are unnecessary, over-specified, unclear, or better stated differently. Where applicable, provide suggested alternatives or revisions.

● Recommend any evaluation factors or discriminators the Government should consider for a future solicitation.

● Identify any additional information, considerations, or dependencies that must be known for a successful implementation, or that may materially affect pricing structure, cost drivers, schedule, or performance.

● What are the most common implementation challenges?

● What best practices do you recommend for inherited credential?

● What emerging technologies or trends should the agency consider?

5.0 Submission Instructions

Respondents shall include the information specified in the subsections of Section 4.0 Requested Information.

Description Response Requirement Due date for RFI responses

All RFI responses are due no later than 5:00 PM ET, October 15, 2026. RFI responses received after the due date may not be reviewed or considered.

Response format

Capability statements shall be submitted in a PDF or Word document format, using no less than ten (10) point font character size, and no less than a 3/4" around each page for margins. Tables and figures shall use no smaller than ten

(10) point character size and must be clear and readable.

The capability statements provided by RFI respondents shall not exceed fifteen

(20) pages in length, excluding the cover page, any data flow diagrams, and sample event outputs. The Government may not review or consider any information that is provided in excess of aforementioned page limitation.

How to respond? Submit RFI responses electronically via email to jonah.jordan@gsa.gov, lindsey.mitchell@gsa.gov, and ruchi.tekriwal@gsa.gov. All responses should include a cover page with the respondent’s contact information.

mailto:SubmitRFIresponseselectronicallyviaemailatjonah.jordan@gsa.govand mailto:SubmitRFIresponseselectronicallyviaemailatjonah.jordan@gsa.govand mailto:SubmitRFIresponseselectronicallyviaemailatjonah.jordan@gsa.govand mailto:dustin.spiehler@gsa.gov.TheemailsubjectlineshouldincludeRFInumber