OMB's recent memo gives you two years to integrate Login.gov on public-facing websites with user authentication. However, it doesn't ban commercial credential service providers outright. You're facing a decision: when should you rely on Login.gov as your primary solution, and when should you justify keeping or adding a commercial provider like ID.me or CLEAR?
Here's how to make that choice using compliance timelines and risk factors that matter.
The Decision You're Facing
Your agency must offer Login.gov as a sign-on option for in-scope public-facing websites within two years. The memo states Login.gov should be "the default option for new account creation for any user population that Login.gov is able to serve." However, you can maintain or introduce other authentication solutions if they meet specific use cases Login.gov can't handle, or if removing them would burden a significant user population.
This creates a decision tree. You're not choosing Login.gov or a commercial provider in most cases. You're deciding which one to prioritize, when to justify dual options, and how to phase out solutions that no longer meet the memo's criteria.
Key Factors That Affect Your Choice
User population characteristics. If your website serves a population that already relies heavily on an existing commercial provider, OMB allows you to avoid "imposing additional burden" by maintaining that option. You'll need to track active user volume and justify continued use during routine reevaluations.
Identity assurance requirements. Login.gov has faced scrutiny over whether it meets NIST's Identity Assurance Level 2 standard. A March 2023 GSA Inspector General report found that agency officials had misled customer agencies by claiming Login.gov met IAL2 when it did not. GSA committed to adding facial recognition capabilities to meet that standard, but you should verify Login.gov's current assurance level against your system's risk assessment.
Operational and technical gaps. The memo allows other solutions when Login.gov "is unable to fully meet" a particular use case. This could include specialized authentication workflows, integration constraints with legacy systems, or user populations with accessibility needs Login.gov doesn't yet address.
Fraud and security posture. A July GAO report noted that GSA still needs to address fraud threats and technical issues in Login.gov. If your digital identity risk assessment reveals fraud patterns or attack vectors that a commercial provider mitigates more effectively, document that gap as part of your justification for dual offerings.
Mission exemptions. If you're in the Defense Department, intelligence community, or managing national security systems, you're not required to deploy Login.gov. OMB encourages DoD to offer it "to the extent practicable" for public-facing sites, but you retain discretion.
Path A: Login.gov as Primary (or Sole) Provider
Choose this path when:
- Your website serves a general public user base without specialized authentication needs.
- Login.gov's current capabilities meet your digital identity risk assessment requirements.
- You're launching a new public-facing service and don't have an entrenched user population on another platform.
- Your user metrics show low adoption of any existing commercial provider.
- You want to minimize vendor management overhead and align with the memo's default guidance.
Implementation steps:
Within 60 days, submit your list of public-facing websites with user authentication to OMB. Within 240 days, complete a digital identity risk assessment using the resource NIST will publish within 120 days of the memo. Within one year, adopt the practices guide GSA will publish within 180 days. Set Login.gov as the default option for new account creation and phase out any commercial providers that don't meet the "specific use case" or "significant user burden" exceptions.
What you gain: You align fully with OMB's stated preference, simplify your identity provider landscape, and avoid the complexity of maintaining multiple credential service providers. GSA implemented a new, lower-cost pricing model in July, which may reduce your operational costs compared to commercial alternatives.
What you risk: If Login.gov experiences outages, fraud incidents, or fails to meet your assurance requirements, you don't have a fallback without re-justifying and re-procuring a commercial solution. Track GSA's ongoing work to strengthen anti-fraud safeguards and address the technical issues GAO flagged.
Path B: Login.gov + Commercial Provider (Dual Offering)
Choose this path when:
- You have a significant existing user base on a commercial provider (e.g., Medicare.gov's dual Login.gov and ID.me model).
- Your digital identity risk assessment identifies use cases Login.gov cannot fully meet.
- Your user population includes groups with specialized accessibility or authentication needs.
- You operate in a high-fraud environment and need commercial provider capabilities GSA hasn't yet deployed.
- You're managing a transition period and need to avoid service disruption.
Implementation steps:
Deploy Login.gov as required, but document the specific operational requirement or user burden that justifies maintaining the commercial option. "Routinely reevaluate" the need by tracking active user volume on each platform. Promote Login.gov as the default for new accounts. If active use of the commercial provider drops significantly, prepare to phase it out.
What you gain: You maintain continuity for existing users, address capability gaps Login.gov hasn't closed, and retain flexibility during the two-year transition. You can shift users toward Login.gov gradually rather than forcing a hard cutover.
What you risk: You carry the overhead of managing two identity providers, including separate privacy impact assessments, security monitoring, and vendor relationships. You'll need to justify continued use during OMB reviews and demonstrate that Login.gov truly can't serve the population relying on the commercial option.
Path C: Commercial Provider Only (Exemption or Waiver)
Choose this path when:
- You qualify for the Defense Department, intelligence community, or national security system exemption.
- Your mission requirements demand capabilities Login.gov will not develop (e.g., classified system integration, specialized biometric modalities).
- You can document that Login.gov fundamentally cannot meet your operational or security requirements.
Implementation steps:
If you're exempt, document your rationale and proceed with your existing or planned commercial solution. If you're not exempt but believe Login.gov cannot meet your requirements, prepare a detailed justification citing specific NIST controls, assurance levels, or operational constraints. Expect OMB scrutiny.
What you gain: You maintain full control over your identity verification approach and can tailor it to mission-specific needs.
What you risk: You operate outside OMB's stated direction and may face pressure to adopt Login.gov in future policy updates. You'll need airtight documentation if auditors or oversight bodies question your decision.
Summary Matrix
| Factor | Login.gov Primary | Dual Offering | Commercial Only |
|---|---|---|---|
| Best for | New services, general public | Transition periods, specialized needs | Exempt missions, classified systems |
| Compliance alignment | Full alignment with memo | Justified exception | Requires exemption or waiver |
| User burden | Low for new users | Managed for existing users | Depends on population |
| Operational complexity | Single provider | Dual provider overhead | Single provider |
| Fraud/security gaps | Depends on GSA improvements | Mitigated by commercial option | Depends on provider |
| Cost | GSA's new lower-cost model | Dual licensing/contracts | Commercial pricing |
Your 60-day deadline to submit your website list to OMB is the starting point. Use that inventory to map which sites have entrenched commercial provider user bases, which face specialized authentication requirements, and which can adopt Login.gov as the sole option without disruption. Your digital identity risk assessment at 240 days will determine whether Login.gov's current capabilities meet your assurance requirements or whether you need to document gaps that justify a commercial provider.
The memo doesn't force a binary choice. It forces you to justify any path that isn't Login.gov as the default. Build that justification on documented user metrics, operational requirements, and security gaps you can verify.
