TL;DR: CJIS now requires multifactor authentication for systems that store or provide access to criminal justice information by October 1, 2024, and points implementers toward phishing-resistant methods grounded in NIST SP 800-63B, according to Axiad. The practical shift is that identity assurance, revocation, and authenticator binding now matter as much as access itself.
At a glance
What this is: This is an analysis of CJIS’s updated security policy and its requirement that systems accessing criminal justice information use phishing-resistant MFA.
Why it matters: It matters because law enforcement, courts, vendors, contractors, and other agencies that touch CJIS data now need authentication designs that hold up under modern identity attacks, not just checkbox MFA.
By the numbers:
- The updated CJIS security policy is roughly 50% new, according to the FBI/CJIS Division.
- CJIS requires multifactor authentication for systems and applications that store and provide access to criminal justice information by October 1, 2024.
- NIST SP 800-63B defines Authenticator Assurance Level 2, the assurance level CJIS references for phishing-resistant MFA.
👉 Read Axiad's analysis of CJIS phishing-resistant MFA requirements
Context
CJIS has moved the authentication discussion from generic MFA to phishing-resistant MFA, which means the control now has to withstand credential theft, not just satisfy a policy checkbox. For identity teams, that raises the bar for how people, machines, and vendors are authenticated before they can reach criminal justice data.
The governance issue is broader than law enforcement alone. Any organisation that supports CJIS-connected workflows must now align access assurance, authenticator lifecycle, and revocation processes with a policy that expects stronger proof of identity and clearer control over stolen or suspended authenticators.
Key questions
Q: How should security teams implement phishing-resistant MFA for CJIS access?
A: Start by identifying every system and user that reaches CJIS data, then replace weak second factors with cryptographic methods such as certificate-based authentication or FIDO passkeys. Make enrollment, recovery, and revocation part of the design, because phishing-resistant MFA fails when fallback paths remain easy to abuse.
Q: Why do ordinary MFA methods fall short for CJIS-connected systems?
A: Ordinary MFA can still be vulnerable to phishing, token replay, and recovery abuse, especially when the second factor is a code or push approval. CJIS pushes organisations toward methods that bind the authenticator cryptographically to the login event, which makes stolen credentials far less useful.
Q: What breaks when authenticator revocation is not governed properly?
A: If revoked, lost, or reassigned authenticators can still be used, access persists beyond the point where trust should end. That creates a direct control gap for sensitive environments, because authentication state no longer matches the organisation’s view of who should be able to connect.
Q: Who is accountable when CJIS authentication requirements are not met?
A: Accountability usually sits with the organisation that operates the system and with the teams that own identity, access, and audit evidence. In practice, that means security leaders, IAM teams, and auditors all need a shared view of which authenticator types are allowed and how suspension is enforced.
Technical breakdown
Why phishing-resistant MFA is different from ordinary MFA
Ordinary MFA can still rely on factors that attackers routinely intercept, replay, or coerce. Phishing-resistant MFA uses cryptographic proof tied to the authenticator, typically through public key infrastructure or FIDO methods, so the login ceremony resists credential capture and replay. In CJIS terms, the control is not only about having two factors, but about making the factors non-transferrable in practice. That is why NIST SP 800-63B matters here: it defines assurance in a way that distinguishes resilient authentication from weak MFA implementations.
Practical implication: validate that MFA methods are phishing-resistant, not just multi-factor on paper.
Authenticator binding and revocation in CJIS environments
CJIS references enrollment and the need to bind physical authenticators, then explicitly calls out revocation or suspension. That matters because authentication assurance fails when the authenticator lifecycle is treated as a one-time deployment rather than a governed object with state changes. If a smart card, token, or device is not revocable at the identity layer, the policy cannot reliably contain loss, theft, or role change. In regulated environments, binding and revocation are part of the access control design, not administrative afterthoughts.
Practical implication: treat authenticator issuance, suspension, and replacement as controlled lifecycle events.
Certificate-based authentication and FIDO in existing identity stacks
The article frames certificate-based authentication and FIDO passkeys as the path to phishing resistance, but the architectural point is that strong authentication has to fit into existing identity providers and access workflows. Certificate-backed login depends on PKI trust chains, while FIDO depends on device-bound cryptographic assertions. Both reduce reliance on passwords and OTPs, but neither is operationally useful if enrollment, recovery, and administration are fragmented across teams. The implementation challenge is integration depth, not just technology choice.
Practical implication: map certificate and passkey deployment to your current IdP, PKI, and recovery processes before rollout.
Breaches seen in the wild
- Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
- MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CJIS is forcing a shift from MFA compliance to authenticator governance. The article is not really about adding another login factor. It is about whether an organisation can prove that the factor is resistant to phishing, can be revoked, and can be managed across people and non-human actors that touch CJIS data. Practitioners should read this as a governance requirement, not an authentication feature request.
Phishing-resistant MFA becomes the control boundary when identity attacks are the dominant entry path. CJIS is acknowledging that passwords and weak second factors no longer define acceptable risk for criminal justice access. That aligns with the broader NIST view that assurance must be cryptographic, not merely procedural. Security teams should expect auditors to focus on method quality, not just MFA presence.
Authenticator lifecycle is now part of access control, not a side process. The policy language on enrollment, binding, suspension, and revocation shows that credentials are only as trustworthy as their offboarding state. This is where many programmes still fragment ownership between IAM, endpoint, and operations teams. Practitioners should treat authenticator state as governed identity data.
Phishing-resistant authentication for vendors and contractors matters as much as for employees. CJIS-connected ecosystems include non-criminal justice agencies, suppliers, and other third parties, which means the access problem extends beyond the agency boundary. That makes federation, device binding, and recovery design part of third-party risk management. Practitioners should not scope CJIS controls to internal users only.
Credential proof strength is the real control in zero-trust access to sensitive public-sector data. Zero trust only works when identity verification survives real attacker behaviour. CJIS is effectively narrowing the acceptable trust surface by demanding stronger authenticators and clearer suspension controls. Practitioners should align zero-trust claims with authenticator quality, not with network segmentation alone.
From our research:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
- For a broader view of breach patterns and control failures, review 52 NHI Breaches Analysis.
What this signals
Phishing-resistant authentication is becoming the baseline for regulated access, not an advanced option. CJIS is one of the clearest examples of a policy environment where simple MFA is no longer enough, and similar expectations will continue to spread wherever access protection is tied to high-consequence data. Teams should expect stronger scrutiny of recovery, revocation, and authenticator binding as auditors mature their questions.
Identity programmes that still separate authentication from lifecycle governance will struggle to evidence control. The practical problem is not only choosing a stronger method. It is proving that issuance, suspension, replacement, and recovery are all governed as one chain across internal staff, contractors, and external partners.
Zero trust claims will increasingly be judged by authenticator quality. If an organisation cannot show that access is backed by phishing-resistant proof and revocable credentials, its zero-trust story remains incomplete. That will matter in public sector environments first, but the governance pattern is portable to any sensitive data estate.
For practitioners
- Inventory every CJIS-connected authentication path Map all systems, users, vendors, and contractors that can reach criminal justice information, then identify which paths still rely on non-phishing-resistant MFA. Include recovery flows and service desks, because a weak fallback can undo a strong primary factor.
- Separate phishing-resistant methods from legacy MFA Classify each authenticator by whether it meets phishing-resistant expectations under NIST SP 800-63B, then phase out OTP-only and push-based methods where CJIS data access is in scope. Use this review to drive remediation priorities by application, not by user population alone.
- Govern authenticator binding and revocation as lifecycle events Require explicit issuance, binding, suspension, and replacement workflows for tokens, smart cards, passkeys, and certificates. Tie those events to joiner-mover-leaver processes so access changes and authenticator state changes stay consistent.
- Test how recovery weakens strong authentication Review reset, backup, and exception paths for any place a help desk or administrator can re-enable access without a phishing-resistant step. The strongest method loses value if the recovery path is easier to abuse than the login path.
Key takeaways
- CJIS is turning phishing-resistant MFA into an access prerequisite for criminal justice data, which raises the governance bar beyond traditional MFA rollouts.
- The policy’s focus on binding, suspension, and revocation shows that authenticator lifecycle is now part of identity assurance evidence, not just administration.
- Teams that govern CJIS access should align authentication strength, recovery design, and auditability before the October deadline becomes an operational gap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL2 | CJIS points readers to NIST assurance guidance for phishing-resistant MFA. |
| NIST CSF 2.0 | PR.AC-1 | Authentication and credential assurance are core access control functions here. |
| NIST Zero Trust (SP 800-207) | CJIS-style assurance aligns with zero-trust identity verification principles. |
Treat authenticator quality as part of the trust decision before granting access to sensitive systems.
Key terms
- Phishing-resistant MFA: A multifactor authentication method that is designed to resist phishing, replay, and credential interception. It relies on cryptographic proof tied to the authenticator so the secret is not something an attacker can easily copy and reuse in another session.
- Authenticator lifecycle: The governed sequence of issuing, binding, using, suspending, revoking, and replacing an authenticator. In strong identity programmes, lifecycle control is as important as the factor itself because trust changes when a token, card, passkey, or certificate changes state.
- Authenticator Assurance Level 2: A NIST identity assurance level that describes stronger authentication requirements suitable for higher-risk access. It commonly uses cryptographic authenticators and helps distinguish resilient login methods from weaker MFA patterns that still depend on shared secrets or easily replayed codes.
Deepen your knowledge
Phishing-resistant MFA and authenticator lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning access controls to CJIS-style assurance requirements, it is worth exploring.
This post draws on content published by Axiad: New CJIS Security Policy Changes the Game for MFA for Criminal Justice Organizations. Read the original.
Published by the NHIMG editorial team on 2025-07-16.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org