Meeting the CJIS MFA requirement on a small-agency budget

Sooner or later, every small agency’s CJIS audit questionnaire asks some version of this:

Does your agency have Advanced Authentication on user logins for any systems capable of accessing, storing, or processing CJI?

That’s the identification and authentication control, IA-2, and it isn’t optional anymore. Multifactor authentication has been an auditable, sanctionable requirement since October 1, 2024. The modernized policy (versions 6.0 and 6.1) requires it for both regular and administrative accounts, whether the login happens at the keyboard, over the network, or remotely.

Plenty of agencies already have some MFA, usually on email or a state web portal. The trouble is that the question isn’t about some systems. It’s about every system that can access, store, or process CJI. That’s where the gaps hide.

Figure out every place someone logs in

Start with the CJI environment you scoped for the audit (see getting ready for a CJIS technical security audit) and list every login that touches it:

• Windows logon on each workstation that can reach CJI, including dispatch consoles and records terminals
• Servers that store CJI, including console logons and Remote Desktop
• The CJI applications themselves: records management, jail management, and state portals
• VPN and remote access, including in-car laptops and any remote support tools your IT provider uses
• Administrative access: domain admin accounts, firewall management, hypervisors
• Local accounts that can still log in, including the one someone made years ago “just in case”

If a CJI application has its own MFA but the Windows session in front of it doesn’t, and CJI can land on that workstation’s disk, you probably still have a gap. Ask your CSA how they view it for your setup.

What counts as a second factor

The policy points to NIST’s Authenticator Assurance Level 2 (AAL2): two different factors, from two of the three categories (something you know, have, or are), using authenticators that meet federal cryptographic standards.

In practice, these are the usual options:

• Authenticator app push or codes (Duo, Microsoft Authenticator, and similar). Common and affordable. Turn on number matching so users can’t approve a push they didn’t start.
• Hardware security keys (FIDO2/YubiKey-style). Strong, fast, and phishing-resistant. They’re a good fit for shared or high-turnover stations where a personal phone isn’t practical.
• Smart cards, if the agency already has badge infrastructure that supports them.
• Windows Hello for Business, which ties a PIN or biometric to the specific device. It’s often a good fit in Microsoft-heavy environments, but confirm your CSA accepts your configuration.

Avoid building your answer on text-message codes. NIST treats SMS as a restricted authenticator, and it’s the easiest one to intercept or socially engineer. If a vendor only offers SMS, ask what else they support.

Small-agency approaches that work

MFA for Windows logon and RDP. Products like Duo’s Windows Logon integration add a second factor to the Windows sign-in screen and to Remote Desktop. This covers the gap most small agencies actually have: the workstation itself. It’s usually licensed per user, installs as an agent, and can be rolled out a few machines at a time.

Hardware keys at shared stations. Dispatch and front-counter workstations are often shared by several people across shifts. Personal phones may not be allowed on the floor, and shared logins break the “uniquely identified” part of the same control. A key on each person’s key ring, used with their own account, solves both problems.

Put remote access behind MFA first. If budget forces you to phase it, start with anything reachable from outside: VPN, remote support tools, and RDP. Those are the logins attackers try first.

Don’t forget your own accounts. If you’re the contractor, your admin accounts and your remote support tool are in scope too. An agency with MFA on every user but none on the IT provider’s remote access has handed the auditor an easy finding.

Plan for the edge cases before rollout

These are the things that break MFA projects in small shops:

• Offline logins. Decide what happens when a laptop can’t reach the MFA service. Most products offer offline codes or cached factors. Configure them deliberately rather than leaving a fail-open default.
• Break-glass accounts. Keep an emergency admin account for when the MFA service is down. Document it, protect the credentials, and tell the auditor it exists.
• Service accounts. Accounts that run software shouldn’t be able to log in interactively. Lock them down and document them, rather than trying to MFA them.
• Lost or forgotten phones and keys. Write down how someone gets back in at 2 a.m. on a Saturday, and who is allowed to approve it.

What to hand the auditor

Answering “yes” is easy. Being able to prove it is what matters. Keep these in your audit folder:

• A list of every CJI login point and how each is protected
• Screenshots or configuration exports showing MFA is enforced, not just available
• The enrollment list, showing every CJI user is enrolled
• A written procedure for enrollment, lost devices, and break-glass access
• For anything not covered yet, a dated remediation plan with an owner

A partial “yes” with a clear plan is a much better conversation than a “yes” that falls apart when the auditor asks to see a login.

Where to confirm the details

The requirement lives in the Identification and Authentication section of the CJIS Security Policy. Your state CSA has the final say on what satisfies it in your environment, so when you’re choosing between products, it’s worth a short email to confirm before you buy.

All articles