Take a staggered approach to modernizing the 3 digital identity pillars
Ren Iris
“Digital identity modernization” has been a trending topic in civic tech. I spoke with Rob, a director at Mighty Acorn Digital, to understand why some of these modernization projects unfold smoothly while others encounter pitfalls. He’s most interested in helping state and local governments build secure digital services that are simple to maintain, easy to use, and widely recognizable.
“Building user-friendly sign-on and identity systems requires a lot of incremental change,” said Rob. “It’s not something that can be done in a single big bang, so it’s imperative that the systems be easy to work on, easy to add to, and easy to scale up.”
On agency projects, Mighty Acorn works to integrate and educate, starting with engineering teams. As Rob recognized, sign on and identity are only parts of the digital-access picture. When you integrate the “data and patterns of the identity system well,” Rob said, that intentionally built platform “makes the system feel natural for users.” That smooth feel is made possible through collaborative efforts with a central identity team, whether that means onboarding a vendor or working interdepartmentally.
Digital identity modernization involves 3 pillars, not 1
“Digital identity” sounds like a singular entity or concern, but Rob noted that it encompasses 3 distinct pillars.
1. Single sign-on (SSO): Give constituents 1 secure, usable login across local government systems.
2. Identity verification: Prove that a person is who they say they are by using documentation and clear standards.
3. Central profile and information sharing: Keep core details (such as addresses) updated once and reflect changes across relevant agencies.
Rob has observed that some agencies imagine a panacea: 1 system that simultaneously solves sign-on, identity proofing, and profile sharing. The reality is more complicated than that, especially when there are compliance and security requirements. Each pillar—SSO, identity verification, and central profile and information sharing—has its own “network of complexity” in technology, policy, and user experience. Building 1 pillar is complicated enough; when agencies try to modernize all 3 simultaneously, it can overwhelm teams and stall progress.
Identity is something most constituents assume is a solved problem, but the segmentation of government offices doesn’t easily lend itself to centralized services that are both user friendly and work well for agencies within the government. That intersection is possible, but hard to achieve—it takes a lot of work and coalition building.
For example, Rob said that applying for benefits needn’t be a complex process. We already have the technical tools to provide the central identity assurance that would let people skip many of “the boilerplate parts of an application form, but they’re rarely deployed in that way.”
Digital identity modernization benefits from a staggered, layered mindset. Rob recommended treating the 3 pillars as layers. Modernize with a strong SSO, then sequentially add identity assurance and centralized profile. Sequencing reduces risk and gives opportunities to learn from constituents during each project sprint or phase. It also maintains momentum because it spaces out influential decision-making, avoiding bottlenecks.
Start by creating a usable SSO with secure access
Define a clear, constituent-friendly sign-on pattern (e.g., username / password plus an appropriate second factor) that can be reused across agencies. Align sign-on decisions with standards such as authentication assurance levels, without losing usability. “Security is critical to get right,” said Rob, with aspects to consider such as data security, fraud detection, and social engineering–resistant human processes.
Another key step is integrating SSO into agency systems. It should be straightforward for software engineering teams to plug into the central sign-on service. “I’d think deeply about which data belongs in a central identity system versus an agency system,” Rob said. “If it’s not broadly useful data across many agencies, it doesn’t belong in the central system.” He suggested that agencies treat sign-on as a shared infrastructure that can be adopted consistently. Agencies can then avoid reinventing authentication for each project.
While Rob has found that agencies focus plenty on fraud prevention, they do so sometimes at the expense of inclusion. Avoid unnecessary barriers—such as overly strict rules for email formats or name characters—that block valid users without meaningfully reducing fraud.
“Many government entities believe that the use of privacy-preserving email services,” observed Rob, “or alias addresses that use ‘+’ introduce an opportunity for fraud. The counterpoint is that residents may wish to use these addresses for a variety of reasons, such as wishing [to preserve] their ‘real’ email address, or creating a duplicate account to work around a limitation some system imposes.” There are applications beyond constituents’ privacy, too. What happens when someone has an accent mark in their name? What about special characters in emails? Agencies want standardization and security, but also, they don’t always know the potential implications or cascading effects of a systemic or design decision.
Designing for inclusion involves considering user research / the user experience. Rob recommended designing for a diverse set of users—people with missing documentation or limited device access (What happens when someone has inconsistent access to a mobile device for SMS or TOTP authentication?), older constituents, and those uncomfortable with or unfamiliar with technology. Factors such as SMS, phone calls, and device-bound credentials all require levels of access, privilege, and knowledge.
Rob also offered “formulas for success…such as allowing a phone-call OTP code as an alternative to SMS OTP.” And, when possible, agencies can support offline documentation-proofing processes. He underscored maintaining awareness of what a system is doing to best filter system rejections, which helps agencies determine if someone is attempting fraud or simply getting stuck. “Bring an inclusive lens to every stage of the software development lifecycle…. Be prepared to iterate often” and speak with constituents and residents to learn where their pain points are in the identity process.
Add identity verification and profile as later layers
Once there’s a solid sign-on process, Rob said, agencies can add identity proofing, which entails collecting and checking documentation to meet desired identity assurance levels. Create a plan for managing partial or incorrectly submitted documentation by integrating alternative workflows, such as offline verification and staff-assisted processes.
Being methodical, measured, and context-driven increases the chances of long-term modernization success. Move cautiously into centralized profiles, using central profile data only for the attributes that several agencies find useful. Each agency manages its own program-specific data, making a focused approach the natural one. Rob also underscored thinking through how changes such as address updates should be communicated to agencies. These changes may raise policy questions, such as whether benefits can be legally redirected to a new address.
Throughout the digital identity modernization process—and for each identity pillar—Rob advised that agency teams communicate complexity, keeping it manageable with ongoing feedback and iteration. At each layer, collect data that pinpoints where constituents are getting stuck. Agencies can deploy user research techniques to gather pain points from both constituents and agency staff, then apply those findings to adjust documentation, workflows, and systems before modernizing the next identity pillar.
“In general,” said Rob, “the principle here is to approach business rules with a critical eye.” Move methodically, thinking through privacy and security implications, and “decide if the tradeoffs are worth it.” Sometimes, “there’s no ‘right’ answer,” but “we have to help everyone understand the implications of a decision.”