How to Maintain CJIS Compliance When Your Agency Moves to a Browser-Based Portal

For law enforcement agencies evaluating a move from installed portal software to a browser-based platform, CJIS compliance is often the first concern. And it should be. Any system that accesses, transmits, or stores Criminal Justice Information (CJI) must meet the security requirements outlined in the FBI CJIS Security Policy.

The good news is that moving to a browser-based portal doesn’t change the CJIS compliance requirements your agency must meet. The same policy areas apply whether the software is installed locally or accessed through a browser. What changes is how those requirements are implemented, and in many cases, a browser-based architecture makes compliance easier to maintain, not harder.

This article walks through the specific CJIS policy areas that IT teams should verify when moving to a browser-based portal, what to look for in a vendor, and where the compliance advantages of this architecture actually show up in practice.

What the CJIS Security Policy Requires for Browser-based Platforms

The CJIS Security Policy (currently version 5.9.5, released July 2024) covers 19 policy areas that apply to any system handling CJI. When an agency moves from installed portal software to a browser-based platform like Portal XL, the same 19 policy areas apply. The agency hosts and controls its own environment. PsPortals provides the software, not the infrastructure.

The policy does not prohibit hosted or browser-based access to CJI. The policy does not prohibit browser-based access to CJI. What matters is that the security controls are in place regardless of how the software is delivered.

The core principle is straightforward: the agency retains full control over how CJI is protected. Portal XL is deployed within government-controlled infrastructure. The vendor must sign the CJIS Security Addendum, and the agency must verify that security controls are in place before any CJI flows through the new system.

Encryption Requirements for CJI in Browser-Based Portals

Encryption is one of the most scrutinized areas during any CJIS audit. The policy requires that CJI be encrypted at every stage:

• In transit: All data exchanged between the agency and the portal must be encrypted using TLS 1.2 or higher. This applies to every query, response, and message that moves between the browser and the server.

• At rest: CJI stored on the server must be encrypted in a way that prevents unauthorized access, even if the storage infrastructure is compromised. Agencies focused on

law enforcement data protection should confirm that their vendor uses FIPS 140-2 or FIPS 140-3 validated encryption modules for data at rest.

• In processing: When CJI is decrypted for active processing, the environment must be secured so that vendor personnel cannot access unencrypted data. This is typically achieved through hardware security modules (HSMs) or confidential computing environments.

The encryption key control point is critical for maintaining overall CJIS compliance. Under the CJIS Security Policy, the agency must retain control over the cryptographic keys used to protect CJI. The vendor should not have the ability to decrypt CJI independently. This is a non-negotiable requirement, and it should be verified before any data migration begins.

Authentication and Access Controls

The CJIS Security Policy requires multi-factor authentication (MFA) at Authenticator Assurance Level 2 (AAL2) for any user accessing CJI. In a browser-based portal, CJIS-compliant authentication is handled centrally on the server rather than configured on each individual device.

This centralized approach has practical advantages for law enforcement IT teams:

• MFA policies are enforced uniformly across all users and devices. There’s no risk of one workstation being configured differently from another.
• Session management rules, including automatic lockout after inactivity, apply consistently regardless of whether an officer logs in from a desktop, MDT, or shared terminal.
• Role-based access controls (RBAC) are defined once at the server level. Officers, dispatchers, investigators, and administrators each see only the data and functions relevant to their role.
• Failed login lockout policies protect against brute-force attempts uniformly, without needing per-device configuration.

For agencies currently managing authentication across dozens of installed endpoints, a browser-based portal consolidates these controls into a single management layer. That’s less configuration work for IT and a more consistent security posture for the agency.

Audit Logging and Compliance Documentation

One of the most significant compliance advantages of a browser-based portal is centralized audit logging. Every query, login, data access, and user action is recorded in one system. When a CJIS compliance audit requires documentation of who accessed what CJI and when, the logs are already consolidated.

With installed software, audit trails are often scattered across individual workstations and endpoints. Assembling a complete picture of user activity during an audit requires pulling data from multiple sources, which is time-consuming and prone to gaps.

A browser-based architecture resolves this by design. All user activity passes through the server, so the audit trail is inherently complete. This makes it significantly easier for IT teams to demonstrate compliance and for CJIS coordinators to produce the documentation auditors expect.