CJIS v6.0’s Identity Requirements Are Not Waiting for 2027

The Access That Nobody Can Afford to Lose

For a law enforcement agency, a courthouse, a 911 dispatch center, or any of the private organizations that support them, Criminal Justice Information (CJI) is not a category of data. It is the raw material of the work. Without CJI, an officer cannot run a plate. A dispatcher cannot verify a warrant. A records clerk cannot process a background check. The security policy that governs CJI access is what keeps that information flowing, but it is also what turns it off when an agency or organization falls short.

And the stakes couldn’t be higher. For a small agency or business whose work depends on CJI access, a compliance failure is existential: lose the access, lose the ability to operate. That is the reality behind CJIS v6.0, and it is the reason the calendar around this policy matters now more than ever.

CJIS v6.0 Priority Tiers: Not All of Them Wait for 2027

The date most compliance officers have circled on their calendars is October 1, 2027. That date is real, but it applies to a specific subset of the modernized controls. Version 6.0 organizes requirements into four priority tiers, and only the non-Priority-1 items benefit from the phased runway to 2027.

Priority 1 controls are auditable now. Authenticator management is one of those Priority 1 areas. That reshapes the roadmap. If your agency has been mapping to a 2027 target for the whole security policy, the first useful move is to separate the Priority 1 items and address them on a tighter timeline.

“A gap assessment against Priority 1 is the practical starting point. It surfaces what the agency has, what it needs, and what it inherits from its cloud platform,” says AJ Rogers, Planet’s Managing Architect for Compliance. “Without that baseline, road mapping to 2027 is planning against the wrong deadline.”

CJIS Identity Requirements Read Like NIST SP 800-63

Open the identity section of CJIS v6.0 and it does not read like a compliance framework. It reads like a NIST identity workbook. Entropy calculations for one-time passcode authenticators. Replay resistance for authentication assertions. AAL2 assurance for personnel with system access. Bit-length minimums for credentials used from squad car laptops.

Authenticator management alone runs across, in Rogers’ exact words, “literally about 200 different considerations.” The evaluation of your identity stack under v6.0 is a technical exercise, not a checklist. Microsoft has done substantial work aligning Entra ID and the broader Microsoft 365 stack to these requirements, which reduces the burden on agencies operating in Microsoft cloud environments. Alignment is still the agency’s job but the updated platform work makes it a tractable one.

The CJIS Password Requirement That Contradicts NIST

One requirement in v6.0 deserves a moment on its own because it surprises almost every compliance officer who reads it carefully.

CJIS v6.0 requires forcing password expirations after twelve months. The federal government’s own NIST SP 800-63B identity guidance considers periodic password rotation a bad practice unless a compromise is suspected. Two federal frameworks pointing in opposite directions is not unusual. It is worth highlighting because a compliance team following newer NIST guidance can end up with a v6.0 finding for doing what NIST recommends.

According to Rogers, “The practical action is to configure the CJIS requirement explicitly rather than assume the two frameworks agree. Small point with big consequence at audit time.”

The CJIS v6.0 Shared Responsibility Model Has Real Nuance

Shared responsibility is easy to describe in the abstract. Cloud provider owns the platform. Agency owns the data and the configuration. CJIS v6.0 makes that line more specific, and where it lands depends on which cloud tier the agency is on.

Federal CJIS does not strictly require a FedRAMP-authorized cloud service, but the FBI’s personnel screening requirements make one highly recommended in practice. The FBI leaves the call to the agency, and the cloud tier the agency chooses reshapes the shared responsibility split. Agencies operating in a FedRAMP-authorized cloud like Azure Government or GCC High inherit personnel screening and certain compliance controls from the CSP. Agencies operating in a non-FedRAMP cloud like Azure Commercial pick up more of that responsibility themselves. Encryption key management is the clearest example. In commercial cloud, the agency manages the keys directly because Microsoft’s commercial data center staff are not screened against FBI requirements.

“Mapping the shared responsibility split to the specific cloud tier the agency uses is one of the more useful artifacts to have in front of an auditor,” says Rogers “It answers questions before they get asked.

A Note on “CJIS-Certified” Vendors

Vendors selling into the CJIS market often describe their products as CJIS-certified. It is worth noting that phrase has no real meaning. The FBI does not certify products, vendors, or services. It delegates audit authority to the individual state CJIS Systems Agencies.

“There is no official CJIS certification,” says Rogers. “The FBI delegated that responsibility to the states. There could be 50 different interpretations of how you go through the auditing process.”

A vendor’s product may genuinely support the technical controls CJIS requires. That is useful, and it can save an agency real work. It does not, on its own, make the agency compliant. Configuration, monitoring, and evidence at audit remain the agency’s responsibility. Procurement teams evaluating CJIS-adjacent products can save headaches later by asking vendors to describe which specific controls their product supports and how, rather than accepting the certification framing at face value.

CJIS and BYOD: The Scenario That Ends Every Conversation

Version 6.0 does not flatly prohibit personal devices from processing CJI. It just makes the path narrow. Getting BYOD right for CJI requires information exchange agreements and effectively complete configuration control over the personal device.

Now play the scenario forward. An officer enrolls their personal phone in the agency’s device management platform because the agency’s BYOD policy allows it. They do their job for two years. Then something changes. A termination. A lost device. A security incident that requires a remote wipe. The agency does exactly what the policy allows and wipes the device. The CJI is gone. So are the officer’s kids’ birthday photos, the videos of their parents, and the personal notes that were not backed up somewhere else.

The security policy allowed the wipe. The personnel and legal exposure that follows lands on the agency. This is not a hypothetical situation. It is a live conversation Planet has with agencies right now.

Rogers’ recommendation is simple: keep personal devices out of the CJI workflow. Agency-issued devices, managed by the agency, are the cleaner path. BYOD can work for other categories of work. CJI is not one of them.

State CJIS Systems Agencies Add Requirements. Read Yours.

The federal CJIS Security Policy is the baseline. State CJIS Systems Agencies can add requirements on top of it, and some do. Certain states require a FedRAMP-authorized cloud service for CJI processing. That is a state requirement, not a federal one.

Any state can layer additional restrictions. What is compliant in one state may not be compliant in another. The security policy acknowledges this directly: states can get more restrictive. They cannot get less restrictive. Compliance work built only against the federal baseline can miss the state augmentation until an audit surfaces it. Read both together.

Where Planet Can Help

There is a pattern in how CJIS conversations start. An agency reads v6.0 or hears about it from a peer. They look at their current identity posture, look at what Microsoft says is included in the platform, and hit a wall in the middle. The security policy and the technology stack are speaking different languages, and the shared responsibility split in between is where the confusion lives.

That middle is where Planet’s compliance team works. We read the security policy against the specific Microsoft stack the agency is running. Our compliance and technology teams sit on the same engagement by design, because reading the policy without the stack lens leaves gaps, and implementing the stack without the compliance lens leaves different gaps.

The starting point is almost always the same. When asked what he would tell a CJIS compliance officer today, Rogers comes back to the same recommendation he gives every customer: “I would ask them if they have performed a gap assessment from the last security policy to this one and figured out what the deficiencies are so we can create a roadmap. And that, to me, always starts off with a gap assessment.”

What’s Next

If your agency has MFA turned on and has not looked at the rest of v6.0 yet, the first useful step is to separate the Priority 1 items from the 2027 items. Priority 1 is the near-term work. Authenticator management is on that list. A gap assessment against those controls tells you what your actual exposure is and gives you a defensible baseline to plan against.

The rest is sequencing. Now is the time to build a phased roadmap against your state CSA’s requirements, not just the federal baseline. Get ahead of the 2027 controls and avoid scrambling in Q3 of 2027.

Schedule a CJIS v6.0 gap assessment with Planet’s compliance team to identify Priority 1 exposure, map your current identity posture against the modernized controls, and build a phased roadmap for your agency.