News

The Federal Single Sign-On Mandate: What M-26-18 Requires

Moca Network

September 2, 2026

A single sign-on mandate requires an organisation to consolidate separate account systems onto one shared authentication service. The United States Office of Management and Budget has now issued Memorandum M-26-18, requiring civilian federal agencies to deploy the government's shared sign-on service across covered public-facing websites within two years. When we covered this in August it was a draft proposal. It is now policy with a clock attached.

The milestones matter more than the headline.

Key takeaways

60 days: agencies must give OMB an inventory of public-facing websites that use authentication.
240 days: each must complete a digital identity risk assessment.
One year: agencies must adopt the shared service's implementation best practices.
Two years: deploy on all covered public-facing websites, or file a notice explaining why they cannot.
The Department of Defense, elements of the intelligence community and national security systems are exempt. Agencies may also retain alternatives where the shared service cannot meet a particular population's needs.

The 60-day inventory is the hard part

The two-year deadline gets the attention. The 60-day requirement is what will actually hurt.

Most large organisations cannot produce an accurate list of their own authenticated properties on demand. Sign-on gets added at the edges: a benefits portal here, a grant application there, a contractor-facing microsite commissioned by one office and inherited by another. The systems that hold credentials are rarely inventoried in the same place as the systems that hold data.

An enterprise reading this outside government should treat the exercise as a free diagnostic. If you cannot list every property where a user creates an account with you, in under two months, you also cannot answer the questions that follow from it: where credentials are stored, which properties share a session, and what an attacker reaches after compromising the weakest one.

Consolidation moves the problem rather than removing it

Concentrating authentication on one service produces real gains. It reduces the number of credential stores, applies one assurance standard, and removes the incentive for every department to build its own identity proofing.

It also concentrates consequence.

Property	Fragmented sign-on	Consolidated sign-on
Credential stores to defend	Many, inconsistent	One, hardened
Assurance level	Varies by system	Uniform
Effect of one compromise	Contained to one system	Reaches everything behind the service
Availability risk	Distributed	Single dependency
User experience	Repeated proofing	Prove once

Neither column is strictly better. Consolidation is the right trade when the shared service is materially better defended than the average system it replaces, which in most federal estates it is. But the risk profile changes shape rather than shrinking, and the policy is explicit that a digital identity risk assessment must be done for each property rather than inherited wholesale.

What this signals to the private sector

Three things follow for organisations that are not federal agencies.

Prove-once is becoming the public expectation. A citizen who verifies identity once for a government service will not accept re-proving from scratch at a bank, a marketplace or a healthcare provider. Onboarding friction is measured against the best experience a user has had, not the industry average.

Assurance levels are becoming a shared vocabulary. Once agencies complete standardised identity risk assessments, the language of assurance levels moves into procurement and partnership conversations. Being able to state the assurance level a given check achieves stops being a specialist concern.

Interoperability is the unanswered question. A government service establishes identity for citizens accessing public services. It does not, by itself, let a private business verify an attribute about that person. The bridge between a strong public-sector proofing event and a private-sector verification need is exactly where verifiable credentials sit.

AIR Identity is built for that bridge: a verification performed once can be presented elsewhere as a zero-knowledge proof of the specific attribute a service needs, without the relying party receiving the underlying identity data or contacting the original issuer. For businesses whose acquisition economics depend on onboarding completion, that portability is the difference between a verified user and an abandoned signup — a point we examined in proof of human and in the context of verified user acquisition.

Practical steps

Run your own 60-day inventory. List every property where a user authenticates, who owns it, and what data sits behind it. The exercise usually finds systems nobody claimed.

Assess risk per property, not per organisation. A marketing microsite and a payments portal do not need the same assurance level, and treating them identically over-secures one and under-secures the other.

Decide where you sit in the chain. Are you proofing identity yourself, consuming someone else's proofing, or both? Organisations that have never made this explicit tend to be doing all three inconsistently.

Plan for portable assurance. Design on the assumption that users will arrive already verified elsewhere, and that being able to accept that proof is a competitive advantage rather than a compliance concession.

Frequently asked questions

What does OMB Memorandum M-26-18 require?

It requires civilian federal agencies to deploy the government's shared sign-on service across covered public-facing websites within two years, with an inventory of authenticated public-facing sites due in 60 days, digital identity risk assessments in 240 days, and adoption of implementation best practices within one year.

Which agencies are exempt from the single sign-on mandate?

The Department of Defense, elements of the intelligence community and national security systems are excluded. Agencies may also retain alternative sign-on where the shared service cannot meet the needs of a particular population or operational requirement, or where removing an existing option would significantly burden users.

What is a digital identity risk assessment?

A structured evaluation of what could go wrong if the wrong person gains access to a given service, used to determine the identity assurance and authentication assurance levels that service requires. Different services justify different levels, which is why the assessment is done per property rather than once for an organisation.

Does a government sign-on service let private businesses verify identity?

Not directly. A public sign-on service establishes identity for access to public services. Private-sector verification requires a credential the individual can present to a third party, which is the role verifiable credentials and attribute attestations perform.

How does single sign-on consolidation change security risk?

It reduces the number of credential stores to defend and standardises assurance, while increasing the consequence of a compromise or outage in the shared service. The trade is generally favourable when the shared service is better defended than the systems it replaces, but it requires per-service risk assessment rather than blanket adoption.