Login.gov has run as a federal identity verification platform for years, built around federal agencies and federal systems. The Department of Labor is now enhancing its identity verification offering for state unemployment insurance programs, raising the standard to include biometric identity proofing and integrated in-person verification through USPS.
For states already using Login.gov through NIDVO, this is an upgrade. For states starting fresh, it is a full integration with a platform that was not built with state systems in mind from the start.
What Login.gov does for states
Login.gov answers one question: is this person who they say they are. It does not decide what they are allowed to do inside your system once they are verified.
That distinction is where a lot of teams get tripped up early. Verified identity, assurance levels, and multi-factor confirmation come from Login.gov. Everything else, who is allowed to see what, what happens when someone is verified but not enrolled in your program, what your caseworkers see versus what an applicant sees, belongs entirely to your application.
This shows up in small but consequential ways. A successful Login.gov authentication is not the same as being authorized to use your system. A resident might verify their identity perfectly and still not be eligible for the program they are applying to, and your application needs to handle that gracefully rather than treating verification as a green light. The same is true in reverse: if someone's account gets suspended in your system, Login.gov has no idea, and won't stop them from authenticating. Your application has to catch that.
Login.gov gets you to a verified identity, reliably and securely. What comes next is yours to build.
The work between the mandate and the launch
A federal directive tells you what is required. It will not warn you about the moment your launch gets held up over something nobody flagged, or the weeks lost because two teams thought the other was waiting on them.
Two things state teams consistently miss.
Paperwork doesn't wait for code.
The legal and procurement track, the interagency agreement, security authorization, and risk assessment, does not have to wait for technical planning to finish. It can and should start in parallel. Teams that treat it as a step that comes after the technical plan is set are usually the ones still waiting on paperwork when their developers are ready to go live.
The page nobody plans for.
Any integration that proofs identity at the enhanced standard also needs a specific page on the agency's own website for residents who cannot complete verification, whether they lack a valid ID, cannot capture a usable photo, or fail the process outright. It is a small requirement, easy to miss, and exactly the kind of thing that surfaces during a security review when there is no time left to build it properly.
Your team needs to be ahead of these issues, not catching up to them. The Fearless Login.gov team built a checklist that walks through what has to happen before development starts, what your team needs to build on the application side, and what production deployment actually involves, drawn from the same process used to build Login.gov itself.
The full checklist covers what else your team needs before launch. It is the same one our team uses on Login.gov work internally, Download the Login.gov Implementation Checklist