DEV Community: Hans Study

Active Directory for Genetec Security Center

Hans Study — Mon, 26 Oct 2026 20:04:29 +0000

Active Directory Integration, Authentication Flow

Security Desk

Operator Workstation

Web Client

Browser

Config Tool

Admin Workstation

Kerberos / LDAP →

Active Directory

Domain Controller

← Auth token + group membership

Directory Server

Security Center

Group → Role mapping

Archiver · Access Manager

Service Accounts via AD

AD handles authentication. Security Center uses group membership to assign roles and access privileges.

If you are running a multi-server Genetec Security Center deployment without Active Directory, you are making everything harder than it needs to be. I see this regularly. Environments with a dozen servers, multiple client workstations, hundreds of cameras, and all of it managed through local accounts. Passwords shared across systems. No centralized policy enforcement. No reliable audit trail that ties actions to specific users. No time synchronization that you can trust.

Local accounts scale poorly. They are maintained inconsistently. When an operator leaves, their access has to be revoked on every system individually. When a password needs to change, it changes on some systems and gets forgotten on others. When something goes wrong and you need to reconstruct who did what, the answer is “someone logged into the shared admin account.”

Active Directory solves all of that. It also introduces dependencies and configuration requirements that, if missed, cause authentication failures that are difficult to diagnose. This post covers the AD integration for Genetec Security Center environments: what it requires, how to set it up, and what to watch for. AD integration is one of the standard items reviewed during a Genetec Health Check; broader scope around the Genetec stack lives under Genetec consulting.

Prerequisites

Before integrating Genetec with Active Directory, the following must be in place:

Domain membership. The Genetec servers must be domain-joined. This is a prerequisite for Kerberos authentication, which is the preferred authentication method for AD-integrated Genetec environments. Attempting to configure AD authentication without domain-joining the servers will result in fallback to NTLM, which has known weaknesses and should not be relied on in environments where Kerberos is available.

Time synchronization. Kerberos authentication requires that the time difference between the Genetec servers and the domain controller is under 5 minutes. In practice, keep it under 2 minutes. A time skew that exceeds the Kerberos tolerance causes authentication failures that are cryptic to diagnose if you do not know to look for them. Configure all Genetec servers to synchronize time from the domain hierarchy. In environments with multiple sites, verify that the time synchronization path goes through the domain hierarchy and not through an independent NTP source that may drift relative to the domain.

DNS resolution. The Genetec servers must be able to resolve the fully qualified domain name of the domain controllers. Use the domain’s own DNS servers as the primary DNS for Genetec servers. Using external DNS (8.8.8.8, 1.1.1.1) as the primary DNS for domain-joined servers creates intermittent authentication problems when those servers cannot resolve domain resources.

Active Directory Users and Computers access. You will need permission to create Organizational Units, security groups, and service accounts in AD. Coordinate with the domain administrator before starting the configuration.

Organizational Unit Structure

Create a dedicated OU for Genetec-related AD objects. This keeps Genetec objects organized, makes Group Policy application easier to scope, and makes it straightforward to identify everything related to the Genetec deployment in a single location.

Suggested structure:

OU=Physical Security
  OU=Servers
    [Genetec server computer accounts]
  OU=Workstations
    [Genetec client workstation accounts]
  OU=Service Accounts
    [Genetec service accounts]
  OU=Security Groups
    [Genetec role groups]

Apply Group Policy to the Physical Security OU for settings specific to Genetec servers and workstations. This includes Windows Firewall rules for Genetec ports, exclusion paths for Genetec processes in Windows Defender, and any performance-related OS settings. Keeping these in a dedicated OU means they do not affect general-purpose servers and can be modified without touching broader domain policy.

Service Accounts

Genetec roles communicate with each other and with the directory using service accounts. Create dedicated service accounts for the Genetec environment rather than using the built-in local system account or a shared general-purpose account.

Create a service account for each Genetec role that requires one:

GSC-SVC-DIRECTORY: Account used by the Directory role
GSC-SVC-ARCHIVER: Account used by Archiver roles
GSC-SVC-ACCESSMGR: Account used by the Access Manager role
GSC-SVC-SQL: Account used by SQL Server for the Genetec database

Configure these accounts with passwords that do not expire (service accounts do not interactively log in, so password expiration causes service failures rather than prompting for a change). Use strong, randomly generated passwords and store them securely. Restrict these accounts to log on only as a service, they should not be usable for interactive login. This is one of the hardening baselines that gets skipped most often in deployments that pass commissioning.

If your environment’s security policy requires password rotation on service accounts, use Group Managed Service Accounts (gMSA). gMSAs are AD accounts where the password is managed automatically by the domain, removing the operational overhead of manual password rotation. Genetec supports gMSAs on current versions.

Security Groups and Role Mapping

Genetec uses AD security groups to determine role assignment. When an AD user logs into Security Center, their group memberships are read and mapped to Security Center roles that have been linked to those AD groups.

Create security groups that correspond to Genetec access levels:

Group Name	Genetec Role	Who Gets This
GSC-Operators	Security Desk Operator	Monitoring center staff
GSC-Supervisors	Supervisor / Investigator	Team leads, investigators
GSC-Administrators	System Administrator	IT and security admin staff
GSC-AccessAdmin	Access Control Administrator	HR, access control managers
GSC-VideoAudit	Video Investigator (read-only)	Compliance, legal, audit

In the Security Center Configuration Tool, link each security group to the corresponding Security Center role. When an AD user is added to GSC-Operators, they automatically get Operator-level access to Security Center on their next login. When they leave the organization and their AD account is disabled, their Security Center access is immediately revoked as well.

Group Policy for Genetec Environments

Create a Group Policy Object linked to the Physical Security OU with settings specific to Genetec servers and workstations.

Windows Defender exclusions. Add exclusions for Genetec processes, the installation directory, the media storage directories, and the database files. Incorrect exclusions are one of the most common causes of Genetec performance problems. Genetec publishes the specific exclusion paths in their best practices documentation, apply them precisely. Do not exclude entire drives or root directories.

Windows Firewall rules. Configure inbound rules for the Genetec role ports. The specific ports depend on the roles running on the server and the Genetec version. At minimum: TCP 5500 and 5501 for the Directory, TCP 554 for RTSP streams, and the port ranges for any other roles deployed. Create the firewall rules through Group Policy rather than manually configuring them on each server, this ensures consistency and survives server rebuilds.

Power plan. Set the power plan to High Performance for Genetec servers and workstations. The Balanced power plan throttles CPU and GPU performance in ways that degrade both recording and video display. Configure this through Group Policy to ensure it is applied consistently and not overridden by default settings after a Windows update or restart.

NTP client configuration. Ensure all servers in the Physical Security OU synchronize time from the domain hierarchy. A GPO preference setting that configures the Windows Time service as a domain client is more reliable than manual configuration and ensures consistency.

Kerberos Configuration

Genetec Security Center supports both Kerberos and LDAP authentication for AD integration. Kerberos is strongly preferred. It is more secure, does not require the Security Center service to bind to the domain controller with a service account, and provides better performance in larger environments.

For Kerberos authentication to work correctly with Genetec, the Security Principal Name (SPN) for the Genetec service must be registered in Active Directory. Genetec handles this automatically when the server is properly domain-joined and the service account has the necessary permissions. If authentication is failing in ways that suggest Kerberos ticket issues, verify the SPNs are registered using setspn -L [account-name].

If LDAP is required (for environments where Kerberos cannot be used), configure LDAP over SSL (LDAPS) rather than unencrypted LDAP. Unencrypted LDAP sends credentials in cleartext. LDAPS requires a certificate installed on the domain controller, but it is the only acceptable option for production environments.

Common Pitfalls

Time synchronization drift. This is the most common cause of intermittent AD authentication failures in Genetec environments. The failure mode is that login works most of the time but fails periodically or for specific users. Check the time difference between the Genetec servers and the domain controller immediately whenever AD authentication starts failing intermittently.

DNS pointing to external resolver. A Genetec server configured with 8.8.8.8 as its primary DNS cannot reliably resolve domain resources. Kerberos ticket requests go to the domain controller by hostname. If the hostname cannot be resolved, authentication fails. This is especially common in environments where the Genetec servers were set up before the network was finalized and the DNS configuration was not updated.

Service account password expiration. If Genetec service accounts have passwords set to expire, the services will fail when the password expires and nobody notices until something stops working. Either set service account passwords to never expire, or use gMSAs, or build a process to rotate them before expiration. Whichever approach you take, document it so the next person who inherits the system knows what to expect.

Missing SPNs after server migration. When Genetec servers are migrated to new hardware or new IP addresses, SPNs may need to be re-registered. If AD authentication stops working after a server migration and everything else looks correct, SPN registration is the next thing to check.

Insufficient SPN registration rights. The service account needs specific permissions to register SPNs in AD. If the service account does not have those permissions, SPNs are silently not registered and Kerberos authentication fails. Verify with the domain administrator that the service account has the ability to register SPNs for the hostnames and IP addresses of the Genetec servers.

Genetec Security Center: Tuning and Performance

Hans Study — Sun, 25 Oct 2026 17:46:24 +0000

Server Performance, Before and After Configuration Changes

Before, Default Settings

CPU Usage

82%

Disk Queue

High

SQL Mem

95%

Frame Drop

65%

NIC Buffer

Full

After, Tuned Configuration

CPU Usage

34%

Disk Queue

Low

SQL Mem

52%

Frame Drop

NIC Buffer

Normal

Same hardware. Same camera count. Different results from configuration changes only.

Most performance issues in Genetec Security Center environments are not software defects. They are configuration gaps that were never addressed during deployment or that accumulated over time. Over the years I have audited and remediated dozens of multi-server Security Center deployments across government facilities, airports, law enforcement, healthcare, and enterprise campuses. The same problems show up repeatedly.

NIC buffers left at factory defaults. Power plans set to Balanced. Video drives with Windows indexing enabled. Antivirus scanning every video file as it gets written. Servers running with settings that were appropriate for a general-purpose workstation but not for a machine handling hundreds of continuous video streams.

These recommendations are based on Genetec’s published enterprise best practices, checked against the 5.14 guide in August 2026, combined with findings from real system assessments. Run a current, stable, patched release rather than the newest one, current versions contain performance improvements that make some older configuration recommendations obsolete.

A note on StreamVault appliances: Genetec’s StreamVault units are white-labelled Dell servers running a Genetec-tuned and hardened version of Windows. They ship with over 200 preconfigured security settings and hardening profiles aligned to CIS Level 2. Many of the settings below are already configured correctly on StreamVault hardware. Verify rather than assume, the configuration should be checked even on StreamVault units, particularly after major updates or if the appliance was reimaged.

Power Plan: High Performance

This is the single most common cause of Genetec performance problems on servers that appear correctly sized. The Windows Balanced power plan throttles CPU and storage I/O performance to reduce power consumption. On a server handling hundreds of simultaneous video streams and continuous database writes, that throttling degrades performance in ways that are difficult to attribute without specifically checking the power plan.

Set all Genetec servers to the High Performance power plan:

powercfg /setactive SCHEME_MIN

Or configure it through Group Policy for consistency across servers. The High Performance plan disables processor throttling, keeps storage controllers in full-performance mode, and prevents the CPU from reducing clock speed during periods of activity. The power cost difference on a server-grade machine is typically under 20 watts. The performance difference can be significant.

Verify the setting has applied: powercfg /getactivescheme should return the High Performance scheme GUID.

NIC Buffer Settings

Network interface card receive and transmit buffers control how much data the NIC can hold before the driver processes it. Default buffer sizes are set for general-purpose use and are too small for servers handling high volumes of continuous video traffic. When the buffer fills before the driver can process it, packets are dropped. Dropped packets cause retransmissions, which degrades camera streaming performance and adds load to both the server and the network.

Increase NIC buffers in Device Manager or via PowerShell:

# View current adapter settings
Get-NetAdapterAdvancedProperty -Name "Ethernet" | Where DisplayName -Match "Receive Buffers|Transmit Buffers"
# Set receive and transmit buffers to maximum supported value
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Receive Buffers" -DisplayValue 4096
Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "Transmit Buffers" -DisplayValue 4096

The specific parameter names and maximum values depend on the NIC vendor and driver version. Intel NICs typically support up to 4096 for both receive and transmit buffers. Broadcom NICs vary by model. Check the driver documentation for the specific NIC in your servers.

On servers with multiple NICs (dedicated NIC for management, dedicated NIC for camera traffic), configure both. The buffer settings are per-adapter.

SQL Server Memory Configuration

SQL Server will consume as much memory as available RAM allows, by default. On servers where SQL shares resources with Genetec roles, the Directory server being the primary example, this means SQL expands to fill available RAM, eventually leaving insufficient memory for the Genetec Directory service and other processes.

Set SQL Server maximum server memory explicitly. The appropriate value depends on the total RAM and the other roles running on the server. A general starting point for a dedicated Directory server:

-- Run in SQL Server Management Studio (SSMS)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
-- For a server with 32 GB RAM running only Directory and SQL:
EXEC sp_configure 'max server memory', 20480;  -- 20 GB, leaving 12 GB for OS and Genetec
RECONFIGURE;

Adjust based on actual memory requirements. Monitor SQL memory usage in production and increase the cap if SQL is consistently hitting it and performance degrades. The goal is to give SQL enough memory to keep frequently accessed data in the buffer cache without starving other processes.

TempDB location also matters on Directory servers. If TempDB is on the same drive as the system database, move it to a dedicated drive. TempDB I/O can be significant during complex queries, and sharing a drive with the system database creates contention.

Antivirus Exclusions

Antivirus software that scans video files as they are written degrades Archiver performance significantly. Video files are large, written continuously, and changed frequently. Scanning them on write is high-overhead and accomplishes nothing useful, video files are not executable and do not carry executable malware payloads in the format the Archiver writes.

Configure antivirus exclusions for the following path types on all Genetec servers. The exact paths depend on your installation directories and the Genetec version.

# Genetec installation directory (default):
C:\Program Files (x86)\Genetec Security Center 5.x
# Health monitoring cache agent folder (default):
C:\ProgramData\Genetec Security Center 5.x\MonitoringCache\Agent
# Video archive directories (all drives used for video storage):

# SQL Server database files:
[SQLData]\*.mdf
[SQLLog]\*.ldf
[SQLTempDB]\*.mdf, *.ldf
# File extensions to exclude from archive directories:
*.g64, *.g64x, *.gek

Do not exclude entire drives or root directories. Scope exclusions precisely to Genetec directories and file types. Broad exclusions create security gaps that antivirus is supposed to address.

For the health monitoring cache folder specifically: exclude file extensions .tik, .xml, .units, .cameras. These files are frequently generated and trigger false positives in some antivirus engines.

Disable automated scans, “scan on definition update,” and any bundled network monitoring or firewall services from antivirus products on Genetec servers. These secondary features block Genetec traffic and strain resources beyond what the core scanning engine requires.

Video Drive Configuration

Video archive drives should be configured for optimal sequential write performance. Several Windows settings that are appropriate for general-purpose storage degrade performance on video archive drives.

Disable Windows Search indexing on all video archive drives. Indexing generates significant I/O on write-heavy volumes and provides no value for video archive directories that are not searched by Windows.

# Disable indexing on the video archive drive (replace D: with your archive drive)
$vol = Get-WmiObject -Class Win32_Volume -Filter "DriveLetter='D:'"
$vol.IndexingEnabled = $false
$vol.Put()

Disable 8.3 filename creation on video archive drives. This is a legacy compatibility feature that generates extra I/O for every file created:

fsutil behavior set disable8dot3 1

Drive letter assignment. Use dedicated drive letters for video archive volumes. Do not use mount points for production video archive paths, some file system operations behave differently on mount points and can cause recording problems in specific Genetec versions.

NTFS allocation unit size. For new video archive volumes, format with a 64 KB allocation unit size rather than the default 4 KB. Large allocation units reduce the overhead of managing many small file system entries across a drive that holds large video files:

Format-Volume -DriveLetter D -FileSystem NTFS -AllocationUnitSize 65536 -NewFileSystemLabel “VideoArchive1”

This applies to volumes being formatted fresh. Do not reformat volumes with existing video archive data unless you intend to lose that data.

Camera Stream Configuration

The camera configuration on the Genetec side has a direct impact on Archiver performance and storage consumption. Default settings are not always appropriate for production environments.

Codec selection: H.265 typically reduces bandwidth and storage by 40 to 50 percent compared to H.264 for equivalent quality. If your cameras support H.265 and your Archiver is running Security Center 5.9 or later with GPU-accelerated decode, use H.265. The compute cost of decoding H.265 is higher than H.264, but the storage and bandwidth savings usually outweigh this on modern server hardware.

Recording mode: Continuous recording generates more data and more I/O than motion-triggered recording. For areas where continuous recording is not required by policy, motion-triggered or scheduled recording reduces storage and I/O load significantly. Configure recording modes per-camera or per-area based on the actual security requirement, not as a single setting applied uniformly.

Stream quality separation: Genetec supports separate high-quality and low-quality streams per camera. The high-quality stream is used for recording; the low-quality stream is used for live monitoring. This reduces the decode load on operator workstations and the bandwidth required for client connections without reducing recording quality.

StreamVault-Specific Notes

Genetec StreamVault appliances ship with Aurora Protect (Cylance-based endpoint protection) pre-configured with the correct Genetec exclusions. If you replace Aurora Protect with a different product, all exclusions must be configured manually using the paths above. The default exclusion configuration in a new installation of any third-party antivirus product will not match what Genetec requires.

StreamVault appliances apply CIS Level 2 hardening by default. Some of these settings are more restrictive than standard enterprise server configurations and may need to be adjusted for specific integrations. Document any changes made to the baseline configuration, the StreamVault baseline exists for security reasons and modifications should be deliberate.

StreamVault firmware updates and Security Center updates are managed through the Genetec Update Service (GUS). GUS automates the update process and can be configured to apply updates during defined maintenance windows. Check the GUS documentation for the specific appliance version before enabling automatic updates in production, not all update combinations are supported simultaneously.

Ongoing Maintenance

A tuned server at commissioning will drift if maintenance is not ongoing. The items below belong on a regular maintenance schedule.

Database maintenance: Run SQL Server index maintenance on the Security Center database monthly at minimum. Index fragmentation builds over time and degrades query performance. Genetec does not automatically maintain SQL indexes beyond basic auto-shrink settings.
Archive partition management: Review archive drive usage monthly. Archiver will delete old recordings when storage reaches the configured threshold, but monitoring usage ensures you are not approaching that threshold unexpectedly during retention-critical periods.
Windows Updates: Apply updates on a defined schedule. Test updates in a non-production environment if possible, particularly major cumulative updates. Some Windows updates have affected Genetec services in specific versions.
NIC driver updates: NIC driver updates occasionally fix performance-related issues. Review available updates when diagnosing network-related performance problems.
Event log review: Review the Windows Application and System event logs on Genetec servers monthly. Recurring errors that are not causing obvious problems today frequently indicate issues that will become problems under higher load.

A tuned server drifts. If you want a second set of eyes across the whole stack, not just one server, see the Genetec Health Check or work through the Health Check Checklist. Many of the symptoms tuning fixes also show up in the 10 most common Genetec Security Center issues.

Genetec Security Center 5.13.3.0 Review: What Matters

Hans Study — Sat, 24 Oct 2026 17:32:04 +0000

Image courtesy of Genetec. Used with attribution.

The Genetec release cadence has gotten consistent enough that this kind of write-up is worth doing every minor version. 5.13.3.0 hit techdocs on May 14, 2026. The previous baseline most production environments are sitting on is 5.13.2.0, which dropped in July 2025. That is roughly 10 months between the two, with a couple of patch revisions in between, which is about right for a platform of this scale.

What follows is the field read on what is in the box, what is worth upgrading for, and what is still on the wishlist after years of asking.

Where the version stands today

Updated 23 August 2026. This review was written when 5.13.3.0 was the newest on-premises build. It is not any more. 5.14.0.0 shipped on 12 May 2026 and 5.14.0.1 followed on 29 June, so 5.13.3.x is now the mature branch rather than the leading one. Everything below still holds as a description of 5.13.3.0, and 5.13.3.x remains the release I put most clients on today. For where 5.14 changes the picture, read the 5.14 outlook.

Security Center 5.13.3.0 is the mature on-premises release and the one I still recommend for most production deployments. 5.13.2.0 (released 2025-07-10) is the last major step before it, and 5.14.0.0 is the newer platform release sitting above it. The SaaS variant (Security Center SaaS) is on its own continuous-delivery track, which adds investigation features and access control enhancements on a near-monthly cadence as of Q1 2026. This article focuses on the on-prem release that most of us actually run.

If you are still on 5.11.x, you should be planning your move. 5.11.3.26 was last updated in December 2025 and is essentially end-of-life territory. 5.12.x is the bridge. 5.13.x is where the active development is happening.

Planning the move rather than reading about the release? The Security Center migration paths reference has the supported routes and a pre-flight checklist.

Platform changes that actually matter

Time drift monitoring against the Directory

This is the kind of feature that sounds boring and turns out to be useful. The client workstation can now show the time-sync offset against the Directory server, accessible through the Session info icon in the notification tray. If you have ever lost an afternoon chasing why an export was timestamped 90 seconds off the door event you were trying to correlate, you know why this is welcome.

What is missing: a system-wide health view that surfaces every workstation with significant drift, alerts on it, and does not require somebody to open Security Desk and click around. The data is now exposed; the proactive monitoring is not. Maybe next release.

Copy configuration tool now requires its own privilege

For years, anyone with admin rights could right-click an entity, hit Copy Configuration, and ship settings across hundreds of cameras or doors in one go. Useful tool. Easy to misuse. The new Use Copy configuration tool privilege gates access to this function explicitly.

This is the kind of granularity that should have been there from the start, but I will take it now. Upgraded users who already had access keep it by default, so you will want to audit which roles have it and prune as appropriate.

CSV report limits

CSV exports are now capped at 1 million results, or 10,000 if the report includes images. This came about because well-intentioned people kept exporting full system-wide cardholder reports and bringing the Reporting role to its knees.

The cap is sensible. It also means if your workflow currently relies on dumping a 3M-row CSV out of Security Desk, you need a new workflow. My thought: that workflow was always a sign you should have been hitting the SDK or the database directly, not the report engine.

Debug console disabled by default

A small but meaningful hardening change. The debug console in Security Desk and Config Tool is now off by default. You can re-enable it through About > Debug console when troubleshooting. Anyone who has been on a hardened deployment has been disabling this through GPO or registry for years; now it is the default.

Permanent alarm muting from Investigate

You can now mute a continuously-sounding alarm permanently across all workstations by hitting Investigate in the Alarm monitoring task, instead of waiting until the alarm is acknowledged. This is a quality-of-life win for operators dealing with a stuck input that is blasting audio across the SOC every 4 seconds.

It is also exactly the kind of feature that should come with usage logging, because “mute permanently” is the sort of action you absolutely want to see in audit trails after the fact. Confirm in your environment that this writes to the audit trail. If it does not, file a feature request.

Enhanced Network view with proxy and archiver co-location

Archiver and Proxy servers can now operate in the same network without requiring an extra routing layer. Live and playback streams use the same path, which makes both troubleshooting and capacity planning more predictable.

For larger deployments using cascaded Archivers and federated systems, this simplification matters. For single-site shops, you probably will not notice.

Automation enhancements

Delays between response actions

Before 5.13.3, automation response actions fired immediately and in order. Now you can insert delays in hh:mm:ss format between actions, which opens up workflows that were previously impossible: trigger a camera to start recording, wait 30 seconds, send an email with a snapshot, wait 5 minutes, escalate if not acknowledged.

This was a long-standing gap. Welcome to the feature set.

New contextualised actions

The following actions can now operate on the source entity that triggered the automation:

Block and unblock video
Override with event recording quality
Override with manual recording quality
Recording quality as standard configuration

These join the contextual actions added in 5.13.2.0 (email snapshots, set door/entity maintenance mode, reboot a unit). The automation engine is becoming progressively more useful for the kind of incident-response workflows that used to require SDK glue code.

Map designer enhancements

Auto-positioning of georeferenced devices

If you add a camera or ALPR unit to a georeferenced map and the device has a configured geographic location, it now drops in the correct place automatically (provided the location falls within the current map view). If the device is outside the current view, the system tells you how far off the click point is from the configured location.

For sites that have been disciplined about geocoding their devices, this is a real time-saver. For sites where the lat/long fields are still blank or filled with whatever the integrator typed in at commissioning, this changes nothing.

Bulk synchronisation of map objects with linked entities

Open Map > Synchronize map objects with entities’ geographic locations and align in one shot. Or, if the entity has no geographic location configured, push the map object’s position back to the entity. Useful for cleanup after a campus expansion when devices have moved but the GIS data did not catch up.

Video enhancements

Batch firmware upgrade

You can now upgrade multiple video units in batch through the Hardware inventory task, provided all selected units are the same model and on the same firmware version. The constraints are reasonable; the time savings on a 200-camera refresh are substantial.

This is one I have been waiting on. The previous one-at-a-time workflow was the kind of thing that turned a firmware-mandated security update into a 2-week project. Worth exploring on the next maintenance window, and worth building into your standard firmware cadence going forward.

That said, for Axis-heavy fleets I am still reaching for Axis Device Manager (ADM) before I reach for Hardware Inventory. ADM remains the better tool for batch configuration, firmware management, certificate deployment, and credential rotation across Axis cameras specifically. It speaks the manufacturer’s language natively, handles edge cases the VMS does not have visibility into, and gives you the scripting hooks that make large-fleet maintenance tractable.

My thought: vendor-native management tools almost always beat VMS-integrated equivalents for their own gear; that is not a knock on Genetec, it is how the math works.

For mixed fleets where Axis is one of several manufacturers, the Genetec batch tool is the right answer because it is the only tool that touches everything. For pure Axis sites, ADM stays in the rotation. The two are not in competition; they are solving different problems at different scales.

Either way, Genetec moving in this direction is a real step forward.

AV1 device support

Security Center now supports AV1 codec devices. At launch, Axis is the only manufacturer shipping AV1-compatible hardware, and the support is narrower than the marketing implies. Only Axis cameras built on the ARTPEC-9 SoC encode AV1. The Q1728 block camera was the first model to ship with it; the Q6355-LE and Q6358-LE PTZs, the Q1726-LE, and a growing list of Q-series and P-series models built on ARTPEC-9 are joining the fleet. Cameras still on ARTPEC-8 or earlier, including the Q9227 anti-ligature line that detention and behavioural-health facilities rely on, do not support AV1 and will not be retrofitted with a firmware update. The codec is a chip-level capability, not a software toggle.

For AV1 to deliver value end-to-end, you need a workstation with hardware acceleration (NVIDIA or Intel Quick Sync on 11th-gen CPU or later), a current Chrome or Edge with native AV1, and an ARTPEC-9 Axis camera at the edge. When the stars align, the Web App can play AV1 streams without transcoding, which is what makes the codec interesting in the first place (bandwidth savings without the CPU tax on the workstation side).

The real impact of AV1 is not going to be felt in retail or small-commercial deployments. It is going to land hard in industries with multi-year retention obligations. Law enforcement archive storage, provincial and federal detention, courthouse and tribunal facilities, healthcare with extended legal-hold periods, gaming and casinos under regulatory retention rules. These are environments where storage cost compounds year over year, where a 30-50% reduction in archive volume (the kind of saving AV1 is showing in early field deployments compared to H.264) translates into significant capital and recurring storage savings. A facility holding 90 days of 4K video across 400 cameras is moving petabytes; the same facility holding 7 years of video for evidentiary purposes is doing math that AV1 changes meaningfully.

Worth tracking closely. Worth piloting on new ARTPEC-9 deployments. Not yet worth ripping out an ARTPEC-8 fleet that is working.

Expanded archive viewing limits

The Limit archive viewing field in User management now supports up to 365 days. The old cap forced workarounds for environments with long retention periods, where compliance use cases needed to look back further than the field would allow.

Archiver role warning toggle

If you have got multiple Archiver roles using the same drive for storage (intentionally, in a tiered storage design), the warning that fires every time you open the config can now be suppressed per Archiver role. You have to call GTAC to turn it off, which is mildly annoying but at least it is possible.

Access control enhancements

Improved visitor credential display

The Visitor management task now has a dedicated Credentials page in the modify visitor dialog. Tile or list view. Add, edit, or remove credentials from one place. Assign temporary cards and print badges from the same screen.

A long-overdue cleanup of a workflow that previously required clicking through multiple dialogs. My thought: nobody is going to write a case study about this, but the people who work in Visitor Management every day will notice immediately.

Partitions for temporary access rules

When you create a temporary access rule via Cardholder management, you now have to assign it to a partition explicitly. The old behaviour inherited the cardholder’s partition, which led to scoping bugs in multi-partition environments. The change is a small UX nudge with real security value.

What is still on the wishlist

This is the part of the release-review nobody at Genetec marketing writes. These are the gaps I have been raising with Genetec reps at every GTAP touchpoint for years.

Native, structured log streaming to SIEM

Security Center generates rich audit data. Getting that data into a SIEM in a clean, structured form (CEF, LEEF, JSON over syslog) requires SDK work or third-party connectors. For a platform that sells into government, defence, and critical infrastructure, native, schema-stable, real-time forwarding should be table stakes. It still is not.

Finer-grained RBAC

The Use Copy Configuration Tool privilege is a step. There are dozens more privileges that need this treatment. Delegated administration (giving a regional admin full rights inside their partition, including user management for that partition, without elevating them to system admin) is still a workaround rather than a first-class feature.

Native MFA for local accounts

Local Security Center accounts still rely on the underlying directory or third-party MFA for any meaningful second factor. Native TOTP for local accounts, gated by role, would be useful for the break-glass admin scenario where AD is unreachable and you still want a second factor.

True hybrid parity

SaaS gets features (natural language search, similarity detection, the unified front desk) that on-prem does not. On-prem gets features (federated systems, full SDK access) that SaaS does not. The marketing positions this as “choose what fits your deployment.” In practice, customers running both want feature parity, and the product split keeps widening rather than narrowing.

Web App parity

The Web App is good, and getting better with every release. It is still not at parity with Security Desk for power-user workflows. If your operators live in the Web App, you will find the edges. If they live in Security Desk, you will find the edges of the Web App when you try to support remote operators.

Better SDK documentation

The SDK is powerful. The documentation is uneven. Genetec has been investing in the developer portal, and 5.13.3.0 ships with corresponding SDK release notes, but the gap between “what the SDK can do” and “what is documented well enough for a non-Genetec-engineer to do it” remains.

Should you upgrade?

If you are on 5.13.2.0, the path to 5.13.3.0 is incremental. Review the Features that impact an upgrade page in the techdocs before you start, but for most deployments, this is a straightforward minor version step. The batch firmware upgrade, the Copy configuration privilege, and the automation delays are reason enough to plan it for the next maintenance window.

If you are on 5.12.x, plan the move to 5.13. The compatibility matrix is reasonable and the platform-level changes (continuous delivery, the consolidated install, the SDK improvements) compound.

If you are on 5.11.x, you should already be working on this. The 5.11 train is in its last station.

As always: read the Known issues and Limitations pages before you upgrade anything. The Genetec techdocs are clear, and the known-issue list is more honest than most vendors’ equivalent.

If you want an outside read on whether your environment is ready for the jump, a Genetec Health Check covers version currency and the hardware and integration constraints that decide an upgrade, and independent Genetec consulting can plan and oversee it.

Axis Camera Station Pro 6.14 Review: AI, Analytics, Search

Hans Study — Fri, 23 Oct 2026 18:37:25 +0000

Image courtesy of Axis Communications. Used with attribution.

I have been skeptical of Axis Camera Station for years, without saying so loudly. Not because the product was bad, but because Axis spent the better part of a decade trying to position it as a “good enough” VMS for small-to-medium deployments while letting Genetec, Milestone, and Avigilon own the enterprise conversation. ACS was the camera-vendor’s afterthought. It worked. Nobody got excited about it.

That changed somewhere between version 6.1 (when Axis Camera Station Pro split from the original ACS lineage) and the current 6.14 release. The product I am evaluating today is fundamentally different from the one I dismissed in 2020. The AI, analytics, and search story is finally cohesive. In an Axis-heavy environment, nothing else integrates this tightly. And for the first time, I am seeing deployments where ACS Pro is the right answer rather than a compromise.

This is the field review for anyone running, considering, or designing around ACS Pro in 2026.

Where the version stands today

AXIS Camera Station Pro 6.14 is the current release as of mid-2026. The platform has been moving fast: 6.6 (free text search), 6.9 (swaying object filter, Secure Entry mass credential distribution), 6.10 (security fixes), 6.11 (License Plate Verifier integration), 6.12 (Audio Manager Pro), 6.13 (Badge templates and elevator access control, both in beta), 6.14 (object detection recording, multi-rule editing, vehicle make/model search).

That is 8 releases in the past 18-ish months. Aggressive cadence for a VMS, slower than ACS SaaS but appropriate for a server-based platform. The release notes are public, the upgrade paths are clean, and unlike some vendors I could name, Axis publishes a clear “What’s new” page that does not require a partner login to read.

Smart Search 2: the feature that changes the conversation

This is the headline. Smart Search 2 is Axis’s AI-powered search engine, and it is the feature that takes ACS Pro from “competent VMS” to “platform I would actually deploy for investigation-heavy environments.”

What it does, in plain terms: it indexes object metadata from every camera that supports analytics, classifies the objects it sees (people, vehicles, specific characteristics), and lets you search recorded footage by describing what you want to find.

Two search modes:

Pre-classified object filtering. Pick “person” or “vehicle” from a filter list, refine by attributes like clothing colour, vehicle colour, vehicle type, time range, and area. This is the kind of search that previously required either expensive third-party analytics (BriefCam, Veesion) or hours of manual scrubbing. ACS Pro now does it natively, with the metadata generated on-camera by AXIS Object Analytics or ARTPEC-driven deep-learning analytics.

Free text search. Type a natural-language description of what you are looking for, in English, and the system returns matching clips. “Construction worker in yellow vest near the loading dock between 2 and 4 PM” is a valid query. The model handles object recognition, attribute matching, and association reasoning (the construction-worker classification is handled by inference; you do not have to spell out every visual element).

This arrived in version 6.6 and has been refined in every subsequent release without much fanfare. By 6.14, the search results are fast, the false-positive rate is reasonable, and the workflow is actually useful for the kind of investigative work that used to eat investigator hours by the dozen.

My thought: this is the first VMS-native AI search I have used that I would actually rely on for a real investigation. The competitors are catching up, but Axis got there first on a tightly-integrated product, and it shows.

The technical caveats:

Smart Search 2 indexes metadata from cameras with AXIS Object Analytics or supported deep-learning analytics. Older cameras without these capabilities will not contribute searchable metadata, which means your fleet’s classification coverage is a function of which cameras are deployed where.
The 6.9 release added a swaying-object filter that strips foliage and similar repetitive motion from the indexing pipeline. This was a major precision improvement. If you are on a pre-6.9 release and seeing too many false hits from windy trees, that is why.
ARTPEC-8 and later cameras get the best metadata fidelity. ARTPEC-9 (the Q1728, Q1726-LE, Q6355-LE, Q6358-LE, and the growing list of new models) brings improved object classification accuracy on top of AV1 codec support.
Free text search runs locally on the server (or in Axis’s cloud if you are using the cloud variant). Either way, the prompt and the indexed metadata do not leave your environment when running on-premises, which matters for compliance-driven deployments.

AXIS Object Analytics: the engine behind the search

Smart Search 2 is the interface. AXIS Object Analytics (AOA) is the engine. AOA is the deep-learning analytics application that ships pre-installed on compatible Axis cameras and produces the object classifications that Smart Search 2 indexes.

In 6.14, AOA gained a direct role in recording configuration: the new object-detection recording method lets you trigger camera recording on human or vehicle detection rather than generic motion. This is a bigger deal than it sounds. Motion-triggered recording on a wind-prone exterior site can fill an archive with hours of swaying-branch clips. Object-triggered recording filters out anything that is not a person or vehicle, which means your archive is full of the events that actually matter rather than noise.

For storage-constrained deployments, this changes the math on retention. A camera that previously needed 90 days of motion recording to cover an investigative window can often run 90 days of object-triggered recording on a fraction of the storage, because the periods of no humans or vehicles in scene are not recorded at all.

The combination of AOA-driven recording, Smart Search 2 indexing, and ARTPEC-9 codec efficiency is starting to deliver real storage and retrieval improvements end-to-end.

My thought: this is where Axis’s “edge analytics first” architecture finally pays off. They have been pushing analytics to the camera for years; in 6.14, the VMS-side workflow finally takes full advantage of it.

AXIS Data Insights Dashboard

The Data Insights Dashboard is Axis’s visualisation layer for analytics data. Originally launched in 6.1 with crossline counting and occupancy, it expanded significantly in 6.6 with three new dashboard types:

Audio analytics for AXIS Audio Analytics events (gunshot detection, aggression detection, glass break).
Generic for all supported data sources including AXIS Guard Suite events and third-party analytics applications.
Image health for AXIS Image Health Analytics, which monitors camera focus, tampering, and image quality issues.

In 6.5, vehicle data was added as a search/filter option (white bus, red sedan, license plate ranges). In 6.3, vehicle properties like colour, direction of travel, and country plate origin became searchable. By 6.14, vehicle make and model joined the list, which closes the loop on a workflow that used to require BriefCam-tier add-ons.

The dashboard is useful in three real-world scenarios I have seen:

Retail and venue operations: occupancy trends, queue analysis, peak-hour identification.
Industrial and warehouse: vehicle traffic patterns at loading docks, dwell-time analysis, identification of unusual stoppages.
Healthcare and behavioural environments: aggression detection trends, dwell times in restricted areas, audio-event clustering by time of day.

For environments where the security operation also feeds operational intelligence (which is most modern deployments), the Data Insights Dashboard is a real selling point. It is not as deep as a dedicated BI platform, but it is deep enough that operators get useful answers without leaving the VMS.

AXIS License Plate Verifier

ALPR has matured significantly in the past few releases. License Plate Verifier got serious integration improvements in 6.11, where the workflow for managing authorised plate lists, syncing groups of cameras, and triggering barrier control became operator-friendly. 6.14 expanded the search side: data search now supports vehicle make and model in addition to plate, colour, direction, and country.

For sites that need vehicle access control (gated communities, corporate parking, secure logistics yards, employee parking enforcement), the ACS Pro + License Plate Verifier combination is becoming a credible alternative to specialised ALPR products. It runs on the Axis cameras you have already got (or new Axis cameras you would buy anyway), no separate licensing dance, no third-party analytics server.

The caveat: License Plate Verifier capabilities depend on the camera. License Plate Verifier kit cameras with OS 12.8 or the License Plate Verifier version 3 ACAP on standalone cameras give you the full feature set. Older kit cameras get baseline ALPR but not the latest searchable attributes.

Axis Secure Entry: the access control side

For sites running ACS Pro as the unified VMS plus access control platform, Secure Entry has matured into a real Mercury-class alternative on Axis hardware. The 6.5 release brought Secure Entry 2.0 UI improvements and roll-call/mustering reports (relevant for healthcare, education, and large industrial sites). 6.9 added mass distribution of QR and mobile credentials, which closes a workflow gap that previously required either manual per-cardholder emails or external bulk-email tooling.

The 6.13 release added elevator access control in beta, with a new “Floor” door type, support for up to 16 floors, and the AXIS A9910 Relay Expansion Module for sites needing more floor relays. Beta status is real (you should test thoroughly before deploying to production), but the feature exists and the foundation is in place.

The trade-off versus Mercury or HID-on-Synergis: Axis Secure Entry is a tightly integrated, Axis-only access control stack. The Axis A1610, A1710, and A1810 door controllers handle the controller layer; the AXIS A4612 Bluetooth Reader and equivalent readers handle the credential layer. For all-Axis deployments, the integration is tight and the management surface is minimal. For mixed-vendor deployments, this is not the answer; you will still want Synergis with Mercury or HID hardware, or an Avigilon Alta stack, depending on your environment.

What is worth using, what is worth waiting on

Going feature by feature, my current field guidance:

Use today:

Smart Search 2 (free text and object filtering). Mature, fast, valuable.
AXIS Object Analytics + object-detection recording. Real storage and clarity wins.
AXIS Data Insights Dashboard. Useful for any environment with operational reporting needs.
AXIS License Plate Verifier with vehicle make/model search.
Secure Entry 2.0 (the GA, non-beta features). Solid for Axis-only access control.
AV1 codec support (with ARTPEC-9 cameras only, AXIS OS 12+).
Axis Secure Remote Access v2 (the legacy v1 was deprecated in late 2025, plan accordingly).

Test before deploying:

Elevator access control (beta in 6.13/6.14). Functional but flag the beta status with the client.
Badge templates and printing (beta in 6.13). Useful when it works, but production deployments need careful testing.
Multi-server distributed search. Works, but federated environments deserve a test pass.

Mind the gap:

Mobile app feature parity. The mobile app has been steadily improving (access control in 6.8, expanded views over time), but parity with desktop is still partial. For operators who will work primarily from a phone, test the workflows that matter to your team specifically.
Smart Search 2 results depend on metadata coverage from your camera fleet. Older or non-Axis cameras do not contribute metadata. Plan deployments around this rather than discovering it after the fact.

Architectural notes:

ACS Pro is a Windows server platform, like Genetec on-prem. No Linux option. If your IT standardised on Linux for infrastructure, that is the conversation to have early.
Cloud connectivity is available via Axis Cloud Connect for license management, server monitoring, web client access, and similar functions. The cloud variant of Smart Search 2 (added in 6.5) extends the search workflow to remote operators via My Systems.

How ACS Pro stacks against Genetec

The honest comparison: they are different products solving overlapping problems.

ACS Pro wins on:

Axis-native deployments (camera, intercom, audio, access control on Axis hardware). The integration is tighter than any third-party VMS managing Axis gear.
Smart Search 2 free text search. Genetec is catching up via Security Center SaaS features, but on-prem parity is not there yet.
Out-of-the-box analytics for any environment running Axis ARTPEC-8 or 9 cameras.
Total cost of ownership for small-to-medium Axis-heavy sites. ACS Pro perpetual licensing avoids per-channel surprises.

Genetec wins on:

Multi-vendor camera environments. Genetec’s driver pack covers more cameras with more features than ACS Pro is targeted to.
Enterprise-scale federated systems and multi-site management. Genetec’s federation model is more mature.
Integration depth with non-Axis access control (Mercury, HID Aero, ASSA ABLOY Aperio, building automation).
Mission Control and Operations Center for command-and-control workflows.
Customisable SDK and a deeper third-party integration network.

The decision rule I am using for clients: if the site is predominantly Axis hardware and the use case is straightforward video plus access control, ACS Pro deserves the consideration. If the site is mixed-vendor or runs at enterprise scale with federation requirements, Genetec stays the default.

My thought: nobody benefits from a religious war between VMS platforms. The right answer depends on the deployment. ACS Pro has earned a seat at the table in 2026 in a way it had not in 2022.

Where I land on this one

ACS Pro in 2026 is a fundamentally different product than the one I dismissed in 2020. The trajectory since 6.1 is genuine, not marketing.
Smart Search 2 (free text + object filtering) is the feature that made me change my mind. First VMS-native AI search I would actually rely on for a real investigation.
AXIS Object Analytics + object-detection recording changes the storage math for any deployment with long retention requirements. Real savings, not benchmark numbers.
For Axis-heavy deployments where the use case is video plus access control, ACS Pro earns a seat on the shortlist. Sometimes it wins the seat.
For mixed-vendor environments or enterprise-scale federated systems, Genetec still owns the conversation. ACS Pro is not trying to be that product.
The beta features (elevator access control, badge templates) need to come out of beta before I would put them in a client SOW. Test them, but do not lean on them yet.
Mobile app parity, multi-vendor depth, and a Linux server option remain open items. Watch the cadence; Axis is moving faster than most VMS vendors.

Whichever VMS you land on, the network underneath it decides whether it performs. See building a network for CCTV and access control for the infrastructure side, and the security system hardening guide for hardening it.

Genetec Security Center 5.9 Is End of Life

Hans Study — Thu, 22 Oct 2026 18:43:54 +0000

I’ve walked into enough server rooms to recognize this one on sight. Somebody stood up Security Center 5.9 back in 2020, it worked, and that was the end of the conversation. Cameras up, doors locking, dashboard green. You don’t go poking a system that behaves. That’s the version Genetec just declared end of life.

Consider this the heads up.

Security Center 5.9 is done. Since December 2025 it stopped getting updates and security patches, and the patches are the part that matters. Run 5.9 or anything older and you’re on software nobody is fixing anymore. Not fixing slowly. Not fixing.

End of life is a quiet problem. Nothing breaks the day it lands. The cameras still record, the doors still open, the dashboard stays the same shade of green it was last week. What changes is invisible. The next time a vulnerability turns up against something in your stack, and one will, the fix doesn’t come to you. It goes to the versions still under support, and 5.9 keeps the hole. Then it keeps the next one. The exposure doesn’t show up as a cliff, it builds as a slope, and the longer you sit the steeper it gets. That is the whole risk, and it’s why this matters even though everything looks fine.

The upgrade pitch is aimed at someone else. Genetec wants everybody on 5.14 or Security Center SaaS, and the messaging is loud about the new toys. Faster video search. Alarm automation. Better analytics, integrated comms, a cleaner experience across desktop, web, and mobile. The features are real and some of them are good. None of it is the reason to move.

Nobody refreshes a working access control system because the search box got smarter. You move because an unpatched security platform is a liability bolted to your network, and the irony writes itself: the system you bought to watch the building turns into the easiest way into it. Cameras, controllers, the lot. Exposed and unpatched, it isn’t defending anything. It’s an entrance. If the new analytics happen to help your operation, fine, take them. They’re a bonus. The patch cutoff is the reason.

The technical reality is messier than a weekend cutover. Before anyone sells you a clean Saturday-night migration, a few things decide how big this job really is.

You probably can’t jump straight from 5.9 to 5.14. Genetec’s upgrade paths tend to route through a stepping-stone build, so getting there is its own piece of planning, not a footnote.

The hardware might not survive the trip. Servers, Windows versions, and SQL versions that were fine under 5.9 may not be supported on the current release. That turns a software upgrade into a hardware refresh, and on Genetec’s schedule rather than yours.

Where the system lives is a live decision now. On-premises, cloud, or hybrid. SaaS wasn’t a serious option when most of these 5.9 systems were built. It is today, and it’s worth weighing before you default to same-as-before.

And licensing decides what you’re actually allowed to do. Your upgrade entitlement and your Advantage status set the menu and the price. Check that first. Plan around it second.

The supported route off 5.9 and what it involves is laid out in the Genetec Security Center migration paths reference.

End of life is a clock, not a fire. You don’t have to move this week. You do have to move, and the version of this that goes badly is always the one where somebody else picks the date. An auditor. An insurer. Whoever ends up writing the incident report.

Pick it yourself. Map the path, find out what hardware lives through the jump, decide where the system should sit for the next 5 years, and get it on a calendar while it’s still your call. Once it stops being your call, it gets expensive, and you don’t get to argue the timeline.

Mapping that path is exactly what a Genetec Health Check is built for. It tells you what hardware survives the jump, what the upgrade route looks like, and where the system should sit next. If you want a hand planning the move, independent Genetec consulting covers upgrade planning and deployment oversight. Start a conversation while the timeline is still yours to set.

03.14.09, Canada's one addition to NIST SP 800-171

Hans Study — Wed, 21 Oct 2026 18:50:14 +0000

ITSP.10.171 is the Canadian Cyber Centre's adaptation of NIST SP 800-171 Revision 3, and the government says plainly that it doesn't change the technical content in any substantive way. It has 98 requirements. NIST's Revision 3 has 97. The 1 extra is 03.14.09, dedicated administration workstation.

It is the only requirement in the Canadian standard that isn't in the American one. It comes from the Canadian control catalogue, source control SI-400 in the ITSG-33 lineage, and nobody who has only worked from 800-171 will have seen it.

What it asks for

Three things.

Administrative and superuser actions are done from a physical workstation dedicated to that work and isolated from all other functions and networks, especially the internet.
Remote connection from that workstation to the network it administers runs over a carrier private network, such as VPLS or MPLS, with VPN encryption on top.
The workstation is a hardened, single-purpose machine or thin client that isn't shared between security realms.

The discussion text goes further than most shops expect. The workstation isn't domain-joined. It doesn't download patches from the internet. It carries no office tools. It isn't used to update documentation in networked applications.

What it looks like in a 20-person shop

Smaller than you'd fear. 1 admin machine, kept off the internet, patched from media you bring to it, and used for nothing but administering the enclave. Admin accounts work from that machine and from nowhere else. Nobody reads email on it or browses from it.

That pairs with a habit the maintenance and access control requirements already push you toward: nobody works under an admin account day to day. The person who administers the enclave has an ordinary account for email and a separate admin account that only functions from the dedicated machine.

For a shop that runs its own IT, this is a procurement item and a change of habit. Annoying, and nothing more.

Where it gets hard

The second clause is the problem. An MSP administering your enclave from its own office over an internet VPN doesn't meet the requirement as written, which is why it belongs on the list of questions to ask your provider. A carrier private network to every client is not how most MSPs are built, so the clause lands on a business model, not only on a configuration.

Their obvious question is whether this is a requirement or an aspiration. It is a Level 2 requirement, it is new, and the assessment method for it hasn't been published. Nobody can say today how an assessor will score it.

What I tell clients

Read the text yourself rather than relying on a summary. The standard's wording is the authority.

Keep administrative work inside the enclave wherever you can. The less administration crosses a network you don't control, the less the remote clause has to carry.

Get your assessor's reading in writing before you buy circuits. A carrier private network is a real recurring cost, and buying one against an interpretation that turns out to be softer is wasted money. Skipping one against an interpretation that turns out to be strict is worse, so the written reading matters in both directions.

Put the question in the MSP relationship now, not at assessment time. If administration is an MSP deliverable, the responsibility matrix has to say how they will meet 03.14.09, or whether the client takes administration in-house. Some MSPs won't be able to support this work. Better to learn that in 2026 than mid-assessment.

This is a Level 2 item, so it doesn't touch a Level 1 attestation. Level 2 is planned for select contracts from spring 2027, and 03.14.09 deserves a line in the plan now.

Nobody Owns the Network Between the Integrator and IT

Hans Study — Wed, 21 Oct 2026 18:49:42 +0000

Ask who’s responsible for the security of a building’s camera and access control network, and you’ll usually get a pause, then a deflection. The integrator says they delivered what the contract specified. The IT department says they were handed a finished system they didn’t design and can’t fully see. The facilities team says it’s a security system, so surely security owns it. The security team means guards and policy, not subnets. Everyone is partly right, which is another way of saying nobody owns it.

That gap is the actual vulnerability. Not a specific unpatched camera, though there are plenty of those. The structural problem is that the network between the integrator and IT belongs to no one, and unowned infrastructure doesn’t get secured, monitored, or maintained.

Why this is a national-stakes problem, not a building problem

For a single office, an unowned camera network is a manageable risk. For the systems that run a country, it’s something else. State-linked intrusion campaigns spent the last few years getting quiet and patient inside critical infrastructure networks, living off the land, waiting. The Volt Typhoon and Salt Typhoon activity that surfaced is the clearest public example of the pattern: not smash-and-grab, but long, careful positioning inside the kinds of networks that keep water moving and power flowing.

Physical security systems are an ideal way in. They’re networked, they’re numerous, they’re rarely segmented well, they’re patched late if at all, and they sit inside facilities that matter. A camera fleet on a flat network at a utility is not a facilities problem. It’s an attack surface on critical infrastructure, and the reason it stays open is governance, not technology.

You can’t buy your way out of a responsibility gap

The instinct is to reach for a product. A new firewall, a monitoring tool, a network access control appliance. Tools help, but they don’t decide who’s accountable, and accountability is the thing that’s missing. A monitoring platform that nobody owns generates alerts that nobody reads.

What closes the gap is a decision. Someone has to own the security of the physical security network, end to end, with the authority and the budget that go with it. That ownership has to be named before the next system gets installed, not discovered during the incident review after it’s breached.

What ownership actually looks like

It’s unglamorous, which is part of why it gets skipped. A named owner for the security estate’s network posture. A requirement that integrators meet a security standard as a condition of acceptance, not a nice-to-have. Segmentation and monitoring that someone is responsible for maintaining. And documentation good enough that the IT team inheriting the system knows what they have. None of that is a product you can purchase. All of it is a choice an organization can make.

The organizations that get this right treat the network under their physical security the way they treat any other production network, because that’s what it is. The ones that don’t are leaving a door open in a building that can’t afford an open door, and calling it someone else’s job.

If you’re trying to figure out who owns this in your organization, or you’ve realized the answer is no one, that’s the conversation I have with leadership.

Hans Study, CISSP, is an independent network and security consultant and fractional CISO in Ontario, Canada. He has spent 15+ years on critical infrastructure, defence, and public safety networks.

Physical Security Network Hardening: The Soft Spot

Hans Study — Tue, 20 Oct 2026 18:37:35 +0000

A security integrator pulls cable, mounts cameras, installs card access on the doors, and gets everything wired and talking. The customer watches a guard pull up live video on a monitor, sees the door unlock when a badge taps the reader, and signs off. Job done. Except the part nobody checked is the only part that matters once the building is occupied: whether any of those devices is safe to have on a network.

Most of the time, it isn’t.

Here’s the thing people miss. A modern camera is a Linux computer with a lens. A door controller is a computer that can open a locked door. A video management server is a Windows box sitting on your network with a service account that probably has more access than it should. These are computers, and they get installed by integrators whose training was in conduit, mounting, and making the demo work, not in network security. That’s not an insult. It’s a description of how the work is structured, and it’s how critical infrastructure ends up exposed without anyone deciding it should be.

The buyer makes it worse without meaning to

Customers judge a security system by whether it works the way they can see it work. Does the camera show a picture? Does the door open? Did the install look tidy? Those are the acceptance criteria, and a system passes them whether or not it’s a soft entry point into the corporate network. So the buyer pays for what they can observe, the integrator delivers what the buyer pays for, and network security, which nobody can see in a walkthrough, falls into the gap between them. Airports, hospitals, courthouses, law enforcement, and plain office buildings. Everywhere is impacted.

I’ve watched enough of these systems pass acceptance testing to know the gap between a system that works and a system that’s secure is wide, and the customer almost never finds out until something goes wrong.

The 5 things that close most of the gap

None of this is exotic. It’s the basic hygiene that should have been part of the install, applied after the fact because it wasn’t.

Get it off the flat network. Cameras, controllers, and the management servers belong on their own segment, with traffic between that segment and the business network controlled and logged. A flat network where the lobby camera can reach the finance server is a design failure, even if everything displays correctly.
Change the credentials, all of them. Default passwords on devices, default service accounts, the vendor’s maintenance login. Change them before the system goes live, not in a future maintenance window that never comes.
Patch the things, on a schedule. Camera and controller firmware ages out fast, and “it still works” is not the same as “it’s safe.” If nobody owns patching for the security estate, nobody is patching it.
Lock down the management server. Least privilege on the service accounts, host hardening, logging turned on and going somewhere. The video management system is a Windows server like any other, and it should be treated like one, with stability, security, and sometimes functionality weighed honestly when you do.
Write down who owns it. The single most common failure isn’t technical. It’s that no one is responsible for the security of the security system after handoff. Name the owner, on paper.

The deeper problem is the handoff

The integrator finishes and leaves. The customer’s IT team was rarely in the room during the install and inherits a system they didn’t design, often without documentation, sometimes without even knowing the device count. The vendor considers the job closed. So the system runs for years, unpatched and unsegmented, until an incident or an insurance review or an auditor finally asks the question nobody asked at sign-off.

If you operate any of this, the fix isn’t a product. It’s deciding that the security system is part of your network, holding the integrator to a standard before you accept the work, and owning it afterward. That’s the work I do on the convergence side, and it’s the same gap I keep finding on assessments.

Hans Study, CISSP, is an independent network and security consultant and fractional CISO in Ontario, Canada, focused on the boundary where physical security, OT, and IT meet.

The Firewall Did Its Job: What FortiBleed Was Really About

Hans Study — Mon, 19 Oct 2026 20:05:59 +0000

When FortiBleed made the rounds, the framing wrote itself: another firewall, another breach, patch and move on. That framing is wrong, and the wrong lesson is more dangerous than no lesson, because it sends people chasing a fix for a problem they don’t have.

FortiBleed isn’t a CVE. It’s a compiled dataset of credentials for 73,932 FortiGate devices across 194 countries, assembled from replayed prior-breach data and infostealer logs, with the hashes cracked offline. Read that again. The credentials came from earlier breaches and from malware sitting on people’s machines. The firewall didn’t leak them. The firewall did its job. The credentials were the problem, and the credentials were already gone long before anyone slapped a name on the pile.

FortiGate is the Honda of firewalls. It’s everywhere, it’s reliable, and it shows up in small clinics and Fortune 500 data centres alike. So when a dataset like this surfaces, it reads like the Fortune 500 because, statistically, it is. Ubiquity is why the list is long. It isn’t evidence the product failed.

FortiBleed is just the receipt

A credential dump like this is the receipt for hygiene failures that happened months or years earlier. Reused passwords. Admin logins that were never rotated after a known breach. Accounts that got scraped by an infostealer on some employee’s laptop and then sat valid because nobody changed them. The dataset is the proof of purchase for all of it, printed after the fact.

If you’re reaching for the patch notes, you’re reading the wrong document. There’s nothing to patch here. The exposure is identity, and identity doesn’t get fixed by a firmware update.

A password is a speed bump, not a barrier

Here’s the part that should bother you. For a lot of these devices, a valid credential is the whole game. Single-factor admin access to a firewall means the credential is the front door, and a stolen-but-valid password walks right through it. A password on its own is a speed bump. It slows an attacker by roughly the time it takes to paste it.

Multi-factor authentication is the barrier. With MFA on management access, a credential from a dump like FortiBleed is most of a key and not the whole key, and “most of a key” doesn’t open the door. That single control turns this entire dataset from an emergency into a cleanup. Yet management interfaces sit exposed with single-factor auth constantly, on devices guarding networks that matter.

The boring fixes are the real ones

There’s a grim irony in the patching reflex. Automatic updates are already on for most of these devices, and it makes no difference, because the firmware was never the issue. The fixes that actually matter are the ones that don’t feel urgent until they’re overdue:

MFA on every management interface, no exceptions for the device that happens to be convenient.
Rotation of admin and service credentials after any known breach, and on a schedule besides.
Infostealer hygiene on endpoints, because that’s where a lot of these credentials are harvested in the first place.
Management interfaces off the open internet, reachable only through controlled paths.

None of that is exciting. All of it would have made FortiBleed a non-event for your organization.

If your management access still rides on single-factor credentials, that’s worth fixing before the next dataset shows up with your devices in it. It’s the kind of thing I find on assessments.

Hans Study, CISSP, is an independent network and security consultant and fractional CISO in Ontario, Canada.

OT Network Security Controls That Hold Up

Hans Study — Sun, 18 Oct 2026 17:29:10 +0000

Operational technology is not enterprise IT with a different brand of switch. The protocols are older. The traffic is predictable. Uptime is absolute, and a control you would apply without thinking on the corporate network can take a plant offline.

That is why OT advice copied out of IT playbooks fails in the field. The controls below hold up, because they respect how industrial systems actually run.

Zones and conduits, not a flat plant

Segmentation is the foundation. The OT version is more deliberate than VLANs on the corporate side.

IEC 62443 frames it as zones and conduits. Group assets by function and risk into zones. Define exactly what crosses between them, through controlled conduits. Default to deny. The Purdue model gives you the layers to start from.

Watch for the flat plant network where the historian and the safety system share a broadcast domain. That is the most common OT finding I see, and the most dangerous.

Put an iDMZ between the plant and the business

IT and OT converged whether anyone planned it or not. What matters now is whether the boundary is controlled.

Build an industrial DMZ. Nothing on the business network talks directly to the plant. Data that has to move, historian replication or remote views, moves through brokered services in the iDMZ. A compromise on the corporate side then hits the DMZ instead of the controllers.

If a business-network machine can open a socket straight to a PLC, you do not have a boundary. You have a label.

Know the protocols, because they will not defend themselves

Modbus, DNP3, S7, EtherNet/IP, and OPC have little or no authentication by design. You cannot patch that away.

So account for it. Protocol-aware segmentation. Deep packet inspection where it earns its keep. A clear answer to what each conduit is allowed to carry. Treating industrial protocols like HTTP is how IT-style controls break OT.

Monitor passively, because active scanning breaks things

A vulnerability scanner that is routine on the corporate network can knock an old PLC offline just by probing it. I have watched it happen. NIST says the same thing; active scans may cause device instability or interfere with the device process state (NIST SP 800-82 Rev. 3, Appendix E.2.3).

Monitor passively instead. Tap the traffic, baseline what normal looks like, and alert on the deviation, without ever sending an unsolicited packet to a control device. You get visibility into the 200 devices nobody inventoried. You also avoid being the reason the line stopped.

Make remote access deliberate

Vendors and operators need in. The default is a flat VPN into the plant, or a forgotten cellular modem on a panel, and that is how the quiet intrusions get their foothold.

Broker it. Route remote access through a jump host in the iDMZ, monitored and time-boxed, with multi-factor on the way in and a recording of what was done. Convenient back doors are how state-linked actors live off the land inside critical infrastructure for months at a time.

Patch on the plant’s terms, and compensate when you cannot

OT patches lag for real reasons. A reboot is a production event. Vendor certification takes time. Some systems will never be patched, because the vendor is gone.

Pretending otherwise is not a plan. Tie a patch cadence to maintenance windows for what you can patch. Then wrap compensating controls around what you cannot: tighter segmentation, monitoring, access restriction.

An unpatchable system behind a tight conduit is defensible. An unpatchable system on a flat network is an incident waiting for a date.

Keep safety systems separate

Safety instrumented systems exist to bring a process to a safe state. They do not belong on the same network as everything else.

Separate the SIS from the basic process control system, physically or logically. (NIST SP 800-82 Rev. 3, section 2.3.7: SIS and BPCS independence; IEC 61511.) Get that wrong and a security incident becomes a safety incident. Keep them apart.

Own it across the boundary

The hardest part of OT security is the seam, not any single control.

The plant team owns uptime. IT owns the network. Security owns policy. The OT network falls in the gap between all three. It is the same ownership gap that swallows physical security networks.

Someone has to own the converged environment end to end, with the authority and the budget that go with it. Name them before the next integration, not during the incident review. Unowned infrastructure does not get secured, and on a plant network the cost of that is measured in more than data.

If your clients sit in a sector that will be designated under the Critical Cyber Systems Protection Act, these are the controls their supply chain questions will reach for.

None of these controls require breaking the process to secure it. They require understanding the process well enough to secure it the way it actually runs. That is the whole job.

If you are working this on a live plant network, industrial and OT network advisory is the engagement that covers it.

CPCSC for security integrators: what changes

Hans Study — Sat, 17 Oct 2026 17:26:29 +0000

Most integrators file CPCSC under “the client’s problem.” The defense supplier gets certified, the crew installs the cameras and card readers, and somebody in an office handles the paperwork.

That holds until you open the project folder.

What CPCSC is, in one paragraph

CPCSC is Canada’s cyber security certification for defense suppliers. It covers any organization whose systems store, process, or transmit Specified Information under a Department of National Defence contract. Specified Information is sensitive but unclassified data the contract says has to be protected. Level 1 has been in select contracts since the summer, and PSPC’s timeline puts Level 2 third-party assessments between April 2027 and March 2028. The requirement follows the data down the supply chain, and there’s no exemption for being 3 tiers below the prime.

3 ways integrators end up in scope

The project files

On a defense site, the drawings, the device schedule, the IP plan for the security network, and the door and camera layouts can all be Specified Information. Once they’re on your commissioning laptops, your project share, or the email thread with the GC, those systems are in scope. So are the backups.

Remote support

If your techs remote into a client’s VMS or access control server, that connection becomes part of the client’s assessment. The assessor will ask how you get in, who on your bench can reach it, and whether MFA is enforced on that path; 03.07.05 requires it for non-local maintenance.

The gear itself

CPCSC certifies organizations, not products, so there’s no such thing as a CPCSC-compliant camera. But a camera, NVR, or controller on the same network as the contract data is an endpoint someone can use to get in. It gets judged on how it’s configured.

What changes on the install side

Most of this is habit, and none of it needs new hardware.

Treat project data for defense sites like an enclave, with encrypted laptops and one controlled project share
Move drawings through a managed transfer path instead of email
Keep a list of who on the crew had access to which project
Purge project data at close, after checking the contract’s retention clause
Put security devices on their own network segment, denied by default
Change every default password before a device touches the network
Give each technician a named account on the VMS and controllers, not a shared “admin”
Route remote support through a jump host with MFA and session recording

That last one matters more than it looks. I’ve seen MSPs with a remote tool on every machine tell me “this is how we do it,” and that’s how whole fleets get wiped.

How to get ahead of it

Start with your own company

Run the CPCSC Level 1 self-assessment on your own systems. Primes evaluating subcontractors will ask, and Level 1 includes multi-factor authentication. That one catches integrators who’ve been running the shop on passwords.

Write down who does what

A short responsibility matrix in the service agreement says which controls you operate and what evidence you hand over, on what schedule. Assessors read it first.

Hand the client their evidence

The physical protection requirements in ITSP.10.171 cover who’s allowed in, monitoring who goes where, and controlling the doors. The evidence for all of it lives in systems you install: the access list export, the door event report for the server room, the held-open alarm settings, the camera coverage of the entry. An integrator who delivers that pack at commissioning, and again at each service visit, becomes part of the client’s readiness.

Why this is an opening

I’ve seen a prime contractor’s internal network requirements first-hand, and the gap between those and what reaches its small suppliers is wide. Integrators sit right in that gap, carrying the prime’s drawings around in a truck.

Most of the market hasn’t noticed yet… the firms that close that gap first are the ones primes will want back on the next bid.

The free CPCSC hub is at hans.study/cpcsc/, with a page for MSPs and integrators. Policy templates are at hans.study/cpcsc/templates/.

CPCSC physical security: access control and CCTV

Hans Study — Fri, 16 Oct 2026 18:16:51 +0000

Physical security is the part of CPCSC most small suppliers assume they’ve already covered. The doors lock, the alarm company comes every year, there’s a camera at the front entrance. Then they read the physical protection family in ITSP.10.171 and realize it asks for something different from a locked door. It asks for proof.

2 of the 13 Level 1 requirements are physical: 03.10.01, physical access authorizations, and 03.10.07, physical access control. Level 2 adds the rest of the family: 03.10.02 for monitoring physical access, 03.10.06 for alternate work sites, and 03.10.08 for access control over transmission lines. An access control system and a camera system, set up properly, produce most of the evidence for all 5.

Who’s allowed in: 03.10.01

The requirement is an approved list of people allowed into the areas where systems holding Specified Information live, issued credentials to match, and a review on a schedule you choose. The access control system already holds the list. What’s usually missing is the review.

Export the cardholders with access to the enclave doors every quarter, compare them to HR’s active list, remove the ones who shouldn’t be there, and keep the export with a date and a name on it. That export is your evidence. The most common finding is a departed employee’s card still active on the server room door, and a quarterly export catches it.

Controlling the door: 03.10.07

This is where the configuration matters.

Credential technology. 125 kHz proximity cards clone in seconds with cheap hardware. The floor I’d set is 13.56 MHz Seos or iCLASS SE with custom keys, not the standard keyset, in a corporate format such as HID Corporate 1000. HID’s February 2024 advisories (CVE-2024-23806) showed keys could be extracted from iCLASS SE configuration cards and encoders, so keep reader firmware current, lock out configuration-card changes, and disable legacy and 125 kHz technologies at the reader so a cloned old-format card can’t downgrade its way in.
Reader wiring. Wiegand sends card data in the clear between reader and controller. OSDP with Secure Channel encrypts it, and new installs should use it.
Card plus PIN on the doors that matter: the server room, the engineering area, secure storage.
Held-open and forced-door alarms enabled on the enclave doors, routed to someone who’ll respond.
Visitors logged and escorted, with a visible difference between staff, screened contractors, and visitors. Coloured lanyards and different card designs cost almost nothing, and an assessor sees them in the first 5 minutes.
Anti-passback and tailgating controls matched to the risk, from signage to a turnstile to a 2-door vestibule. A fastener supplier on a defense program doesn’t need the same as a firm building armoured vehicle subsystems.

Watching the door: 03.10.02

Monitoring means you’d notice, and could reconstruct, who went where. Cameras on the entries and main routes, with at least one identification-grade camera at the enclave entry. A camera that shows somebody walked past isn’t the same as one that shows who it was; thermal cameras detect people but rarely identify them, which is worth knowing before you choose coverage for the door that matters most.

Then join the systems up. The door event, the video at that door, and the user’s login should share a clock. Sync the access controllers, the recorders, and the servers to one time source, as 03.03.07 asks of every system’s time stamps, so an investigation doesn’t start with an argument about which clock was wrong.

The parts people miss: 03.10.06 and 03.10.08

Alternate work sites are the engineer’s home office and the laptop in the truck. If Specified Information goes home, the requirement goes with it, and the rules for protecting it there belong in writing.

Access control for transmission covers the cabling. Network runs through an open warehouse ceiling or a shared riser can be tapped; locked telecom rooms and enclosed pathways for the runs serving the enclave are the fix. Integrators see these runs every day and rarely think of them as a security control.

The systems protecting the systems

Your access control server and VMS hold the evidence, which puts them inside the boundary. They get the same treatment as anything else there: named accounts, MFA where the platform supports it, patching on a schedule, their own network segment, and remote access through a controlled path. A card system on the office network with a shared admin login undermines everything it records.

The evidence pack

When the assessor asks, this is what you hand over:

Quarterly access list export with reviewer and date
Door configuration showing held-open and forced alarms on the enclave doors
A sample door event report for the enclave door
Camera coverage snapshots for the entries and the enclave door
The visitor log and the escort rule
The credential format, key program, and reader configuration
Time synchronization settings on the controllers and recorders
The retention periods you chose for door events and video, written in the system security plan

None of this needs new hardware in most buildings. It needs the systems you already own set up to prove what they do. The physical protection page on the CPCSC hub covers each requirement, and there’s a free access review record for the quarterly export.