CJIS MFA Requirements: What the Policy Says, What Auditors Check, and How to Close the Legacy App Gap

The deadline is behind us. Since October 1, 2024, multi-factor authentication for access to Criminal Justice Information has not been a recommendation or a roadmap item. It is an auditable requirement of the CJIS Security Policy. If you are reading this in 2026, the question has shifted from when do we need MFA? to the audit is coming, and there is a system we could not cover.

That system is almost never email or the VPN. It is the legacy web application: the records portal, jail management screen, court case system, background-check tool, or partner-facing portal that touches CJI, runs on a local login, and has no native MFA.

This guide explains what the CJIS MFA requirements say, who is in scope, what auditors look for, and how agencies can put MFA in front of legacy web applications without rewriting them.

What the CJIS Security Policy Requires

The MFA requirement entered the policy in version 5.9.2 under Policy Area 6, Identification and Authentication. The policy term is advanced authentication. NIST's NCCoE public-sector MFA session describes the October 1, 2024 enforcement date for protecting access to Criminal Justice Information. The authoritative policy documents live in the FBI CJIS Security Policy Resource Center.

The mechanics are straightforward, but the operational scope is broad:

• MFA means at least two of three factors: something you know, something you have, and something you are.
• The policy does not mandate one MFA product. It points agencies toward NIST SP 800-63 Digital Identity Guidelines for authenticator standards, which gives agencies flexibility in implementation.
• The requirement follows the data, not the device. Any application that stores, processes, displays, or provides access to CJI needs protected authentication, including web applications that sit behind other network controls.
• Oversight is real. Formal audits, annual self-reporting, and state CJIS Systems Agency oversight make MFA coverage a control that must be demonstrable, not just planned.

The CJIS 6.x transition raises the bar

The FBI has also moved the policy into the CJIS 6.x line, which reorganizes controls around NIST SP 800-53 Rev. 5. The FBI Resource Center currently includes CJIS Security Policy v6.1, dated June 25, 2026. Audit baselines and transition timing can vary by state, so confirm the exact baseline with your CSA.

For MFA, the practical direction is not softer. Agencies should expect more emphasis on privileged and non-privileged accounts, continuous governance, evidence, and complete CJI access-path coverage. An MFA gap on a legacy CJI web application is a problem under today's audit and tomorrow's control model.

Who Is in Scope

CJIS obligations extend to every entity that touches Criminal Justice Information: municipal and county law enforcement, sheriff's offices, courts, corrections and jail operations, prosecutors, dispatch, non-criminal-justice agencies that access CJI for licensing or employment screening, and the vendors or contractors that build and host their systems.

If an organization queries, stores, displays, or administers CJI, the access path is in scope for CJIS identification and authentication requirements.

What Non-Compliance Can Cost

The risk is not just a finding on an audit report. CJIS non-compliance can lead to monetary sanctions and, in the worst case, loss of access to FBI CJIS systems and data such as NCIC and III. For a public-safety agency, losing access to CJIS data is an operational crisis.

Auditors generally expect agencies to demonstrate MFA or document the remaining gap as a formal risk with a dated remediation plan. Two years after the October 1, 2024 date, it is on the roadmap is getting harder to defend.

Where the CJIS MFA Gap Usually Concentrates

Most agencies covered the obvious systems first: email, VPN, modern SaaS, privileged admin access, and the state connection. The remaining gaps tend to sit in applications that were hardest to retrofit:

• Records management (RMS) and jail management (JMS) web interfaces with their own local logins.
• Court case management and e-filing systems used by clerks, prosecutors, courts, and partner agencies.
• Background-check, licensing, and applicant-screening portals run by non-criminal-justice agencies.
• Vendor-hosted or homegrown web tools that query CJI but were built before MFA was expected.
• Partner and cross-agency web access where a neighboring agency, contractor, or vendor reaches the application through a shared or local account model.

These systems share the same profile: browser-based, business-critical, no native MFA support, and no practical path to modification before the audit. The vendor roadmap does not match the audit calendar, or the application team no longer has the source code. That is the legacy app gap.

How to Add MFA to CJI Web Applications Without Rewriting Them

Datawiza Access Proxy puts an MFA enforcement layer in front of existing web applications. It does not require code changes to the application, a vendor release cycle, or software installed on the application server.

Two modes cover the situations agencies actually face.

Mode 1: Built-in MFA, no identity provider required

Many smaller agencies, county departments, and partner user populations do not run Microsoft Entra ID or Okta for every person who touches CJI. With Datawiza built-in MFA, users keep signing in with the existing application username and password. After that application login, Datawiza enforces an MFA challenge before the user can access the protected application.

There is no identity-provider project as a prerequisite, no identity mapping, and no user migration. For an audit finding or cyber-insurance remediation deadline, this is often the fastest path from uncovered legacy app to enforced MFA.

Mode 2: Identity provider integration

If the agency or county IT team already runs Microsoft Entra ID, Okta, Ping, Cisco Duo, or another preferred identity provider, Datawiza can integrate with that IdP and put the legacy CJI application behind the same SSO and MFA policy as the rest of the environment.

In this model, the identity provider remains the MFA authority and Datawiza extends that policy to applications that could not integrate before. This is especially useful where Duo already has a strong public-safety footprint: Duo handles the MFA decision, and Datawiza becomes the access layer that brings the legacy web application into scope.

In both modes, authentication activity is logged. That gives agencies per-application evidence for CSA audits, annual self-reporting, and remediation documentation.

Preparing for the CJIS MFA Audit

1. Inventory every application that touches CJI. Include vendor-hosted, partner-facing, and internal web applications, not only the main RMS or VPN.
2. Mark MFA status per application. The statement the VPN has MFA does not answer how the records portal authenticates a user who is already inside the network.
3. Close gaps at the access layer where apps cannot be modified. Deploy the proxy in front of the web application, choose built-in MFA or IdP mode, and pilot before cutover.
4. Capture evidence. Keep MFA policy configuration, screenshots or demos of the challenge, and application-specific authentication logs.
5. Document remaining exceptions. Use formal risk documentation with dated remediation plans where a gap cannot be closed immediately.

FAQ

What are the CJIS MFA requirements?

CJIS Security Policy Area 6 requires multi-factor authentication, also called advanced authentication, for access to Criminal Justice Information. MFA means at least two of three factors: something you know, something you have, and something you are. The requirement entered the policy in v5.9.2 and became sanctionable and subject to audit on October 1, 2024.

Is the CJIS MFA deadline over?

Yes. The enforcement date was October 1, 2024. Since then, missing MFA on CJI access paths can become an auditable, sanctionable finding.

What changed in CJIS 6.0 and 6.1 for MFA?

The CJIS 6.x policy line reorganizes the policy around NIST SP 800-53 Rev. 5 control families and increases the emphasis on demonstrable governance. MFA remains required, and agencies should expect more scrutiny across privileged and non-privileged accounts, continuous enforcement, logging, and complete application coverage.

Does CJIS require a specific type of MFA?

No. CJIS defines the factor categories and points to NIST digital identity guidance for authenticator standards. Authenticator apps, security keys, smart cards, and biometrics can all be viable depending on the agency environment and CSA guidance.

How do we add MFA to a legacy application that stores CJI?

Put MFA at the access layer. An access proxy in front of the application can enforce MFA without code changes. Datawiza can do this with built-in MFA after the existing application login, or through an identity provider such as Entra ID, Okta, Ping, or Duo.

Do vendors and contractors need CJIS MFA too?

Yes. The requirement follows the data. Contractors, vendors, and non-criminal-justice agencies that access CJI are in scope for the same identification and authentication requirements, and agencies remain accountable for those access paths.

The Bottom Line

The CJIS MFA mandate is past its deadline, audits are active, and the remaining findings often cluster around legacy web applications that could not take MFA natively. Enforcing MFA at the access layer can close that gap quickly, with or without an identity provider, and produce the evidence trail your CSA audit and annual self-report require.

If an RMS, court system, or CJI portal is the open item on your audit response, book a demo. Bring the application and your current identity setup, and we will walk through the exact flow. For the broader pattern, see adding MFA to legacy apps without code changes.