Utah's State-Endorsed Digital Identity (SEDI) framework, enacted through S.B. 275 and effective May 6, 2026, is a serious piece of legislation. It establishes a Digital Identity Bill of Rights, creates enforceable obligations for wallet providers, verifiers, and relying parties, and builds in protections against issuer surveillance that go further than most state digital identity programs attempted before it. Other states are paying attention.
But legislation is only the starting point. A state that wants to implement something similar faces a layered set of decisions that the statute itself cannot resolve: governance structure, trust infrastructure, credential issuance architecture, wallet ecosystem management, verification standards, conformance processes, and a deployment plan that works across agencies with different systems and different needs. Most of these decisions require the state to determine what it wants before any technology can be procured or deployed.
This post works through those layers, drawing on Utah's published framework where it provides concrete reference points, and identifying where another state would need to make its own determinations.
SEDI is not a product a state purchases and deploys. It is a governance framework backed by statute. Utah's S.B. 275, codified as Utah Code Title 63A, Chapter 20, establishes the program structure, the rights framework, the obligations on ecosystem participants, the data handling restrictions, and the enforcement mechanisms. Without comparable statutory authority, a state implementation team has no reliable basis for the privacy protections, the Duty of Loyalty obligations, or the enforcement mechanisms that give SEDI its structure.
Utah has published example statutory language formatted for adaptation, containing all nine parts of Chapter 20, all 30 definitions, and implementation notes. That template makes the legislative drafting stage more tractable than building from scratch, but it does not eliminate the work of adapting the framework to state-specific constitutional requirements, existing identity statutes, and agency authorities.
The statute also specifies that any infrastructure used to control issuance or revocation must be maintained within a state-controlled data center located within the state (63A-20-301(2)(c)). A state building its own SEDI framework would need to decide whether to adopt comparable constraints and how to operationalize them.
A SEDI implementation requires an operating governance structure before it can issue a single credential. Utah's statute requires a program manager experienced in government administration, data privacy, cybersecurity, and information technology (63A-20-203). Beyond that role, a functioning program requires defined processes for identity proofing standards, credential lifecycle events, conformance certification for wallet providers and verifiers, the complaint and enforcement pathway, annual reporting (Utah's begins January 1, 2027), and coordination with other agencies on use case acceptance.
That coordination point matters more than it might appear. Utah's statute requires coordination with the Department of Alcoholic Beverage Services, the Driver License Division, the Department of Health and Human Services, the State Board of Education, and law enforcement to evaluate SEDI acceptance for age verification, student enrollment, law enforcement encounters, and financial institution identity verification (63A-20-204). A new state would need to map its own cross-agency use cases before issuance begins, not after.
SEDI credentials are cryptographically signed documents. Verifying them requires knowing that the signing key belongs to the issuer you trust. This means the state needs a public key infrastructure (PKI) capable of publishing and managing the keys that will be used to sign credentials, along with mechanisms for verifiers to retrieve and validate those keys.
Utah's implementation guide specifies use of NIST-approved cryptographic algorithms (RSA 2048 or higher, ECDSA P-256 or higher, AES-256, SHA-256). More importantly, the trust architecture in a SEDI framework is designed for peer-to-peer verification. Because the statute prohibits "a mechanism that allows the department to monitor, surveil, or track the presentation of a state-endorsed digital identity to another entity" (63A-20-301(3)), the verification architecture cannot be one where every presentation routes through an issuer-controlled server. The trust infrastructure has to support offline-capable, cryptographically complete verification without a live connection to the issuer.
A state cannot simply deploy credentials that ping a central server for validity on each presentation. The issuer's role ends at issuance; verification happens between the holder's wallet and the verifier's system using published keys and credential metadata.
The trust infrastructure also needs to handle key rotation, certificate expiry, and revocation without creating new surveillance vectors. Utah limits revocation grounds to compromise, issuance error or fraud, or holder request (63A-20-301(5)). The SEDI Implementation Guide addresses this by separating status checking (revocation) from signature verification: revocation checks may require external communication, but signature verification may not. The guide requires that the department gains no presentation activity information from revocation queries.
Before the state can endorse anyone's digital identity, it has to verify who that person is. Utah's statute requires successful identity proofing as a condition of eligibility (63A-20-302). The specific standards for that proofing, aligned to NIST SP 800-63-4, are defined in the implementation guide rather than in the statute itself.
Identity proofing involves confirming that the applicant is who they claim to be, typically by checking documentary evidence against authoritative data sources and verifying liveness or physical presence. A state that performs weak proofing and then issues a credential with strong technical protections has added cryptographic certainty to an uncertain foundation.
For SEDI, the proofing process must accommodate the personal digital identifier concept: the holder creates a unique identifier that is cryptographically provable to be under their control and transportable to infrastructure of their choice (63A-20-201). The state's proofing process binds the credential to that holder-generated identifier, not to a government-assigned number. This is architecturally different from most existing state ID systems. States should evaluate whether their existing proofing systems are compatible with holder-controlled identifier binding.
Once proofing is complete, the state issues a verifiable digital credential that represents the holder's state-endorsed identity. The credential format determines what the credential can express, how selective disclosure works, and which wallets and verifiers can process it.
Utah's open standards requirement (63A-20-301(2)(e)) specifies that the department must select standards that are publicly available and free from licensing fees and patent restrictions. The statute is format-agnostic; qualifying open standards could include mdoc, W3C Verifiable Credentials, SD-JWT, KERI, and others. A state implementing SEDI would need to decide which formats to issue credentials in, and whether to support more than one format to enable participation by the widest range of conformant wallets and verifiers.
Selective disclosure is a statutory right (63A-20-101(8)) and a wallet provider obligation (63A-20-401). But it is a capability of the credential format, not just a policy statement. States need to verify that their chosen format actually enables attribute-level disclosure without revealing the underlying credential structure.
The issuance system also handles the full credential lifecycle: initial issuance, updates when attributes change, suspension where applicable, and revocation under the limited grounds the statute allows. Program design decisions made early here have long-term operational consequences.
One of SEDI's structural features is that it requires a multi-wallet ecosystem. The statute does not select a wallet provider; it sets standards that wallet providers must meet. Utah's Digital Wallet Provider requirements (63A-20-401) include support for online and offline presentation, a secure holder-controlled log of presentations (accessible, exportable, and deletable only by the holder), selective disclosure, and age-minimum verification without disclosing age or date of birth.
This design prevents any single platform from being the exclusive wallet. It also means the state must build a conformance process: evaluating whether a wallet meets requirements and publishing conformance status so government entities, health care providers, and verifiers know which wallets to accept.
Utah's draft implementation guide defines base and profile conformance for issuers, wallets, and verifiers, and states that it does not itself establish a certification program. But the certification process itself, including who conducts it, how long it takes, and what happens when a certified wallet develops a deficiency, is not built into any standard. The state, or a consortium of states, has to build that infrastructure.
Verifiers in Utah's framework are required to mathematically verify credentials, specify the purpose of each identity presentation, and limit data requests to what is necessary for that purpose. The statute also prohibits verifiers from requiring device surrender during a presentation (63A-20-304(c)).
Government entities must accept SEDI within three months after the first credential is issued, unless technically infeasible (63A-20-304). Health care providers receiving at least $10,000,000 per year in public funding have a two-year window (63A-20-305). Both timelines assume verifier-side tooling is available when those deadlines arrive.
States need to evaluate what verifier infrastructure exists or can be procured: reader applications for in-person verification, online verification flows for digital services, and integration guidance for agencies with legacy systems. The conformance framework should apply to verifiers as well as wallets, and states need to decide whether to provide reference implementations that agencies can adopt.
SEDI is more useful when it works everywhere within a state, and potentially across state lines. Both dimensions require deliberate work. Within a state, the challenge is that agencies operate different systems, different digital service platforms, and different authentication frameworks. A state issuing SEDI credentials needs an integration strategy that spans agencies rather than treating each agency as a standalone implementation.
Cross-state credential recognition is architecturally possible when both states use compatible credential formats and exchange protocols. The example statutory language Utah has published is intended to facilitate this: if other states adopt compatible frameworks, a credential issued by one state can be verified by systems in another without requiring a bilateral integration. But this depends on more than shared standards. Mutual recognition requires that each state's conformance and trust framework is structured in a way the other trusts, that the cryptographic infrastructure is interoperable, and that policy decisions about what constitutes valid identity proofing are compatible or explicitly harmonized.
Utah's "Protecting Liberty" document invites other states to join a SEDI Consortium. The April 2026 SEDI Summit named the Kantara Initiative as the organizational home for the multistate consortium, and more than 25 states have participated in discussions. However, the detailed governance structure for the consortium, how it would operate, how disputes would be resolved, and what obligations membership would create, have not been published in final form. States considering SEDI adoption should treat multistate interoperability as a medium-term goal that requires parallel policy engagement, not just technical alignment.
SEDI's privacy protections are meaningful only if the technical architecture enforces them. The "no phone home" requirement is the clearest example: if the credential format or exchange protocol requires an issuer lookup at presentation time, the door to surveillance remains open regardless of the statutory text. Similarly, the processing restrictions in 63A-20-702 and the wallet provider log requirements presuppose specific data management designs: holder-controlled encryption, no server-side transmission without authorization, and functional deletion mechanisms.
A state implementing SEDI needs to evaluate whether each privacy requirement is satisfied technically, not just stated in policy. This means reviewing credential formats for surveillance vectors, exchange protocols for data minimization, and wallet provider agreements for data handling.
The Duty of Loyalty provision (63A-20-701) creates an affirmative obligation to act in the best interests of the individual that goes beyond notice-and-consent compliance. For implementation purposes, it should inform how contracts with vendors are structured, what audit rights the state retains, and what remediation processes exist when a participant's behavior conflicts with the individual's interests.
SEDI explicitly preserves the right to a physical identity credential (63A-20-101(3)) and prohibits government entities from withholding services based on format choice (63A-20-304(a)). A SEDI program cannot be designed as a replacement for physical IDs. Preserving both pathways requires ongoing investment in both systems. States should factor this into program design and budget requests; the risk of underfunding the physical pathway is that the legal guarantee of equal service becomes theoretical.
Digital identity programs can stall when the technology is ready but acceptance is thin. A credential that works at one agency but not at the next will not drive adoption. States need an agency adoption strategy: which agencies go first, what integration support they receive, how staff are trained, and how conformance requirements are communicated.
The three-month window for government systems to accept SEDI (63A-20-304) assumes that integration tooling exists when the clock starts. States need reference implementations, integration documentation, and technical support in place before the first credential is issued, not after agencies hit their deadlines.
None of this happens in a single procurement or a single deployment sprint. SEDI implementation is sequential in important ways. Governance has to be established before conformance processes can run. Trust infrastructure has to be operational before credentials can be issued. Conformant wallets have to exist before residents can receive credentials. Verifier tooling has to be available before agencies can accept them.
Early decisions have long-lasting consequences. The credential format determines which wallets can hold it. The conformance standards determine the ecosystem that develops. The trust root architecture determines how revocation and key rotation work years later. Getting these decisions right requires treating SEDI as infrastructure design, not product deployment. Open standards reduce the risk that early decisions lock in a single vendor, but they do not resolve the governance questions; they create the technical substrate on which governance decisions can operate.
SpruceID has submitted recommendations to Utah's SEDI Request for Information covering credential architecture, privacy controls, standards, interoperability, and governance. If your state is assessing what a SEDI-compatible implementation would require, contact us to discuss the infrastructure decisions your program will need to make.
About SpruceID: SpruceID builds digital trust infrastructure for government. We help states and cities modernize identity, security, and service delivery — from digital wallets and SSO to fraud prevention and workflow optimization. Our standards-based technology and public-sector expertise ensure every project advances a more secure, interoperable, and citizen-centric digital future.
