CJIS Compliant Software: FIPS 140-3, MFA, and Audit Rules

CJIS-compliant software is any system that stores, processes, or transmits criminal justice information in a way that satisfies the FBI Criminal Justice Information Services Security Policy. The current version, 6.0, was released in December 2024 and contains roughly 1,578 requirements organized around NIST 800-53 control families. In practice, compliance comes down to a handful of concrete areas: FIPS-validated encryption, multi-factor authentication, detailed audit logging, mobile device management, fingerprint-based personnel screening, a signed Security Addendum, and a documented incident response capability. There is no central CJIS certification stamp, so the buying agency is the one that has to confirm each piece.

Encryption: The FIPS 140-3 Deadline

The biggest active change for vendors is the encryption transition. CJIS Security Policy v6.0 requires FIPS 140-3 certified cryptographic modules for protecting criminal justice information both at rest and in transit. FIPS 140-2 certificates will not be accepted after September 21, 2026.¹ Software still running on FIPS 140-2 modules after that date falls out of compliance.

The key-length rules depend on where the data sits. For data moving across a network, the policy requires AES encryption with a symmetric key of at least 128 bits. For data stored outside a physically secure location, the bar rises to AES with at least a 256-bit key.¹ The distinction matters because “physically secure location” has a specific CJIS definition involving restricted access, visitor logs, and perimeter controls. A vendor’s cloud data center does not automatically qualify.

Vendors whose FIPS 140-3 certification is under review can use the module in the interim, but the policy expects certification to be completed. Ask whether the vendor holds a validated certificate or just a pending application.

Multi-Factor Authentication and Password Rules

CJIS v6.0 requires multi-factor authentication for every account that touches criminal justice information, whether privileged or not. The factors fall into the standard three categories: something you know (a PIN), something you have (a token or smart card), and something you are (a biometric).¹ Biometrics cannot stand alone; they must be paired with a physical authenticator.

Version 6.0 broke meaningfully with previous versions on passwords, and many existing compliance checklists are now wrong. User-chosen passwords still require a minimum length of eight characters. But mandatory periodic password rotation is gone. The policy states explicitly that “requiring routine periodic changes to memorized secrets is not recommended.”¹ Systems must instead maintain a list of commonly used, expected, or compromised passwords and reject any new password that appears on it.

The old requirement to prevent reuse of the last ten passwords is also absent from v6.0. Software built around forced 90-day rotations and password history tracking does not need to strip those features, but they are no longer part of the compliance baseline. What is required: a rate-limiting mechanism that allows no more than five failed authentication attempts on any account.¹ The system must still be capable of forcing an emergency password change when a compromise is suspected.

Audit Logging and Retention

Compliant software has to record a specific set of events automatically. That includes all successful and unsuccessful login attempts, every attempt to access, create, modify, or delete a user account, file, directory, or system resource, all password change attempts, every action taken by privileged accounts, and any attempt to access, modify, or destroy the audit log itself.¹

Audit records must be retained for at least one year, longer if needed for administrative, legal, or operational purposes.¹ If the logging system itself fails, administrators and personnel with audit responsibilities have to be alerted within one hour, logging processes restarted, and normal operations resumed only after verification. The event types selected for logging need to be reviewed and updated annually.

Personnel Screening and the Security Addendum

Anyone with unescorted access to unencrypted criminal justice information must pass a fingerprint-based background check at both the state and national level before being granted access.¹ That applies to the vendor’s developers, system administrators, database engineers, and support staff. If the person lives in a different state than the contracting agency, checks are run in both states.

A felony conviction of any kind triggers a denial. Version 6.0 does allow the requesting agency to petition the CJIS Systems Officer for a variance in extenuating circumstances, weighing the severity of the offense and how much time has passed. Misdemeanor records do not automatically disqualify someone; the CSO or a designated official reviews the offense and decides.¹

Before any private contractor or software vendor can access criminal justice information, the vendor must sign the CJIS Security Addendum. The FBI publishes an official template (Appendix H in v6.0) obligating the vendor to maintain a security program consistent with federal and state laws, the CJIS Security Policy in effect at contract execution, and all later versions.² The addendum does not lock in the policy version at signing. The vendor agrees to comply with future updates as they are released. Every contractor employee also has to receive a copy of the Addendum and the Security Policy and sign an acknowledgment. Skipping that step disqualifies the software from processing criminal justice data. During procurement, confirm that the vendor’s authorized representative has signed the addendum and that it is incorporated into the primary service agreement, not buried in a side letter.

Training Timelines Under Version 6.0

Version 6.0 tightened the training schedule. All personnel must complete security and privacy literacy training before they are granted access to criminal justice information, then repeat it annually.¹ Earlier versions allowed up to six months after initial assignment and required refreshers only every two years. Both windows are shorter now.

Role-based training adds another layer. Administrators, security officers, and developers with elevated access must complete role-specific training before authorization and annually afterward. If a security event occurs, individuals involved receive additional training within 30 days. Individual training records must be retained for at least three years.¹

Mobile Device Management Requirements

Any software accessed from a tablet or smartphone that directly touches criminal justice information requires a centrally administered Mobile Device Management solution. The MDM must support at least eleven specific capabilities:¹

Remote locking and wiping of lost or stolen devices.
Automatic wipe after a set number of failed access attempts.
Location tracking for agency-controlled devices.
Detection of rooted or jailbroken devices.
Detection of unauthorized software.
Setting and locking device configurations to prevent tampering.
Detection of unauthorized configuration changes.
Enforcement of mandatory security policies pushed to the device.
Enforcement of folder- or disk-level encryption.
Blocking unpatched devices from accessing criminal justice systems.
Isolating criminal justice information so it moves only between authorized applications and storage areas.

An exception exists for indirect access systems that do not allow transactional queries against state or national repositories. In those cases MDM is not required, though the agency still must ensure information reaches only authorized recipients. The state CJIS Systems Officer decides whether access qualifies as indirect.

Cloud-Hosted Software

Cloud deployment does not get a separate compliance track. The same requirements apply. The policy is explicit that cloud vendors can host criminal justice information as long as they meet every applicable control.¹ The practical challenge is scale. Cloud providers have thousands of employees, and each one with potential access to unencrypted data needs a fingerprint-based background check.

A common misconception is that a FedRAMP authorization satisfies CJIS. It does not. The policy warns that “additional security assurances from other authorizations such as FedRAMP, StateRAMP, SOC Type 2, etc., may be leveraged, however, they do not guarantee compliance with the CJIS Security Policy.”¹ There is real overlap (FIPS encryption, multi-factor authentication, audit logging), but CJIS has requirements FedRAMP does not cover, particularly fingerprint-based screening and the Security Addendum. Treat FedRAMP as a strong starting point, not a finish line.

When vetting a cloud provider, work through whether the environment meets the physically secure location standard, how encryption is handled at rest and in transit, what incident response procedures look like, whether the provider will allow FBI and state-level compliance audits, and how media destruction is handled when hardware is decommissioned.

Incident Response and the One-Hour Clock

CJIS v6.0 sets a tight clock on breach reporting. Personnel who discover or suspect a security incident must report it immediately, and no later than one hour after discovery.¹ If the incident is confirmed, notification goes to the CJIS Systems Officer, the state identification bureau chief, or the interface agency official.

The software itself needs to support a documented incident response plan that defines what qualifies as a reportable incident, assigns responsibilities, and describes when affected individuals or oversight bodies need to be notified. For breaches involving personally identifiable information, the plan must include an assessment of harm and mitigation steps. The plan requires annual review and approval by agency leadership. Vendors should be prepared to show that their platform actually supports these workflows, not just that a policy document exists somewhere.

How to Verify a Vendor’s Compliance Claim

Vendor marketing materials routinely claim “CJIS compliance,” but there is no formal CJIS certification the way FedRAMP issues an Authority to Operate. Compliance is assessed by the state CSO and verified through audits, not stamped by a central body. The buying agency has to confirm the vendor actually meets the requirements rather than take a sales claim at face value.

At minimum, before signing a contract, get documentation on each of the following:

A signed CJIS Security Addendum incorporated into the main service agreement.
FIPS 140-3 validated encryption, or certification pending with a completion timeline before September 21, 2026.
Multi-factor authentication enforced for all users.
Audit logging that captures the required event types and meets the one-year retention floor.
An MDM solution covering all eleven required capabilities, if mobile access is in scope.
Fingerprint-based background checks for every person with access to unencrypted criminal justice information, including cloud provider personnel.
A documented incident response plan with a one-hour reporting capability.
Evidence the platform has passed a technical security assessment.

Asking for written proof on each of these is the most reliable way to separate genuine compliance from marketing language, and it puts the vendor on notice that the agency knows what the current policy actually requires.

1
Federal Bureau of Investigation. Criminal Justice Information Services (CJIS) Security Policy
2
Federal Bureau of Investigation. Federal Bureau of Investigation Criminal Justice Information Services Security Addendum