The Conventional Wisdom
Identity management often falls solely on IT. You hire an IAM architect, buy a platform, configure your Identity Provider, and consider it done. Security reviews policies, compliance checks boxes, and business units submit tickets for access. It's a clean separation of concerns.
This model worked when identity was just "username and password to access the file server." It doesn't work when your attack surface includes synced passkeys, federated sessions across cloud providers, and deep fake attempts at identity proofing.
Why We Disagree
NIST's Special Publication 800-63, Revision 4 makes it clear: identity management is a cross-functional process involving cybersecurity, privacy, usability, program integrity, and business units. It's not a suggestion but a requirement for meeting digital identity assurance levels.
The guidelines frame identity risk management as a "team sport." No single function has enough context to make sound identity decisions anymore.
Your IAM architect doesn't know which business processes create fraud risk. Your fraud team doesn't understand OAuth 2.0 Authorization Code Flow or Proof Key for Code Exchange. Your UX designer can't assess whether a continuous evaluation metric will trigger false positives that lock out legitimate users. Your privacy counsel doesn't configure Multi-Factor Cryptographic Devices.
Revision 4 emerged after a four-year process with roughly 6,000 public comments. It includes controls for injection attacks, forged media like deep fakes, integration of syncable authenticators, and representation of subscriber-controlled wallets in the federation model. These aren't incremental patches; they're responses to a fundamentally changed threat landscape since 2017.
You can't address deep fake identity proofing with an IT-only team. You need experts in document fraud patterns, biometric liveness detection, legal implications of false rejections, and user experience impacts.
The Evidence
Look at the expanded fraud requirements in Revision 4. Fraud isn't just a technical control problem. It's a risk modeling problem that requires understanding your business context, user population, and threat actors.
The new continuous evaluation metrics don't just measure system uptime. They assess whether your identity assurance levels remain valid after initial authentication. That decision requires input from:
- Security: What behavioral signals indicate compromise?
- Privacy: What monitoring crosses the line into surveillance?
- Business units: Which workflows tolerate reauthentication and which don't?
- Legal: What do your terms of service permit?
The restructured identity proofing controls better define roles and types of identity proofing. Remote identity proofing for a healthcare portal requires different controls than in-person proofing for a government credential. Your IAM team can implement technical controls, but they can't decide which level of assurance your use case requires or accept the residual risk.
Consider the password composition and rotation changes in Revision 4. These changes reflect research showing that forced rotation creates weaker passwords and that composition rules don't improve security against modern attacks. Implementing this guidance requires convincing business stakeholders that their "change passwords every 90 days" policy is counterproductive. That's not a technical conversation.
What to Do Instead
Build an identity risk working group with members from security, privacy, legal, fraud/program integrity, user experience, and business operations. This shouldn't be a quarterly steering committee but a working group that reviews identity decisions weekly.
Give them shared metrics. Revision 4 recommends continuous evaluation metrics. Define what you'll measure: failed authentication rates, account takeover attempts, false positive lockouts, time to provision access, user satisfaction scores. Make the working group accountable for the tradeoffs.
Map your identity proofing requirements to business context, not just compliance checkboxes. Revision 4 restructures identity proofing controls around roles and types. Your working group should document which services require which identity assurance levels, who approves exceptions, and how you'll measure control effectiveness.
Create decision frameworks for new identity capabilities. When evaluating synced passkeys or subscriber-controlled wallets, your framework should include:
- Security: Does this reduce phishing risk?
- Privacy: What data leaves our control?
- UX: Will users understand this?
- Business: Does this enable or block revenue?
- Legal: What liability do we accept?
Run tabletop exercises for identity scenarios. Walk through a deep fake attempt at remote identity proofing. Who detects it? Who investigates? Who decides whether to block the user or escalate? Who communicates with the affected party? If your answer is "IT handles it," you're not ready.
Document your cross-functional identity risk management process. Revision 4 establishes this as foundational. Write down who participates, how you assess identity risk, how you select controls, how you measure effectiveness, and how you adapt. Make it auditable.
When the Conventional Wisdom Is Right
If your identity requirements haven't changed since 2017, you can probably keep your IT-centric model. If you're running a single-tenant application with username and password authentication, no federation, no mobile access, and no regulatory requirements beyond "don't store passwords in plaintext," you don't need a cross-functional identity working group.
But if that describes your environment, you're not reading this publication.
For everyone else: the threat landscape has moved. Deep fakes exist. Passkeys are real. Federation crosses organizational boundaries. Your users expect seamless access across devices. Your attackers are more sophisticated than your controls.
NIST spent four years updating these guidelines because identity management has outgrown the IT silo. The question isn't whether to build cross-functional processes. It's whether you'll build them before or after your next incident.
