TL;DR: FBI guidance says criminal VPN infrastructure has been used by at least 25 ransomware groups and maps to proxy use, remote services, valid accounts, brute-force, and network discovery, underscoring that CJIS-regulated access must be both trusted and usable, according to Imprivata. Shared devices, remote support, and legacy workflows now need identity-aware controls, because blocking bad infrastructure alone does not prove who should be trusted.
NHIMG editorial — based on content published by Imprivata covering FBI guidance on criminal VPN abuse and CJIS access control
By the numbers:
- The FBI says the criminal VPN service has been used by at least 25 ransomware groups.
Questions worth separating out
Q: What breaks when remote access is trusted because it looks familiar?
A: When remote access is trusted because it resembles normal VPN traffic, agencies lose the ability to distinguish legitimate operational use from attacker activity.
Q: Why do shared workstations make CJIS access control harder?
A: Shared workstations make CJIS access control harder because the device is reused while the identity trail often is not.
Q: What do security teams get wrong about VPN-aware access controls?
A: Security teams often treat VPN-aware access as proof that a session is safe.
Practitioner guidance
- Separate shared access from shared credentials Use individual identities for every officer, dispatcher, and support worker even when the endpoint is shared.
- Verify trust before reaching CJIS systems Make remote access decisions based on identity, device state, session context, and location anomalies, not only on whether a VPN connection exists.
- Limit and review vendor remote access lifecycles Give third-party support only the minimum access required, monitor every privileged session, and revoke access when the support relationship ends.
What's in the full article
Imprivata's full post covers the operational detail this post intentionally leaves for the source:
- Workflow-specific guidance for shared workstations, mobile data terminals, and legacy public safety applications
- Practical interpretation of FBI mitigations such as MFA, VPN-aware access controls, and session monitoring
- Examples of how agencies can balance CJIS compliance with fast, mission-critical access
- Imprivata's view on simplifying secure access without introducing unnecessary login friction
👉 Read Imprivata's analysis of FBI guidance on CJIS access control and criminal VPN abuse →
CJIS access control gaps: are your trusted workflows keeping up?
Explore further
Trusted access breaks down when agencies treat network reachability as proof of legitimacy. The article shows that criminal VPN infrastructure can sit inside the same remote-access patterns agencies use for vendor support, mobile work, and legacy systems. That is a CJIS governance failure, not just a traffic problem. The implication is that access assurance must be based on identity, device, and session evidence, not on whether the path looks familiar.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: Who is accountable when third-party remote access is overused in public safety environments?
A: The agency remains accountable when third-party remote access is overused, even if the support relationship is legitimate. CJIS obligations do not move to the vendor. Agencies need lifecycle controls, session monitoring, and removal of access when the operational need ends, otherwise accountability and auditability erode.
👉 Read our full editorial: CJIS access control gaps exposed by criminal VPN abuse