Digital identity management is often seen as the domain of your IT security team. It involves authentication protocols, encryption standards, and technical controls. Your CISO manages the risk, your identity and access management specialists implement the tools, and everyone else stays out of the way.
However, NIST's Special Publication 800-63, Revision 4 challenges this approach.
Rethinking Identity Management
Digital identity isn't just a technical issue; it's a business risk that manifests through technical systems.
When identity management is isolated within IT, you may focus on the wrong outcomes. Your security team might create complex authentication processes that frustrate legitimate users. Fraud prevention measures could drive customers away. Compliance gaps might only be discovered after implementation. Business units might bypass systems that don't meet their needs.
The Revision 4 guidelines position identity management as a cross-functional process involving professionals from cybersecurity, privacy, usability, and other areas. This isn't just diplomatic language. It's an acknowledgment that identity risk management has evolved into a "team sport" because no single function has all the necessary expertise.
Consider fraud detection. Your security team understands attack vectors. Fraud analysts know behavioral patterns. Customer service knows when legitimate users are blocked. Legal counsel understands regulatory exposure. Without integrating these perspectives, you risk building controls that prevent fraud but also hinder revenue.
Evidence for a Cross-Functional Approach
The updated guidelines include expanded fraud requirements and recommendations for identity proofing processes. These requirements demand consideration of user experience, privacy obligations, operational efficiency, and mission delivery, not just technical controls.
The integration of syncable authenticators and subscriber-controlled wallets into the federation model illustrates this shift. These aren't merely new technical options. They're responses to real-world friction between security requirements and user behavior. While your security team might prefer hardware tokens, users are already managing passkeys across devices. The question isn't which is more secure in theory, but which combination of controls effectively protects your organization given how people work.
Revision 4's continuous evaluation metrics reinforce this cross-functional requirement. Continuous evaluation involves ongoing assessment of whether your identity systems remain effective as threats evolve, user populations change, and business requirements shift. You can't monitor effectiveness solely from a technical perspective. Are authentication processes causing support calls? Are users sharing credentials to bypass friction? Are business units creating shadow identity systems? These operational signals are as important as intrusion attempts.
The reframed risk management processes in Revision 4 highlight a fundamental truth: identity risk isn't just about unauthorized access. It's also about authorized users who can't access what they need, privacy violations from excessive data collection, regulatory penalties from inadequate controls, and business disruptions from systems misaligned with operational needs.
Implementing a New Approach
Start by redefining ownership of identity risk. Your CISO doesn't own it alone. Identity risk is shared across security, privacy, fraud, compliance, operations, and the business units that rely on digital services.
Establish a cross-functional identity governance body with decision-making authority. Include representatives from security, privacy, legal, fraud prevention, customer experience, and major business units. This group should review identity proofing processes, authentication requirements, federation arrangements, and continuous evaluation metrics together.
When implementing new identity controls, require impact assessments from each function. Your security team evaluates threat mitigation. Your privacy team assesses data minimization and consent. Your fraud team reviews detection effectiveness. Your operations team considers support burden. Your business units evaluate mission impact. Make tradeoffs explicitly, not by default.
Build continuous evaluation metrics reflecting this cross-functional view. Don't just measure failed authentication attempts. Measure support tickets related to identity issues, user abandonment during identity proofing, privacy complaints, fraud losses, and time-to-access for legitimate users. When these metrics change, your governance body investigates together.
For identity proofing, map your current processes against Revision 4's restructured controls that define roles and types of identity proofing. Then ask your cross-functional team: which controls create friction that legitimate users can't navigate? Which create unnecessary privacy exposure? Which fraud vectors are still missed? The technical controls matter, but the business context determines which controls to apply where.
Address new requirements for injection attacks and forged media through this same lens. Your security team needs to implement detection controls. Your fraud team needs to define response procedures. Your legal team needs to understand liability exposure. Your business units need to know how verification delays affect operations.
When Technical Ownership Suffices
Technical ownership is appropriate for certain identity functions. Cryptographic implementation, protocol selection, and infrastructure security belong to specialists. You don't need cross-functional input on whether to use SHA-256 or which TLS version to require.
For organizations with simple identity requirements, a single user population, and low fraud risk, lightweight governance might suffice. If you're managing employee access to internal systems with no external federation and no sensitive data, your IT security team can probably handle it.
However, if you're authenticating customers, handling sensitive data, operating across jurisdictions, or facing significant fraud risk, identity management is too important to leave to one function. The risks are diverse, the tradeoffs complex, and the business impact significant.
Revision 4 doesn't just update technical requirements. It updates your organizational model for managing identity risk. The guidelines reflect nearly four years of collaborative development and about 6,000 public comments because identity management now touches too many concerns for any single perspective to address effectively.
Your technical controls will only protect what your organization actually needs protected if the people who understand those needs help design the controls.
