Login.gov: Federal Identity for Public-Facing Services

Somewhere in the long catalog of things citizens are quietly grateful not to think about is the question of how, exactly, the federal government decides that the person typing into a Social Security form is the person they claim to be. The answer, increasingly, is a single sign-on service called Login.gov, run not by the agency on the other end of the form but by a small division of the General Services Administration. It is, on close inspection, a slightly unusual arrangement: one agency holding the front door key for many others.

What Login.gov actually is

Login.gov is a shared authentication and identity verification service operated by the Technology Transformation Services (TTS) inside GSA. Rather than each federal agency building, maintaining, and securing its own login system, an agency can hand that responsibility off to Login.gov and accept the resulting authenticated session. From the citizen's perspective, the experience is mundane and slightly familiar — an email address, a password, a second factor — which is roughly the point.

The service lives at login.gov and is part of the broader portfolio of TTS products that includes cloud.gov, 18F, and USA.gov. TTS sits within GSA's Federal Acquisition Service, which is an organizational placement that surprises people the first time they encounter it. Identity verification, as a function, has rather little to do with acquisition in the procurement sense. The placement is historical: TTS grew out of digital service work that GSA was already doing, and GSA was already in the business of providing shared services to the rest of government. Identity simply became another shared service, alongside per diem rates and the federal fleet.

The standard everything is built on: NIST 800-63

The technical spine of Login.gov is the NIST Special Publication 800-63 series, the federal Digital Identity Guidelines. The 800-63 framework is, depending on one's tolerance for taxonomies, either elegant or maddening. It separates the question of "who is this person" from the question of "is this the same person who signed up before," and assigns each its own ladder of assurance levels.

Identity Assurance Level (IAL) describes how confidently a real-world identity has been verified. IAL1 means no identity proofing is required; the user could be anyone. IAL2 means the user's identity has been verified against authoritative evidence — typically a government-issued photo ID and some corroborating data. IAL3 adds in-person or supervised remote proofing and is rare in civilian-facing services.

Authenticator Assurance Level (AAL) describes how confidently the person logging in today is the same person who registered. AAL1 permits single-factor authentication. AAL2 requires two factors, with cryptographic protections against replay and phishing. AAL3 requires hardware-based authenticators and is, again, uncommon for the general public.

Login.gov supports IAL1 (basic account) and IAL2 (identity-verified account), and it operates at AAL2 by default for any account with a second factor configured. Agencies decide, based on the sensitivity of the transaction, which assurance level to require. Filing a change of address may need only AAL2 with no identity proofing. Filing for federal benefits typically requires IAL2.

The strange edge case worth naming directly: a citizen can have an IAL1 Login.gov account for years, used at one agency, and then be asked by a different agency to step up to IAL2. The same email and password continue to work; the identity proofing is a layer added on top. This is by design, but it confuses people who expect their account to either be "verified" or "not."

Which agencies use it

The roster of agencies relying on Login.gov has grown steadily and now includes, among many others, the Social Security Administration, U.S. Citizenship and Immigration Services, the Internal Revenue Service for certain services, the Small Business Administration, the Department of Veterans Affairs for portions of its public-facing portfolio, the Office of Personnel Management, and — somewhat recursively — SAM.gov, the System for Award Management that contractors must register with before doing business with the federal government.

Coverage is uneven and shifting. Some agencies use Login.gov for everything public-facing. Others use it for some services and a legacy in-house system for others. A handful continue to use ID.me, a private-sector identity vendor that became prominent during pandemic-era unemployment insurance work and remains in use at parts of the IRS and VA. The presence of two parallel federal identity options is the source of a great deal of citizen confusion and a steady stream of congressional correspondence.

Login.gov versus ID.me

The distinction between Login.gov and ID.me is worth drawing carefully because the two are, despite superficial similarity, structurally different things.

Login.gov is a government service, operated by federal employees and contractors under federal data handling rules, with no commercial product line attached. The data collected for identity proofing is held under federal records schedules and used for the purpose of authenticating the user to federal services. There is no advertising business. There is no consumer marketing layer.

ID.me is a private company, headquartered in Virginia, that sells identity verification as a commercial service to both government and private-sector clients. When a citizen verifies through ID.me for, say, an IRS function, the same ID.me account can subsequently be used at retailers offering military or first-responder discounts. That cross-context portability is, depending on one's view, either a convenience or a privacy concern. The 2022 episode in which the IRS announced it would require ID.me facial recognition for online accounts, and then reversed course after public objection, is the moment at which Login.gov's role as the preferred federal option became more publicly visible.

Both services are capable of meeting NIST 800-63 IAL2/AAL2 requirements. The difference is institutional, not technical. Federal CIO guidance has trended toward Login.gov as the default for civilian agencies, with ID.me persisting where prior contracts and integrations make migration nontrivial.

How an agency onboards

The process by which a federal agency adopts Login.gov is more bureaucratic than technical, which is true of most things in federal IT. The technical integration uses standard protocols — SAML 2.0 or OpenID Connect — and a competent agency engineering team can implement it in a matter of weeks. The institutional process around that integration takes considerably longer.

An interested agency begins by contacting the Login.gov partnerships team and describing the service to be protected, the expected user volume, and the assurance level required. A pricing arrangement is established; Login.gov operates on a cost-recovery basis, with agencies paying per authentication or per identity-verified user according to a published rate schedule. The funding mechanism is typically an interagency agreement, of the sort GSA has been executing with other agencies for decades for shared services.

Privacy and security paperwork follows. The agency must update its System of Records Notice under the Privacy Act if Login.gov will be handling personally identifiable information on its behalf, and must complete or update a Privacy Impact Assessment. The agency's authorizing official must accept the security posture of Login.gov, which holds a FedRAMP authorization and operates atop cloud.gov infrastructure. None of this is exotic, but all of it takes meetings.

Technical integration then proceeds in a sandbox environment. The agency's application is configured as a relying party, redirecting users to Login.gov for authentication and receiving a signed assertion in return that contains the user's verified attributes — typically email, and at IAL2, name, date of birth, address, and a unique identifier. The agency decides what to do with that assertion: most commonly, match it against an existing internal account or create a new one.

Production launch usually involves a phased rollout, a period during which both the legacy authentication system and Login.gov operate in parallel, and eventually a cutover. Some agencies have run dual systems for years for reasons that are usually political rather than technical.

What Login.gov does not do

Several misconceptions are worth addressing directly because they come up repeatedly.

Login.gov is not a national ID system. It does not issue identity credentials in any portable sense; the verification it performs is for the purpose of authenticating to federal services, not for presenting elsewhere. A Login.gov account is not a digital driver's license.

Login.gov does not store agency application data. It authenticates the user and returns an assertion. The substantive data of a benefits claim, a tax filing, or an immigration application stays with the agency that owns the service. The boundary is sharp and intentional.

Login.gov does not adjudicate eligibility. Whether a verified person is in fact entitled to the benefit they are applying for is the responsibility of the agency program. Login.gov can confirm that the person is who they say they are; it has no opinion on whether they qualify for anything.

Login.gov is not, despite occasional confusion, the same thing as PIV or CAC cards used by federal employees and contractors. Those are HSPD-12 credentials issued under a separate framework for workforce authentication. Login.gov is for the public.

The slightly absurd thing about federal identity

Anyone who has watched the federal identity space for a while comes to appreciate a particular small absurdity: the United States has, by deliberate historical choice, no national identity system, and yet citizens regularly need to prove their identity to the federal government in order to receive services the federal government provides. The compromise that has emerged is a service that verifies identity by checking commercial and state-issued documents — driver's licenses, primarily — against commercial data brokers and authoritative databases, and produces an assertion that satisfies federal assurance requirements without ever issuing a federal identity credential. It is identity verification by triangulation, conducted at scale, by an office originally set up to help agencies buy office furniture more efficiently. That this works as well as it does is, on reflection, mildly remarkable.