A draft memo from the Office of Management and Budget would require federal agencies to route identity verification on their public-facing websites through Login.gov, according to FedScoop. If it survives in that form, every agency site that currently rolls its own sign-in, or licenses a third-party identity vendor, would need to fold that traffic into a single federal system instead.
For anyone building or maintaining government-facing digital work, that is not a small technical footnote. It is a new constraint that sits underneath the design brief, the procurement contract and the QA checklist, on every project that touches a federal login screen from here on.
What the memo actually changes
Login.gov already exists and already handles sign-in for a number of federal services. What the draft memo would do is remove the choice. Instead of an agency deciding whether to use Login.gov, build its own authentication, or contract a separate identity provider, the expectation becomes that Login.gov is the default, possibly the requirement, across government websites.
That shift matters most for the vendors and agencies who are not the ones running Login.gov but who build the interfaces sitting on top of it. A login flow is never just a login flow. It is form validation, session handling, error states, accessibility compliance, mobile behavior and support documentation. Standardizing the identity layer standardizes all of that, but only if your product was built to work with Login.gov's actual constraints rather than assumptions carried over from a commercial identity vendor.
Identity as a fixed line item, not a variable one
Up to now, teams building for federal clients could treat identity verification as one module among several, something to be scoped per project depending on which agency, which vendor relationship, which legacy system was already in place. A mandate collapses that variability. It means:
- Every proposal for federal-facing work now has to assume Login.gov integration by default, not as an optional add-on priced separately.
- QA and accessibility testing has to be built around Login.gov's actual user flows, not a generic sign-in pattern.
- Timeline estimates need to account for a federal identity dependency that the vendor does not control and cannot accelerate on its own schedule.
None of that is exotic. It is the same shift that happens whenever a platform a market runs on top of becomes mandatory rather than optional, think of what happens to web development once a browser vendor changes a default. The difference here is that the platform is a government identity system, and the mandate comes from OMB rather than market pressure.
The rest of the federal digital stack is not standing still
This mandate is not arriving into a settled environment. FedScoop also reports that Pete Waterman, the FedRAMP director, has just been reinstated at GSA after weeks of leave. FedRAMP is the authorization process that determines which cloud products and vendors are cleared to work with federal agencies at all, so the same office setting the identity rules is one that has just had a leadership gap of its own.
At DHS, meanwhile, CIO Antoine McCord is exiting the agency, per FedScoop. DHS is one of the larger federal operators of public-facing digital services, and a CIO departure during a period when identity requirements are being rewritten from above adds another layer of transition to plan around, not because either event is dramatic on its own, but because vendors now have to track leadership and policy churn across multiple agencies simultaneously rather than treating each as a separate relationship.
There is also a live legal complication worth naming. A lawsuit reported by FedScoop alleges that HUD and DHS have been ducking FOIA requests specifically about their data-sharing practices. That is a different issue from Login.gov itself, but it sits in the same territory: government agencies are being asked to centralize how they verify who a user is, at the same moment their own data-sharing practices between agencies are being challenged in court. Any vendor building tools that move user data between agency systems should read that lawsuit as a signal that data-sharing accountability is an active fault line, not settled ground.
What to actually budget for now
If the OMB memo moves from draft to policy, the practical response is not to wait and see. It is to treat Login.gov integration as a standing line item in any federal-facing proposal, the same way accessibility compliance or security review already are. That means pricing it in from the start, testing against Login.gov's real behavior rather than a mocked-up sign-in screen, and building in schedule slack for a federal dependency whose pace is not yours to set.
It also means watching the personnel side as closely as the policy side. A mandate is only as stable as the office enforcing it, and right now that office has just come through a leadership gap at FedRAMP and is losing a CIO at one of its largest constituent agencies. Vendors who track those signals will budget more realistically than those who treat the memo as a pure technical spec.
Why this is worth taking seriously now, in draft form
Draft memos do not always become policy, and this one could still change shape before anything is enforced. But the direction is clear enough that waiting for the final version before adjusting a proposal template or a project timeline is a bet against the more likely outcome. Identity verification is moving from a design choice to a fixed federal requirement, and the vendors who price that in now, rather than after the memo is finalized, will be the ones who do not have to renegotiate scope midstream.