State and local cybersecurity starts with visible controls
A control that exists only in a policy document won't help much when someone asks who can reach Criminal Justice Information (CJI), how access is protected, or what evidence shows the control works. State and local cybersecurity teams need both working safeguards and a way to demonstrate them without turning every audit request into a scavenger hunt.
That’s the useful frame for CJIS v6.1: organize identity, account management and logging as operating practices, not isolated checkbox projects. The BleepingComputer article that informs this guide is sponsored content written by Specops Software, so treat its specific interpretations as secondary commentary—not the policy itself. This distinction matters. CompTIA’s cybersecurity basics and Fortinet’s discussions of types, threats and best practices can help explain the wider discipline, but neither replaces CJIS requirements or guidance from your CJIS Systems Agency (CSA).
What cybersecurity means for an agency
Cybersecurity is the work of protecting systems, networks and information from unauthorized access, disruption or misuse. For a public agency, that broad purpose becomes concrete: protect sensitive information, control who can use systems, notice suspicious activity, and respond in a way that preserves service and evidence.
CompTIA’s “What Is Cybersecurity | Types and Threats Defined” and Fortinet’s “What is cybersecurity? Types, threats & best practices” are useful conceptual references for the field’s range. Common categories include securing endpoints and networks, protecting applications and data, managing identity, and preparing for threats such as stolen credentials, malicious software or unauthorized access. CISA’s Cybersecurity Best Practices and Infrastructure resources likewise offer a broader public-sector context for reducing risk. These are foundations, not a checklist that independently establishes CJIS compliance.
For a state or local agency, practical cybersecurity isn’t just buying another tool. It’s knowing which systems handle CJI, limiting access to legitimate work, making authentication meaningful, retaining useful records, and assigning owners to the work. That’s what turns abstract “best practices” into a program people can operate.
Make multifactor authentication complete
The BleepingComputer source says CJIS v6.1 controls IA-2(1) and IA-2(2) require multifactor authentication for privileged and non-privileged accounts across local, network and remote access. The operational challenge is coverage: an agency may have MFA on its main cloud services while older applications, administrator paths or remote access remain outside the process.
Start with an inventory of access paths and accounts, then identify where a second factor is actually enforced. Include administrative access and legacy applications in the review. Plan how staff enroll, replace and revoke authenticators; otherwise a lost device or staff departure can leave an awkward gap. Phishing-resistant options such as FIDO2 security keys are worth evaluating, but method selection should fit the systems and policy requirements involved.
MFA isn’t a one-time deployment. New systems, changed workflows and exceptions can quietly erode coverage. Recheck configurations when access changes and record what was reviewed, what remains excluded, and who owns the exception. Those records make the security decision legible later.
Keep accounts and privileges current
The source emphasizes maintaining an inventory of user, administrative, service and temporary accounts, applying least privilege, and separating administrative privileges from everyday work. These are sound operational priorities because access tends to linger when people change roles or leave.
Build a reliable joiner-mover-leaver process with system owners. Make provisioning and removal prompt, and include service and emergency accounts rather than focusing only on ordinary employee logins. For each account, be able to answer who owns it, why it exists, what it can reach and when it was last reviewed.
The BleepingComputer article states particular timelines for temporary, emergency and inactive accounts and recommends at least annual privilege review. Because those exact timings are not established here against the primary policy, don’t turn the article’s figures into an agency mandate without checking. Use the policy and your CSA to confirm the rules that apply. Independently of the precise schedule, more frequent review may be appropriate for sensitive access or when roles change quickly.
Treat password details as a verification task
Password requirements deserve careful handling. The secondary article gives a minimum length, compromised-password screening practices, login-attempt limits and an annual change detail. Those are claims to verify, not a substitute for reading the applicable policy. The available secondary sources do not verify exact CJIS deadlines, password rules, or audit frequency against the primary policy; confirm the applicable requirements in the policy and with your CSA.
Once the requirements are confirmed, translate them into settings staff can actually maintain. Check password policy configuration, account lockout behavior, and how the agency identifies exposed or reused credentials. Encourage unique passwords and passphrases, and consider an approved password manager where appropriate. Document how exceptions are approved and how a suspected compromise triggers a reset or other response.
Avoid treating password changes as a ritual detached from risk. The relevant policy may prescribe specific conditions; follow those, and make sure administrators know which settings enforce them. The point is dependable, verifiable account protection—not an informal rule copied from a vendor article.
Logging is useful only when it can answer questions
Collecting logs is a beginning, not an outcome. The source recommends checking coverage for systems handling CJI, capturing who did what and when and the result, reviewing records, and protecting them against tampering. Centralizing logs in a security information and event management (SIEM) platform can help correlate activity, if the agency has the capacity to operate it well.
A practical review asks whether the records support real questions: which account accessed a system, what action occurred, when it happened, and whether it succeeded. Decide who reviews alerts and how unusual events are escalated. Keep the process proportionate; a pile of unreviewed events is not a monitoring program.
Protect the records and document retention and access decisions according to the applicable policy. Test that logs are available when needed, rather than assuming collection equals evidence. A short exercise—trace a sample event from source system to review—can expose gaps in configuration, ownership or retrieval before an incident or assessment does.
Build audit readiness into routine work
The sponsored article describes audits at least every three years and discusses evidence such as MFA configurations, access reviews, logs, policies, training and assessment results. Since the article is secondary commentary and does not verify audit frequency against the primary policy, confirm the schedule and any associated requirements with the policy and your CSA.
The operational lesson stands without relying on an unverified interval: keep evidence as controls operate. Assign an owner to each control, note where its evidence lives, and refresh records when configurations or responsibilities change. Track weaknesses and remediation decisions, including who is accountable and what remains open. The source also points to remediation planning; verify any exact review cadence in the governing material.
Internal checks can be modest and still valuable. Sample account records, inspect MFA coverage, follow a log event through review, and confirm that evidence can be retrieved. Record findings and resolve the ones that matter. An orderly evidence folder is helpful; a routine that produces accurate evidence is better.
A careful path to stronger CJIS readiness
For state and local cybersecurity teams, the most useful next step is usually a short, owned review—not a sweeping promise to fix everything at once. Map systems that handle CJI, list access paths, identify account owners, and check that logging is producing usable records. Prioritize obvious gaps and assign someone to each follow-up.
Separate verified policy obligations from local implementation choices. Requirements belong in the policy and CSA guidance; recommendations such as using phishing-resistant MFA, centralizing logs, or reviewing high-risk access more often are operational options to assess against the agency’s environment. CISA’s best-practice materials can inform general resilience, while CompTIA and Fortinet explain broader cybersecurity concepts. None should be mistaken for a CJIS policy source.
That separation is not red tape. It keeps a team from building a program around a sponsored article’s interpretation, while still letting practical advice prompt useful questions. Keep the evidence close to the work, revisit controls when systems change, and ask the CSA when the authoritative answer isn’t clear.
Sources and scope
The CJIS-specific recommendations and quoted control references above are drawn from the verified BleepingComputer sponsored article, written by Specops Software: CJIS v6.1 compliance priorities for agencies. Its product discussion is vendor material and is not an endorsement. The official FBI policy URL was present in the research references, but the fetched page yielded only a brief response and did not provide usable policy text for verification. This guide therefore avoids presenting the secondary article’s exact timing and password details as independently confirmed policy.
The CompTIA, Fortinet and CISA titles mentioned above are conceptual context supplied in the coverage brief, not independently verified sources for particular CJIS requirements. Consult current official policy and your CSA for binding requirements.