DEV Community: Hans Study

How scoping took a machine shop from 40 devices to 9

Hans Study — Wed, 28 Oct 2026 19:46:41 +0000

A shop owner told me last spring that CPCSC couldn't apply to him because his DND-connected work was 4 percent of revenue. We found Specified Information in 6 places in an afternoon: the quoting folder, 2 engineers' laptops, the shared drive, his own email, and the cloud backup of everything above.

The program applied to 4 percent of his revenue and roughly 80 percent of his network. That ratio is normal, and it is the whole argument for scoping before anything else.

Scope is the denominator

Every control you implement, document, and prove applies to every system inside your boundary. A supplier that confines contract data to an enclave assesses the enclave. A supplier that lets drawings spread across every laptop and mailbox assesses the whole company. Same controls, same standard, and the second supplier pays several multiples of the first.

What the shop looked like

This is the machine shop the way I keep finding them. CAD workstations, the software driving the CNC machines, the office PCs, and the owner's laptop, all on one small business network behind a modem-router combo. 1 flat subnet, consumer wifi, no segmentation. The customer's drawings were reachable from every device in the building, which put every device in the building in scope.

The build was an architecture job, not a paperwork job. A real firewall at the edge. The shop floor split from the office. Wifi on its own segment. And an enclave for the drawings: 1 file server, 3 workstations, a managed transfer tool for receiving drawings, and a firewall rule set I could read in one sitting.

In-scope devices went from roughly 40 to 9. The build cost a few weeks of an integrator's time and some licensing. The alternative was bringing 40 devices, including the owner's home laptop, to a Level 2 standard by 2027.

The moves, in order of value

Consolidate storage first. 1 project share, or 1 enclave file server, instead of copies on personal drives. That move usually removes more systems from scope than any other.

Contain email second. Every mailbox that ever received a drawing is a system holding Specified Information. Route contract data through a managed transfer folder or a dedicated project mailbox, and make "don't email drawings" a rule with an easy alternative attached, because rules without easy alternatives lose to deadlines.

Separate the enclave third, with its own workstations or virtual desktops, real firewalling at its edge, and its own backup job. For a shop where defense is a minority of revenue, this turns "certify the company" into "certify the room."

Last, purge the echoes: old proposals, dead projects, departed employees' mailboxes. Check the contract's records retention clause first, because some contract data has to be kept for years, and that data gets archived into the enclave rather than deleted.

The owner's laptop

The owner's laptop is where small-shop scoping goes to die. Every shop has the folder. It's named "DND stuff" or "Project X" or just "Drawings," it lives on the machine that also does the banking and the kids' homework, and it's synced to a personal cloud account for convenience.

Nobody wants to tell the owner their laptop is in scope, so the map omits it, and the enclave is fiction from day one. Tell the owner. I've had that conversation a dozen times this year. It takes 5 awkward minutes, the fix is a managed workstation and a habit change, and it beats an assessor finding the folder in minute 20 of the first interview.

One test for "real" separation

Systems that connect to the enclave but are kept from the data by real technical separation can sit outside it. The word doing the work is "real." A VLAN with an any-any rule between segments is a diagram, not a separation.

State of Cyber Hygiene in Ontario: 4,450 Small Businesses Checked

Hans Study — Wed, 28 Oct 2026 18:02:03 +0000

Most weeks I am looking at the networks behind courthouses, water utilities, law enforcement, and the suppliers who build for defence. Big systems, long audits, rooms full of people whose job is to worry about this. Last week I turned the same eye on the other end of the street: the bakery, the law office with two lawyers, the HVAC company with a truck and a website a nephew built in 2017.

I did it because of a bug, and because it felt like the right time, and close to a public service.

On October 21 the PHP project shipped an emergency fix for two flaws, now nicknamed PHP2Shell, that let an attacker take over a web server without a password. PHP runs most of the web, so this is not a problem for someone else’s data centre. It is a problem for whoever runs the software behind the quote form on a local contractor’s site. Within days the United States cyber agency had it on the must-patch list, and Amazon said it had seen attempts before the bug was public.

So I asked a simple question. How exposed are the businesses in my own corner of Ontario, right now?

What I did, and what I did not do

This was not a public records search. I looked at the public-facing side of 4,450 small businesses across seven regions, London and Middlesex County, Sarnia-Lambton, Chatham-Kent, Kitchener-Waterloo, Cambridge, Brantford and Brant County, and Windsor-Essex, and checked for the things I would flag in one of my audits: how their email is set up, whether the software behind the website is current, whether the padlock works, and what their domains give away.

Every one of them runs a website on a domain of its own. Shops, trades, clinics, firms, and contractors. Not chains, and not government. Each was looked at from the outside, the way any visitor could: public DNS records and one visit to the home page. Nobody was hacked or scanned, and no business is named.

This is not name and shame. It is meant to draw attention to things we do not normally pay attention to.

What turned up

The headline, given why I started, is PHP. At least 149 of these local sites are advertising a PHP version that is either behind the PHP2Shell fix or on a release line that will never be patched. Read that as a floor, not a ceiling. Most sites hide their version, so the real number is higher.

The number that bothered me more was email. Of the 3,539 businesses that receive email, 2,942 can be impersonated. That is 83%. There is a DNS record called DMARC that tells Gmail and Outlook to throw away a message forging your address, and four of every five local businesses have not turned it on. That is how a fake invoice, with a real logo and a real signature, lands in a customer’s inbox looking exactly like it came from you. Invoice fraud almost always starts there.

The rest is a grab bag of small, fixable things:

442 domains have no SPF record at all, the most basic email check there is.
1,593 sites run WordPress. 206 of those that reveal a version are behind on security updates, and 229 sites still load a code library retired in 2016. 454 take card payments on that same software.
235 sites serve a broken, expired, or missing certificate.
359 domains that businesses are still listed under no longer work, and 132 more show a parking page. An abandoned domain can be re-registered by anyone, who then receives the mail meant for that business.

Every region has its own report with the breakdown by sector, by town, and by hosting platform, and the method and its limits spelled out. They are all on the State of Cyber Hygiene in Ontario hub, with a map.

The front door nobody has to drive to

When we talk about securing infrastructure, from courthouses to municipal water utilities, there are always holes. Something does not function the way it was intended or designed, something failed, or something was overlooked, on both the physical and the digital side. I see it all the time: a temporary fix becomes permanent, and that becomes the vulnerability. Small businesses are no different.

We look after the physical side without thinking about it. A broken door, a lock that does not latch, a camera someone has covered: we see those and fix them the same day. We are not always paying attention to the same things in the digital world, and the threats there are real, with real impact and real damages.

The biggest change in the last thirty years is that instead of a criminal needing to drive to your business, they can now reach it from the other side of the globe without getting out of their chair. We need to take the same steps on the digital side. At least put a lock on the front door. At least make sure the windows are closed. At the very least, make sure the front door is shut.

This is not a competence problem

I do not want anyone to take the wrong thing from this. These owners are not careless, and they are not foolish. They are busy running a business, and nobody ever sat them down and told them that an afternoon of free changes, to records they probably do not know they have, would close most of the gap. There is no villain here. There is a gap between what is normal and what is possible, and almost nobody told the people on the small end of it.

That gap is the whole reason the fixes are published next to the findings. Five changes close most of what I found, and none of them need new software:

Stop people sending email as you. Publish SPF, turn on DKIM, and set DMARC to quarantine or reject.
Patch the website platform, and hide its version. Keep WordPress, its plugins, and PHP current, and turn off the version numbers in the page and the headers.
Force HTTPS and keep it on. Redirect every visitor to the encrypted site and add an HSTS header.
Turn on multi-factor authentication. On the website admin, the email, and the hosting panel. Remove old staff accounts.
Mind the domains you are not using. Keep them renewed with mail turned off, or let them go on purpose, not by accident.

If you only do one, do the first. It is the most common gap, the cheapest to fix, and the one most likely to cost you or a customer real money.

Where this goes

Seven regions are up. Hamilton-Niagara, the Toronto area, and Ottawa are next, and the plan is to work across Ontario region by region until there is a picture of the whole province and a plain playbook to go with it. Not to sell fear. To put real local numbers next to a national story, and to give small businesses a reason, and a way, to spend the afternoon.

The reports, the combined numbers, and the five fixes are at hans.study/state-of-cyber-hygiene. If you run one of these sites and want to know where you landed, the data is there, and so is my inbox. If you would rather hand the whole list to someone and have it done, book a scoping call.

References

CVE-2026-109618, PHP unauthenticated remote code executionPublished October 21, 2026

NIST National Vulnerability Databasenvd.nist.gov
Known Exploited Vulnerabilities CatalogEntries added October 26, 2026

CISAcisa.gov
RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)March 2015

IETFrfc-editor.org
Baseline cyber security controls for small and medium organizationsCurrent edition

Canadian Centre for Cyber Securitycyber.gc.ca

Outbound links open in a new tab. Source-pinned. If a vendor moves a doc, this block gets updated.

Genetec Architecture, Roles, and Workstations

Hans Study — Tue, 27 Oct 2026 19:34:12 +0000

Genetec Security Center, Server Role Architecture

All roles communicate through the Directory. The Archiver, Access Manager, and Media Router are independent roles that can run on separate servers.

The most expensive problems in Genetec Security Center deployments are almost always architectural. Roles placed on the wrong servers. Database failover configured incorrectly from day one. Media Router settings left over from an upgrade three versions ago. Workstations struggling because nobody tuned them for video. These problems are invisible during installation. Everything works fine when you commission it. They surface six months later when the system is under load, when the client starts using features they were not using during testing, or when you add cameras to a system that was not designed with headroom.

This post covers the architecture decisions that determine how a Genetec Security Center environment performs and scales. The recommendations are based on Genetec’s published enterprise guidance and findings from real system assessments across government, law enforcement, airports, and enterprise environments. The same review pattern is offered as an engagement via the Genetec Health Check; broader scope and ongoing advisory live under Genetec Security Center consulting.

The Server Role Model

Genetec Security Center uses a role-based architecture. Each role is a software component that handles a specific function. Roles are assigned to servers. Multiple roles can run on the same server in smaller deployments. Larger deployments separate roles onto dedicated hardware. Understanding what each role does is the foundation for making good architectural decisions.

Archiver

The Archiver manages camera recording. It connects to cameras, pulls their video streams, and writes them to storage. In most deployments, the Archiver is the most resource-intensive role because it is handling continuous video ingestion from multiple cameras simultaneously.

Archiver sizing depends on camera count, resolution, frame rate, codec, and retention period. Genetec publishes sizing guidance that is regularly updated. As a starting point: an Archiver server handling 50 to 80 standard cameras at 1080p H.265 should have a minimum of 16GB RAM and multiple dedicated storage drives for the video archive, separated from the OS drive. The specific numbers depend heavily on bitrate, which is why camera configuration needs to be finalized before server sizing.

Do not mix Archiver roles and Directory roles on the same server in deployments above approximately 50 cameras. The storage and I/O requirements of an Archiver in production conflict with the database I/O requirements of the Directory under load.

Access Manager

The Access Manager handles the Synergis access control integration. It communicates with HID, Mercury, and Axis door controllers, manages cardholder data synchronization, handles access decisions, and processes events from access control hardware. In environments using Genetec Synergis for access control, the Access Manager role must be online for access control to function.

The Access Manager can share a server with the Directory in smaller deployments. In larger deployments with thousands of doors and cardholders, a dedicated server improves responsiveness and simplifies troubleshooting. I/O on the Access Manager is lower than on the Archiver, so dedicated server requirements are less stringent.

Media Router

The Media Router handles live and playback video streams for Security Center clients. When a client opens a live view or plays back recorded video, the stream is routed through the Media Router. This role is particularly important in environments where clients are on different network segments than cameras, where there are firewall traversals involved, or where load balancing of video streams is needed.

Incorrect Media Router configuration is one of the most common causes of video playback problems in Genetec environments. The Media Router needs to be accessible from both the cameras (or Archiver, for playback) and the clients. In environments where the Media Router settings were left from an older configuration or an upgrade that changed the network topology, clients frequently receive degraded video or playback timeouts that are misdiagnosed as storage or camera problems.

Media Router configuration requires specifying the redirect addresses, the IP addresses that cameras and clients use to reach the Media Router. Getting these wrong means video streams get sent to addresses that clients cannot reach. Always verify Media Router redirect addresses after any network topology change or server migration.

Health Monitor

The Health Monitor collects health data from all roles and entities in the system, detects faults and offline conditions, and generates alarms when things stop working correctly. It is a support role that improves operational visibility but is not in the critical path for camera recording or access control operation.

The Health Monitor should be deployed in any production environment. The value of having automated fault detection is immediate the first time a camera goes offline at 2 AM and the operator gets an alert rather than discovering it during the next morning’s review.

Server Sizing Principles

Genetec publishes detailed server sizing guidance in their enterprise best practices documentation (EN.500-BPEN, updated with each major version). The numbers below are starting points for planning conversations, not substitutes for the official sizing guide for the specific version and camera count.

Deployment Scale	Camera Count	Recommended Architecture	Min Archiver RAM
Small	Up to 50	All roles on single server	16 GB
Medium	50, 200	Directory + Access Manager / Archiver(s) separate	32 GB
Large	200, 500	Dedicated server per major role	64 GB+
Enterprise	500+	Multiple Archivers, federated architecture	128 GB+

Storage sizing is separate from server sizing. Video storage requirements depend on camera count, resolution, frame rate, codec, scene complexity, and retention period. The storage calculator in Genetec’s documentation gives reasonably accurate estimates when you feed it real bitrate data from the cameras. Scene complexity is the variable that surprises people most: a parking lot camera at night in clear weather generates very different storage requirements than the same camera in a busy urban environment during the day.

Size for peak, not average. Archive storage estimates based on average bitrate will be wrong during events. When an alarm triggers and cameras switch to high bitrate, or when there is significant motion in the scene, storage consumption increases substantially. Build in at least 20 to 30 percent headroom above the calculated requirement.

Database Configuration

Genetec Security Center requires SQL Server. The edition depends on the deployment size and the database features required. SQL Server Express has a 10 GB database size limit, which is exceeded quickly in any environment with significant event history. SQL Server Standard or Enterprise is required for production deployments.

Key SQL Server configuration items for Genetec environments:

Max Server Memory: Set this explicitly. On a server where SQL shares resources with Genetec roles, leave adequate memory for the Genetec processes. Leaving SQL memory at the default (unlimited) means SQL will expand to fill available RAM, starving Genetec processes under load.
TempDB location: Move TempDB to a dedicated drive if possible. Genetec generates significant TempDB I/O during queries. Keeping TempDB on the same drive as the system or application databases creates contention.
Database maintenance: Index fragmentation in the Genetec database degrades query performance over time. Schedule regular index maintenance. Genetec’s GUS tool (Genetec Update Service) performs some automated maintenance, but database-level maintenance is separate.
Backup: The Security Center database contains all system configuration, cardholder data, and event history. It must be backed up regularly. Test the restore procedure.

Workstation Optimization

Security Center client workstations handle video decoding for the streams displayed in Security Desk. The GPU does most of the heavy lifting for video rendering. An undersized GPU shows up as dropped frames, high CPU usage, and operator complaints about delayed or choppy video.

For Security Desk workstations displaying multiple simultaneous video panes:

GPU: A dedicated GPU with hardware H.264/H.265 decode support is required for any multi-pane display configuration. Intel integrated graphics is not sufficient for a workstation displaying 16 or more simultaneous streams. Nvidia Quadro or comparable professional GPU for display-intensive operator workstations.
RAM: 16 GB minimum for a standard operator workstation. 32 GB for workstations handling high-resolution or high-count video panes.
Display outputs: Verify that the GPU supports the number of display outputs the operator needs. Running a video wall through daisy-chained consumer monitors using USB-to-DisplayPort adapters is a support nightmare.
Network: The workstation’s network connection needs to handle the aggregate video bandwidth being decoded. A workstation pulling 16 simultaneous 5MP H.264 streams at 8 Mbps each requires 128 Mbps of sustained throughput. A 100 Mbps network connection is undersized for that configuration.

Power plan on workstations should be set to High Performance. The Balanced power plan throttles CPU and GPU clock speeds, which directly affects video decode performance. This is the same setting that causes problems on Archiver servers, and it is equally wrong on operator workstations.

Naming Conventions

A consistent naming convention for Genetec entities makes the system significantly easier to operate, troubleshoot, and hand off. The convention does not need to be elaborate. It needs to be applied consistently from day one.

Camera naming: [Site]-[Floor/Area]-[Camera Type]-[Number]. For example: HQ-B2-CAM-001 for the first camera in the basement of headquarters. The Security Center client sorts entities alphabetically, so a prefix-based convention groups related cameras automatically in the tree view.

Server and role naming: Match the server hostname to what it does. GSC-DIR-01 for the first Directory server. GSC-ARC-01 for the first Archiver. This makes the Diagnostic tool and Health Monitor significantly easier to read when there are multiple servers in the environment.

Archiver naming: If using multiple Archivers, give them names that reflect which cameras they manage (by building, by floor, by area). When a camera drops from an Archiver, knowing which Archiver it is by name immediately tells you which area of the building to investigate.

Federation and Multi-Server Considerations

Genetec Federation allows multiple independent Security Center systems to appear as a single unified view to operators. This is the architecture for organizations with multiple sites that each have their own Security Center deployment and their own local administration, but where central operators need visibility across all sites.

Federation is not the same as a single system with multiple Archivers. In a federated environment, each site is an independent system. The Federation Server on the parent system connects to the child systems and makes their cameras, events, and entities visible to the parent operators. Cardholder data does not automatically synchronize across federated systems, that requires Global Cardholder Synchronization, a separate feature.

The decision between a distributed single-system architecture and a federated multi-system architecture depends on whether the sites need independent administration, whether WAN connectivity between sites is reliable enough to support a unified system, and whether cardholder data needs to be unified. Getting this decision wrong at the architecture phase is expensive to fix later.

Common Architectural Mistakes

Directory and Archiver on the same undersized server. Works during testing. Degrades under load. The Archiver’s storage I/O competes with the Directory’s database I/O, and both compete for RAM with SQL Server.

Media Router not configured for the actual network topology. The default Media Router redirect addresses point to localhost. This works when clients are on the same server. It does not work when clients are on a different subnet. Always explicitly configure the redirect addresses to match the actual network.

SQL Server memory unconfigured. SQL will consume all available RAM on the server if not explicitly limited. Genetec processes on the same server will eventually get memory-constrained and degrade.

No storage redundancy on the Archiver. A single drive failure on an Archiver with no RAID takes down recording for every camera on that Archiver. At minimum, the media storage volumes should be RAID 5 or RAID 6. The system drive should also be protected, losing the OS drive on an Archiver takes down all cameras on that server just as completely.

Power plan not set to High Performance. The Balanced power plan throttles performance in ways that are difficult to diagnose. On a server with a CPU that looks adequate on paper but cannot keep up in production, the first thing to check is the power plan. It is almost always the cause when a system runs well under light load and degrades under production load.

Most of these mistakes pass commissioning and surface months later under load. If your system has grown beyond its original design assumptions, a Genetec Health Check finds them before they turn into an incident, and the Health Check Checklist covers the same ground if you want to walk it yourself first.

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.