Identity Assurance Level 3 (IAL3) is a secure standard for digital identity, reserved for the highest-risk verifications where a false claim could result in insider theft, severe financial loss, fraudulent hiring, or criminal liability.
With NIST SP 800-63-4 now in effect, the requirements for IAL3 have been refined. For organizations relying on Trust Swiftly to handle high-assurance IAL3 identity proofing, understanding two specific operational details is critical: how long to keep the evidence, and how often to require users to provide it.
Here is the breakdown of what the new guidelines say and how we apply them in the real world.
1. How Long to Store IAL3 Evidence?
Under previous iterations of digital identity standards, retention was often a gray area. NIST SP 800-63-4 provides clearer guidance on documented retention policies and the specific handling of biometric data.
Many clients struggle to balance the risk of storing sensitive PII against the desire to purge evidence early to reduce breach exposure. HR, Legal, Compliance, and Security teams often have competing stakes in the IAL3 lifecycle. The location of storage is also another highly discussed topic for organizations. While the data may not be government source data, if IAL3 is used for a FedRAMP project it might fall into the boundary depending on how you classify the criticality of it. The scoping discussions are important to determine early on, because documenting each evidence-handling step is key to setting up the storage environment securely. Other companies treat evidence as sensitive PII and set up DLP controls in their corporate environments to protect it. Employees also have valid privacy concerns; they may not feel comfortable knowing their sensitive biometric data is stored on a corporate system even if it is their own employer.
What NIST Revision 4 Says
For IAL3, NIST mandates the collection of a biometric sample (e.g., a facial scan or fingerprint) to support "non-repudiation," the ability to provide defensible evidence that a specific individual performed an action.
Mandatory Retention: Section 4.3.3 explicitly states that CSPs (Credential Service Providers) "SHALL collect and retain a biometric sample... to support account recovery and non-repudiation."
Duration: NIST does not dictate a universal "number of years." Instead, Section 3.11 requires that retention periods "SHALL be consistent with applicable regulations, policies, and statutes for the regions and sectors that the CSP serves."
The Trust Swiftly Experience: Two Approaches
In practice, organizations typically choose one of two paths:
Path A: The Standard Model ("Life of Account")
Most organizations retain the IAL3 evidence (biometric reference) for as long as the user is active to allow for account recovery. This is followed by a regulatory tail:
Financial/FinCEN: Typically 5 to 7 years after the account is closed.
Healthcare: Often 6 to 10 years depending on HIPAA or state laws.
Federal/FedRAMP: Generally follows NARA schedules, often 3 to 7 years post-termination.
Path B: The Privacy-First Model ("Zero-Retention")
While NIST requirements are explicit regarding retention, companies may prioritize NIST SP 800-63-4 Section 5.1.1 (Privacy Requirements), which mandates data minimization when approved by their assessor and supported by policy. This strategy involves purging the sensitive data immediately after binding the authenticator.
The Trade-off: You reduce the risk of a biometric breach, but you lose the ability to perform biometric account recovery. If a user loses their token, they must re-enroll as a new applicant. One other factor to understand about the breach is the resulting risks. A threat actor with a selfie and ID will still require significant effort to create a proper deepfake and attempt to use it as a foothold into an organization. The main threat instead is an attacker utilizing it for a social engineering attack with knowledge that allows someone to impersonate another person more easily. A secondary threat would be the information being used for financial fraud such as opening a bank account, but proper KYC typically detects these attempts.
Compensating Controls: To satisfy auditors regarding non-repudiation, you rely on the Attestation of Verification. This can show that a vetted entity (Trust Swiftly) witnessed the event and that an audited process bound the token. Storing the raw biometric adds some additional legal value in an enterprise context but also adds significant liability. However, the employee biometric should exist in one area of the organization such as HR records for employee portraits where the headshot matches the IAL3 session. Any organization performing IAL3 should already have a source of truth on headshots as it is a foundational method to detect fake identities.
Our Solution: Whether you choose long-term retention or zero-retention, Trust Swiftly handles the encryption and fragmented storage of these artifacts. We help organizations define ownership, access control, and storage policy so only restricted versions exist in specific, secure environments.
2. How Often to Require IAL3?
IAL3 is a high-friction event. It requires a trained proofing agent (either on-site or via a supervised remote video session) to verify the user. Because of this cost and friction, organizations often struggle with how frequently to require it. The expense alone is a reason most organizations avoid it, reserving it only for their most privileged users.
What NIST Revision 4 Says
NIST views IAL3 primarily as an enrollment (onboarding) event. However, Section 4.3.3 introduces a specific allowance for frequency:
"CSPs MAY choose to periodically re-enroll user biometrics based on the modalities they use and the likelihood that subscriber accounts will persist long enough to warrant such a refresh."
The Trust Swiftly Experience: Risk-Based Re-Verification
We rarely recommend forcing a user to undergo a full IAL3 supervised video session annually simply for the sake of compliance. The exact timing is typically best discussed with your 3PAO; we commonly see organizations consider re-verification in the 2-3 year range based on risk. Adding IAL2 verifications (less intensive and no strict hardware requirements) is another useful strategy for increasing security with lower friction and cost. However, the threat landscape is evolving.
The Insider Threat & Proxy Employees
The trend of hiring "proxy employees" or strawmen has been used for decades by money launderers to set up shell corporations. Today, nation-state actors (such as North Korea) utilize hired contractors (i.e. a Latin American developer) as fronts to procure jobs at Western tech companies.
Why Re-Verify? Bad actors are rarely reliable over long periods. They make mistakes, or the "proxy" (the face) may stop cooperating with the "actor" (the hacker).
The Strategy: If a company never re-verifies, the actor maintains persistent access indefinitely. A re-verification check can catch these actors off-guard. The data provided might have passed initially, but on a re-verification, it may fail due to new external flags or behavioral inconsistencies.
Raising the cost of insider threats is a critical strategy that corporations need to implement as the financial drain and complexity then further limits the available pool of people that are willing to commit these crimes. These are example strategies; more complex methods can be used to increase the chance of catching these types of threat actors. The more lucrative a position is for either financial or information gain, the higher the chance the threat actor will use a reliable proxy pawn, which is why this strategy must be combined with unknown factors to detect the true string puller.
When to Trigger IAL3:
To aid in this strategy, we recommend Risk-Based Re-Verification. You should trigger a new IAL3 check in these three scenarios (more scenarios exist and these are example baselines):
Account Recovery (The #1 Driver): If a user loses their authenticator (e.g., their phone/YubiKey) and forgets their password, they are effectively an unknown stranger again. To recover the account, they must undergo IAL3 proofing.
High-Value Fraud Triggers: If a user attempts a transaction inconsistent with their history (e.g., a privileged role escalation from a new IP and device), triggering a step-up IAL3 check confirms it is them, not an attacker with a phished session.
Elevating Privileges: A user may onboard at IAL1 (email verification) for browsing. When they attempt to access sensitive data, they must "step up" to IAL3.
Our Solution: Trust Swiftly utilizes the "On-Site Attended - Kiosk-Based" and Remote Supervised models defined in NIST Revision 4 (Sec 4.3.8). We optimize agent availability and AI-assisted document validation to reduce supervised session time. This allows clients to request IAL3 verification more frequently without creating unnecessary productivity loss.
The Bottom Line
Under NIST SP 800-63-4, IAL3 is no longer just about checking an ID; it is about binding a human to a digital credential using biometrics and keeping that proof secure for the life of the account.
Trust Swiftly takes the complexity out of compliance. We manage retention schedules and provide supervised verification agents, allowing you to deploy IAL3 assurance quickly and securely. Defining your retention and frequency strategy early is critical; as your security program matures, these rules will evolve to identify and reduce more sophisticated threat actor risk.