Hans Study, Articles

Hardening Genetec Security Center: The Baseline I Deploy

hans@hans.study (Hans Study) — Sat, 27 Jun 2026 00:00:00 GMT

Hardening a Genetec deployment is not the same job as tuning one. Tuning makes a working system fast. Hardening makes a working system defensible, and the two pull against each other often enough that most deployments quietly skip the second one. The result is a security platform that records beautifully and would fall over the first time someone leaned on it. Security Center is not one thing to harden. It is a set of Windows servers, a SQL database, a stack of service accounts, and a security application sitting on top, and each of those layers has its own baseline. Harden the application and ignore the Windows box it runs on and you have hardened nothing. Here is the baseline I actually deploy, in the order I deploy it. ## Start with the operating system, not the application The Directory, Archiver, and Access Manager roles run on Windows Server. That server is the real attack surface, and it gets a server baseline before Security Center is touched: CIS or DISA STIG as the reference, trimmed to what the VMS workload tolerates. The trimming is the skill. A stock STIG will break Genetec in a dozen small ways, so you apply the baseline, test the platform under load, and document every exception with a reason. An exception you can explain is a control. An exception nobody remembers making is a hole. Workstations running Security Desk get the same treatment at the client baseline. Operators do not need local admin, and the box they watch video on should not be the box they read email on. ## Defender exclusions, scoped, not disabled This is where most Genetec deployments go wrong. Antivirus scanning the video drives kills recording performance, so somebody disables Defender entirely, and now the server that watches the building has no endpoint protection at all. That is not hardening, that is surrender. The right move is scoped exclusions. Exclude the specific Genetec process and database paths Genetec documents, exclude the active video storage volumes, and leave real-time protection on everywhere else. Scoped exclusions keep recording fast and keep the server defended. Blanket disabling does neither. ## Service accounts that cannot become domain admin Genetec roles run under service accounts, and the lazy deployment runs them all under one over-privileged account, sometimes a domain admin, because it makes the install work on the first try. That account is now a key to the whole domain, sitting in a service that faces the network. Each role gets its own account with the least privilege it needs, group-managed service accounts where the version supports them so nobody is rotating passwords by hand, and nothing in the Domain Admins group. The SQL service account is separate again. If a service account is compromised, the blast radius should be the role, not the forest. ## The database is a server too Security Center's SQL Server gets hardened like any other production database: a dedicated service account, Windows authentication, TLS on the connection, the surface area trimmed, and backups that are tested by restoring them, not by checking a box that says they ran. The Directory database is the system of record for who can open which door. Treat it that way. ## Segment before you certify Cameras, controllers, the Genetec servers, and operator workstations belong on their own segments, with the traffic between them and the business network controlled and logged. A flat network where the lobby camera can reach the finance server is a design failure even when every camera shows a perfect picture. Camera VLANs isolated, server-to-server traffic understood, client access controlled. Most Genetec performance problems that get reported as platform bugs are actually network problems, and segmentation is where you prevent both the performance problem and the breach. ## Replace the certificates Fresh installs run on self-signed certificates, and self-signed certificates train everyone to click through the warning, which trains everyone to ignore the warning that matters. Replace them with certificates from your internal CA, enable TLS on the Directory and the web components, and the encrypted-by-default posture stops being a someday item. ## Least privilege in the application, finally Now the application. Custom privilege templates instead of the built-in administrator for everyone, partitions that actually partition, operators who can see and do exactly what their job requires and nothing else. Security Center 5.14 made custom privilege templates materially better, so the excuse for everyone-is-an-admin is gone. ## Patch on a real cadence, log like you mean it Patching a VMS lags because you wait for Genetec to certify a Windows update against the platform, and that lag is real, but it is a schedule, not a permanent exemption. Decide the cadence, write it down, and hold to it. And turn on the logging that lets you reconstruct an incident: process creation auditing (Event 4688), Windows Event Forwarding off the security servers to somewhere central, and a tuned Sysmon config. A hardened system with no logs tells you nothing the morning after. None of this is exotic. It is the baseline that should have been part of the deployment, applied with the discipline a security platform deserves, because the system you bought to watch the building is also the easiest way into it if you leave it soft.

Security Controls for OT Networks That Hold Up in Production

hans@hans.study (Hans Study) — Sat, 27 Jun 2026 00:00:00 GMT

Operational technology is not enterprise IT with a different brand of switch. The protocols are older, the traffic is predictable, the uptime requirements are absolute, and a control you would apply without thinking on the corporate network can take a plant offline. That is why the OT security advice that gets copied from IT playbooks fails in the field. The controls below are the ones that hold up, applied in a way that respects how industrial systems actually run. ## Zones and conduits, not a flat plant The foundational control is segmentation, but the OT version of it is more deliberate than VLANs on the corporate side. IEC 62443 frames it as zones and conduits: group assets by function and risk into zones, define exactly what is allowed to cross between them through controlled conduits, and default to deny. The Purdue model gives you the layers to start from. A flat plant network where the historian and the safety system share a broadcast domain is the single most common and most dangerous OT finding. ## Put an iDMZ between the plant and the business IT and OT have converged whether anyone planned it or not, and the question is whether the boundary is controlled. The control is an industrial DMZ: nothing on the business network talks directly to the plant. Data that has to move, like historian replication or remote views, moves through brokered services in the iDMZ, so a compromise on the corporate side hits the DMZ and not the controllers. If a business-network machine can open a socket straight to a PLC, you do not have a boundary, you have a label. ## Know the protocols, because they will not defend themselves Modbus, DNP3, S7, EtherNet/IP, and OPC have little or no authentication by design. You cannot patch that away, so the control is to account for it: protocol-aware segmentation, deep packet inspection where it earns its keep, and a clear answer to what each conduit is allowed to carry. Treating industrial protocols like HTTP is how IT-style controls break OT. ## Monitor passively, because active scanning breaks things The vulnerability scanner that is routine on the corporate network can knock an old PLC offline just by probing it. The OT control is passive monitoring: tap the traffic, baseline what normal looks like, and alert on the deviation, without ever sending an unsolicited packet to a control device. You get visibility into the 200 devices nobody inventoried without being the reason the line stops. ## Make remote access deliberate Vendors and operators need in, and the default of a flat VPN into the plant or a forgotten cellular modem on a panel is how the quiet, patient intrusions get their foothold. The control is brokered, monitored, time-boxed remote access through a jump host in the iDMZ, with multi-factor on the way in and a recording of what was done. Convenient back doors are how state-linked actors live off the land inside critical infrastructure for months. ## Patch on the plant's terms, and compensate when you cannot OT patches lag for real reasons: a reboot is a production event, vendor certification takes time, and some systems will never be patched because the vendor is gone. Pretending otherwise is not a plan. The honest control is a patch cadence tied to maintenance windows for what you can patch, and compensating controls, tighter segmentation, monitoring, and access restriction, around what you cannot. An unpatchable system behind a tight conduit is defensible. An unpatchable system on a flat network is an incident waiting for a date. ## Keep safety systems separate Safety instrumented systems exist to bring a process to a safe state, and they do not belong on the same network as everything else. Physical or logical separation of the SIS from the basic process control system is not a nice-to-have, it is the line between a security incident and a safety incident. Keep it. ## Own it across the boundary The hardest part of OT security is not a control, it is the seam. The plant team owns uptime, IT owns the network, and security owns policy, and the OT network falls in the gap between them. Someone has to own the security of the converged environment end to end, with the authority and budget that go with it, named before the next integration, not discovered during the incident review. Unowned infrastructure does not get secured, and on a plant network the cost of that is measured in more than data. None of these controls require breaking the process to secure it. They require understanding the process well enough to secure it the way it actually runs, which is the whole job.

The Firewall Did Its Job: What FortiBleed Was Really About

hans@hans.study (Hans Study) — Mon, 22 Jun 2026 00:00:00 GMT

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](/advisory/consulting). *Hans Study is an independent security advisor and fractional CISO in Ontario, Canada.*

Why Your Physical Security System Is the Soft Spot in Your Network

hans@hans.study (Hans Study) — Mon, 22 Jun 2026 00:00:00 GMT

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. 1. **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. 2. **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. 3. **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. 4. **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. 5. **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](/advisory/ot-it-convergence), and it's the same gap I keep finding on [assessments](/advisory/consulting). *Hans Study is an independent security advisor and fractional CISO in Ontario, Canada, focused on the boundary where physical security, OT, and IT meet.*

Nobody Owns the Network Between the Integrator and IT

hans@hans.study (Hans Study) — Mon, 22 Jun 2026 00:00:00 GMT

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](/advisory/ot-it-convergence). *Hans Study is an independent security advisor and fractional CISO in Ontario, Canada. He has spent 2 decades on critical infrastructure, defence, and public safety networks.*

Genetec CVE-2025-43028: The ALPR Hole You Have to Close Yourself

hans@hans.study (Hans Study) — Tue, 16 Jun 2026 00:00:00 GMT

ALPR is the part of Security Center most people forget is even running. The cameras and doors get the attention. The license plate reader role sits in the background, quietly doing its job, until a CVE lands on it. This week one did. Genetec disclosed CVE-2025-43028, a high-severity vulnerability in the ALPR Manager role of Security Center. CVSS 8.2. The legacy protocol that Genetec Patroller and SharpV G1 and G2 cameras use to talk to the ALPR Manager can be abused to exfiltrate sensitive data the role handles. Genetec's own engineering team found it, and there's no evidence anyone has exploited it in the wild. Yet. **This is not only an AutoVu problem, and that's the part worth slowing down on.** The obvious read is that it hits plate-reading shops: municipalities, parking enforcement, campus and toll operators, anyone running Patroller in a vehicle or SharpV cameras on a pole. Those are squarely in the blast radius. But this is also the second serious bug in the ALPR Manager role in a matter of months. Back in October, CVE-2025-43027 was a 9.8 critical auth bypass in the same role, and the detail that caught everyone flat was this: the ALPR Manager has been enabled by default on every Security Center instance since 5.11.0.0, whether or not you ever licensed AutoVu. Meaning the role is probably running on your system even if you have never read a license plate in your life. So before you decide this isn't you, go look. **The newer protocol is fine. The old one is the problem.** SharpV cameras connected to the ALPR Manager over the LPM protocol are not affected. The LPM protocol is the secure path, and it's the one you want everything on. SharpV G3 is already there by default, so G3 deployments sit this round out. It's the legacy protocol, the one G1 and G2 cameras and older Patrollers still use, that carries the exposure. **Here's the trap, and it's the reason I'm writing this instead of just linking the advisory.** Patching does not finish the job. To keep fleets from dropping offline mid-migration, the updated ALPR Manager role keeps temporary backward compatibility, which means it will still accept connections from old, unsecure Patrollers after you patch. Update the role, update your Patrollers, walk away feeling done, and the legacy door is still propped open. You are not mitigated until legacy connectivity is off. That toggle turns off 2 ways. Automatically, once every previously connected Patroller has been updated to version 7.0.2 and has checked in at least once. Or manually, through the legacy Patroller connectivity (unsecure) switch in Config Tool, under ALPR, roles and units, live settings. Flip it off and any Patroller still running version 6 or below gets disconnected until it's upgraded. One thing to know going in: once legacy support is off, you cannot turn it back on. There's no undo, which is the point. The order of operations is not optional either. Update the ALPR Manager role first, then the Patrollers. Do it backwards and you'll have new Patrollers with nothing current to talk to. Genetec has also wired in a couple of guardrails worth knowing about: Config Tool now throws a warning when a Patroller connects on the legacy protocol, and Patrollers on version 6 and below can no longer be added at all. ## The steps, in plain order 1. Update Config Tool to the patch build for your Security Center version (table below). 2. Update the ALPR Manager role first. Grant the "register Patroller" privilege to whoever is going to register the units. 3. Update every Patroller to version 7.0.2 and connect each one to the ALPR Manager so the update registers. 4. Confirm the legacy Patroller connectivity (unsecure) toggle is off in Config Tool. Don't assume it flipped on its own. Go look at it. 5. Update all SharpV G1 and G2 cameras to the latest SharpV OS and make sure they're connected over LPM, not the legacy protocol. ## Affected versions and patches | Product | Affected versions | Patch | |---|---|---| | AutoVu Patroller | 6.7.1 and before | 7.0.2 | | Security Center 5.13 | 5.13.3.5 and before | 5.13.3.6 | | Security Center 5.12 | 5.12.2.13 and before | 5.12.2.14 | | Security Center 5.11 | 5.11.3.25 and before | 5.11.3.26 | | Security Center 5.10 | 5.10.4.29 and before | 5.10.4.30 | | Security Center 5.9 | 5.9.5.10 and before | 5.9.5.11 | | SharpV G1 | 13.8.3 and before | SharpV OS 13.8.4 | | SharpV G2 | 13.8.3 and before | SharpV OS 13.8.4 | | SharpV G3 | Not affected (already on LPM) | NA | | Any other Security Center version | All | Move to a supported version | **If you can't patch the fleet quickly, you still have a move.** Set legacy Patroller connectivity to off now. That mitigates the vulnerability and keeps old Patrollers out until they're upgraded to 7.0.2. And if you can't touch the ALPR Manager role or the SharpV cameras promptly, fall back to the basics: restrict network access to trusted sources only, and put the traffic behind a VPN or equivalent controls. None of that is a fix. It's a fence around the problem until you fix it. One more thing about that table. Yes, there's a patch for 5.9. No, that doesn't mean you should feel comfortable on 5.9, because [Security Center 5.9 is end of life](/genetec-5-9-end-of-life/) as of December 2025 and stopped receiving security patches. Read a late CVE fix for a dying version as exactly what it is, a courtesy, not a reprieve. Patch this, then plan your way off 5.9 before the next advisory shows up and there's nothing waiting for you. The patch closes the code. Turning legacy connectivity off closes the hole. Go confirm the toggle.

Genetec Security Center 5.9 Is End of Life

hans@hans.study (Hans Study) — Fri, 12 Jun 2026 00:00:00 GMT

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 quietly 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. **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.

The 10 Most Common Genetec Security Center Issues I See (And How to Fix Them)

hans@hans.study (Hans Study) — Mon, 01 Jun 2026 00:00:00 GMT

Most Genetec Security Center systems do not fail the way people expect them to fail. They pass commissioning. They look fine in the demo. Then six months later the playback stutters, an archive gap shows up in an investigation, an upgrade breaks something nobody tested, and everyone stands around the rack wondering what changed. Nothing changed. The problems were there on day one. They were just invisible under light load.

I have audited and remediated dozens of multi-server Security Center deployments across government, law enforcement, airports, healthcare, and enterprise campuses. The same ten problems show up over and over. None of them are exotic. Most are configuration and ownership failures, not software defects. Here they are, in the order I usually find them.

1. Under-spec'd or misconfigured servers

The server looks adequate on paper and falls over in production. Almost every time, the cause is one of three things: the power plan, SQL memory, or roles stacked on hardware that cannot carry them.

The Windows Balanced power plan is the single most common cause of Genetec performance problems on servers that appear correctly sized. It throttles CPU and storage I/O to save power. On a machine ingesting hundreds of continuous video streams, that throttling is poison, and it is almost impossible to attribute without checking for it specifically. Set every Genetec server to High Performance (powercfg /setactive SCHEME_MIN) and confirm it applied.

The second is SQL Server eating the box. SQL takes all the RAM you let it have. On a Directory server sharing resources with Genetec roles, leave the max server memory at default and SQL will expand until the Directory service starves. Set the cap explicitly.

The third is putting the Directory and the Archiver on the same undersized server past about 50 cameras. Works in testing. Degrades under load, because the Archiver's storage I/O fights the Directory's database I/O and both fight SQL for memory. Separate the roles. I covered the role model and sizing in detail in Genetec Security Center architecture and roles, and the server tuning in server configuration and performance tuning.

2. Storage designed for capacity, not performance

Someone sized the storage for retention days and stopped there. Big drives, lots of terabytes, and write performance nobody checked. Video archiving is a sustained sequential write workload, and a capacity-first array starves under it.

The usual findings: a single parity RAID 5 array carrying dozens of cameras, so one slow rebuild during a drive failure tanks recording for everything on it. Windows Search indexing left on, generating pointless I/O on a volume that nobody searches through Windows. The default 4 KB NTFS allocation unit on volumes holding multi-gigabyte video files. 8.3 short-name creation still enabled.

Fix the foundation. Size for peak bitrate, not average, and add 20 to 30 percent headroom above the calculated number because bitrate spikes during the exact events you care about. Use RAID 6 on archive volumes, protect the OS drive too, format fresh video volumes with a 64 KB allocation unit, and turn off indexing and 8.3 creation. The commands are in the tuning article. Storage is the one area where buying more of the wrong thing makes the problem worse, not better.

3. Network congestion and streaming mismatches

The cameras record fine. The clients see degraded video, timeouts, and stutter that gets misdiagnosed as a camera or storage fault for weeks. It is the network, and usually it is three things.

NIC buffers left at factory defaults, too small for a server pulling continuous video, so the buffer fills and packets drop and the retransmissions pile on more load. Push receive and transmit buffers to the maximum the driver supports (4096 on most Intel NICs) on every adapter carrying camera or client traffic.

No traffic separation. Cameras, clients, management, and everything else sharing one flat segment with no QoS, so a backup job or a Windows update storm steps on live video. Separate the traffic and mark it. The VLAN segmentation reference covers the scheme.

And the quiet killer: Media Router redirect addresses left wrong. The default redirect points at localhost, which works only when the client is on the same box. After any topology change or server migration, the redirect addresses have to be set to addresses the cameras and clients can actually reach. Get them wrong and streams get sent into the void. Verify them after every network change.

4. Ignoring built-in health monitoring

Genetec ships the tools to tell you when something breaks. Most sites never operationalize them. The Health Monitor role is not deployed, System status is a screen nobody opens, health history goes unreviewed, and the one time a camera drops offline overnight, nobody finds out until the morning review, or until someone asks for footage that does not exist.

This is free visibility that organizations leave on the table. Deploy the Health Monitor role in any production environment. It is not in the critical path for recording or access control, so there is no good reason to skip it. Wire its alarms to a human or a ticketing queue, not a dashboard that lives behind three clicks. Review health history on a schedule. The value lands the first time an operator gets an alert at 2 a.m. instead of discovering a dead camera the next day. Role placement and the monitoring layer are covered in the architecture article.

5. Testing changes directly in production

There is no staging system, so every firmware push, config change, and version upgrade lands straight on the live environment, and the rollback plan is hope. This is how a routine camera firmware update takes down a recording role, or a Windows cumulative update breaks a Genetec service in the middle of a shift.

You do not always need a full duplicate environment, though on critical infrastructure you should have one. What you always need is a documented rollback for every change, a defined maintenance window, and a habit of testing cumulative updates somewhere other than production first. The Genetec Update Service can stage and schedule updates inside maintenance windows. Use it. Change discipline is not bureaucracy. It is the difference between a five-minute revert and a two-day incident.

Several of these sound familiar? A Genetec Health Check is a focused assessment that finds these issues across your environment and turns them into a prioritized remediation plan. Start a conversation.

6. Cameras left at factory defaults

The system was commissioned by pointing Genetec at cameras that nobody touched first. Default credentials still live on the devices, which is a hardening failure and an audit finding waiting to happen. Every camera runs H.264 when it could run H.265. Single stream, so the operator workstation decodes the full recording stream just to show a live tile. Continuous recording everywhere, including hallways that see nothing for twenty hours a day.

Treat the camera layer as configuration, not plug-and-play. Change default credentials before the device touches the production VLAN. Define standard camera profiles and apply them, rather than tuning one camera and cloning whatever happened to be on it. Move to H.265 where the cameras support it and the Archiver runs 5.9 or later with GPU-accelerated decode, which cuts storage and bandwidth 40 to 50 percent for equivalent quality. Use stream separation, a high-quality stream for recording and a low-quality stream for live monitoring, so workstations and links are not carrying full recording bitrate just to populate a video wall. Details are in the tuning article.

7. Weak security hardening

This is a physical security system sitting wide open on the network it is supposed to protect. Everyone is an administrator because RBAC was never set up. Communications are unencrypted. There is no Active Directory integration, so account management is manual and nobody offboards. Certificates are self-signed and expired, or never configured. No baseline was ever applied.

A camera estate is an enterprise application, and it gets hardened like one or it becomes the soft entry point. Build RBAC on least privilege so operators get operator rights and nobody runs day to day as a full admin. Follow the Genetec Security Center Hardening Guide rather than the install defaults. Integrate with Active Directory for authentication and lifecycle, which I walked through in deploying Active Directory for Genetec. Manage certificates like they matter, because the moment one expires you find out how much depended on it. For a reference baseline, Genetec's own StreamVault appliances ship hardened to CIS Level 2, which is a reasonable target even on hardware you built yourself. The Windows Hardening for Genetec course covers the workstation and server side.

8. Misdesigned federation and multi-site architecture

A multi-site organization picked the wrong model, and the cost of that decision compounds for years. Federation gets used where a distributed single system was the right answer, or a single system gets stretched across an unreliable WAN where federation belonged. Then cardholders do not sync between sites because Global Cardholder Synchronization was never configured, and operators manage the same person in three places.

Federation is not the same thing as one system with multiple Archivers. In a federated design each site is an independent system and the parent just surfaces their entities to central operators. The choice between distributed and federated comes down to whether sites need independent administration, whether the WAN can carry a unified system, and whether cardholder data has to be unified. If it does, that is Global Cardholder Synchronization, a separate feature you have to plan for. Getting this wrong at the architecture phase is expensive to unwind later, which is exactly why it belongs in a design review before anyone racks a server. The federation tradeoffs are in the architecture article.

9. Poor upgrade discipline

Two failure modes, opposite directions, same root cause. Either the system is frozen three versions back and accruing known issues that were fixed long ago, or it jumped onto a brand new .0 release the week it dropped and inherited every first-release bug.

Neither is discipline. Run a current, stable, patched version, and let new major releases prove themselves before they touch production. I am still telling clients to hold on 5.14.0.0 for exactly this reason, and I wrote up why in the 5.14 outlook and the 5.13.3 release review. Configure the Genetec Update Service to apply updates inside defined maintenance windows, test cumulative Windows updates before they hit Genetec servers, and check that the update combination you are about to apply is actually supported. Upgrade discipline is boring right up until the upgrade that takes the system down, and then it is the only thing anyone wants to talk about.

10. No single owner for end-to-end system health

This is the one that ties the other nine together. The security team owns the cameras. IT owns the network and the servers. The integrator owned the install and left after commissioning. Storage is someone else entirely. Nobody owns the whole stack, so when performance degrades, the default move is to point sideways, and the problem lives in the seams between teams where it never gets fixed.

Genetec health does not respect org charts. A streaming problem can be a NIC buffer, a QoS gap, a Media Router redirect, a saturated archive volume, or a throttled CPU, and those sit across four different teams. Somebody has to own the system end to end: network, server, storage, and the Genetec application as one thing. Assign an accountable owner. Write a RACI so it is clear who fixes what. If you do not have anyone internally who can see across all four layers, that is the gap an outside assessment fills, and it is the entire reason the Health Check exists.

Where to start

If more than a couple of these described your environment, you are not unusual. Most of the systems I walk into have five or six of them running at once, quietly, under a system that technically works. The fastest way to turn that into something actionable is a structured Genetec Health Check: a focused assessment across architecture, storage, network, monitoring, security, and lifecycle that ends in a prioritized remediation plan, not a list of complaints.

You can also work through the Genetec Health Check Checklist yourself first. It covers the same ground and prints cleanly if you want a leave-behind for the team. For an in-depth audit utility with severity weighting and PDF export, the Genetec Health Audit tool walks the same ten areas question by question.

Start a conversation →

Axis Camera Station Pro 6.14: AI, Analytics, and Search Have Genuinely Caught Up

hans@hans.study (Hans Study) — Mon, 25 May 2026 00:00:00 GMT

Image courtesy of Axis Communications. Used with attribution.

I have been quietly skeptical of Axis Camera Station for years. 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. The integration with the Axis ecosystem is genuinely best-in-class for Axis-heavy environments. 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.

The version landscape

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 quietly refined in every subsequent release. By 6.14, the search results are fast, the false-positive rate is reasonable, and the workflow is genuinely 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 unlock 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 deeper third-party integration ecosystem.

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.

Genetec Security Center 5.13.3.0: What's New, What Actually Matters, and What We're Still Waiting For

hans@hans.study (Hans Study) — Thu, 14 May 2026 00:00:00 GMT

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.

The version landscape

Security Center 5.13.3.0 is the current on-premises release. 5.13.2.0 (released 2025-07-10) is the last major step before 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.

Platform changes that actually matter

Time drift monitoring against the Directory

This is the kind of feature that sounds boring and is genuinely 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." The reality is that 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.

Genetec Security Center 5.14.0.0: What's Coming, What's Already Here, and Why I'm Still Telling Clients to Wait

hans@hans.study (Hans Study) — Wed, 13 May 2026 00:00:00 GMT

Image courtesy of Genetec. Used with attribution.

Security Center 5.14.0.0 hit Genetec techdocs on May 13, 2026. That is 12 days ago as I am writing this. The release is real, it is public, the techdocs are live, the installer is downloadable, and the marketing page is up. My phone has been ringing since the announcement, mostly from clients asking the same question: should we upgrade?

Short answer: not yet. Not because 5.14 looks bad. Because day-1 upgrades on a unified physical security platform that runs your video, your access control, and your alarms are a category of risk that does not pay off, ever. My upgrade clock on Genetec major versions starts at 30 to 60 days post-GA, minimum. Sometimes longer if the release notes hint at deep architectural change. This one does.

Here is what is in 5.14, what I am excited about, what I am watching for, and how it stacks against 5.13.3.0 (which is the baseline most production environments should still be on right now).

The "wait 30 to 60 days" rule, and why it exists

Genetec runs a continuous-delivery model. New minor versions ship roughly every 6 to 10 months. Bug fixes and cumulative updates ship more often. The first .0 release of any new minor version is, statistically, the version with the most undiscovered issues. Not because Genetec ships sloppy code. Because the matrix of real-world deployments (every combination of hardware, third-party integration, federated topology, and custom workflow) cannot possibly be reproduced in QA.

The first 4 to 8 weeks after GA is when the early adopters find the edges. The Known Issues page grows. The cumulative update (5.14.0.1, 5.14.0.2) arrives quietly. The patch revision (5.14.1.0) ships with the real "production-ready" version of the platform.

My thought: I tell every client the same thing. The integrator who tells you to upgrade to 5.14.0.0 in your next maintenance window is either eager for the line-item revenue or has not been burned by a .0 release yet. Either way, you would be the test subject.

The exceptions: critical security advisories that mandate a specific minimum version, a feature you genuinely cannot live without (rare), or a brand-new deployment where there is no production version to break. Otherwise, wait.

So with that framing, let us get into what 5.14 actually brings.

The big platform shifts

Web App replaces Web Client, exclusively

This is the headline. Starting in 5.14.0.0, the Genetec Web App is the only web-based client. Upgrading from any prior version automatically migrates Web Client to Web App.

Web Client has been deprecated in slow motion for two release cycles. 5.14 closes the door. Web App brings real feature parity with Security Desk for many monitoring workflows: maps, real-time access control event monitoring via Watch list, Mission Control incident handling, secure video sharing to Clearance, work request creation, fleet monitoring.

This matters because it is the first release where remote operators can genuinely do their job from a browser without dropping back to Security Desk for half the tasks. The Web App is also where Genetec is putting most of its forward-looking UX investment.

What to watch: the migration is automatic, but the change in user-facing UI is significant. Any operator runbook, training material, or SOP that references Web Client by name is now outdated. Budget time for documentation updates and operator retraining.

Custom privilege templates

This is the feature I have been asking for. Custom privilege templates let you define precise combinations of privileges, save them as reusable templates, and apply them to users or user groups without manually checking boxes one at a time.

If you read my piece on user granularity, you know I am a heavy advocate for fine-grained RBAC. The previous workflow for building out 10+ custom roles meant building each role by hand, then trying to remember the exact privilege set when you needed to clone it for a new partition. Custom templates make this maintainable at scale.

My thought: this is the kind of feature that quietly transforms how administrators manage their systems. It will not make a marketing slide jump off the page, but the admins who live in User Management will notice immediately.

Microsoft Entra OAuth for SMTP

Basic authentication is being phased out across Microsoft 365 SMTP. 5.14 brings native Entra OAuth support for email delivery, which means your Security Center email notifications can keep flowing through Microsoft 365 without falling back to less-secure auth methods or app passwords.

Small feature, big real-world impact for any environment standardised on Microsoft 365 for tenant email.

Media component now runs 64-bit

This is the architecture change I have been waiting on. The media component (which handles decoding, the Media Gateway, and Web App video processing) is now 64-bit. The direct effects:

Better decoding performance and lower latency.
Full compatibility with NVIDIA RTX 50X series GPUs (the current generation, which 32-bit had real trouble with).
Smoother Media Gateway operation, especially at scale.

The follow-on effect: this is one of the architectural pieces Genetec needed to address before the platform could move further toward modern hardware acceleration and cloud-edge workloads. It is not the only piece, but it is a necessary one.

Time drift alerts between Directory and failover/expansion servers

If you read my 5.13.3.0 review, you know time-drift visibility on the client was a welcome addition. 5.14 takes the next step: the Directory now actively detects and reports time drift greater than 10 seconds between itself and connected failover or expansion servers, raising health events and admin warnings when drift is detected.

This is the system-wide health view I was asking for in the 5.13.3 write-up. Genetec moved on it faster than I expected.

Retain audit trail when replacing a camera

When you use the Unit replacement tool, you can now preserve the original camera's activity and audit trail data and merge it with the new unit. This is a compliance-driven feature with real teeth: for any environment subject to evidentiary retention or audit requirements, the previous behaviour of losing the audit chain when swapping hardware was a gap that had to be papered over with manual records. 5.14 closes the gap natively.

Access control: the HID VertX/Edge end-of-life notice

This is the section every Synergis customer needs to read carefully.

Native HID VertX and Edge controller integration is officially marked end of life in the 5.14 release notes. HID itself reached EOL on these products back in 2023, which means no firmware fixes, no new features, no security patches from HID. Genetec is supporting them through the lifecycle of the 5.14 branch, but the techdocs include this language:

Since HID no longer provides fixes or develops new features for these controllers, we strongly recommend planning for a hardware replacement before upgrading to Security Center 5.15.

In plain English: you have one Security Center major version of runway. After that, your VertX or Edge controllers will not be supported. If you are on Synergis with HID hardware that hits this category, your hardware refresh planning starts now. Mercury MP1502 and MR52 panels remain the standard upgrade path, with Axis A1610 and A1810 picking up share on the newer deployments.

Other access control items worth noting:

PIN credentials now require dual-entry on creation and modification, which catches typos that previously locked cardholders out until manual reset.
A new View PINs privilege separates PIN visibility from credential code visibility, which is a quiet but meaningful data-protection improvement.
Cardholder, Visitor, and Credential management tasks now require both the task privilege and the corresponding View properties privilege. This is going to surface on upgrade as users who previously had implicit read access suddenly get permission errors. Plan for it.

Video enhancements worth flagging

Granular firmware upgrade privileges

The previous "Upgrade video units" privilege has been split into two:

Upgrade video units using the Genetec Update Service (GUS), which restricts upgrades to Genetec-certified firmware.
Upgrade video units using user-provided hardware (the new name for the old broad privilege), which allows uploading firmware files from the manufacturer directly.

Default templates include only the GUS privilege; user-provided uploads have to be explicitly granted. This is the right default. Existing users with the old privilege get both new ones automatically, but for new deployments and new roles, you are now opting into raw-firmware-upload capability rather than getting it implicitly.

My thought: I have been at sites where a junior tech downloaded the wrong firmware from a sketchy mirror and bricked 6 cameras in an afternoon. This privilege split would have prevented that. Welcome change.

Visual tracking overlays

When configuring visual tracking, you can now add polygons, images, and text objects to help operators understand the camera layout. Useful for complex sites where the spatial relationship between cameras is not obvious from a tile view.

Watermarking enhancements

Watermarks can now be applied to live, playback, and exported video individually or in any combination, with custom text up to 100 characters, configurable colour and outline, and an auto-scale option to keep the watermark visible within the frame.

For evidentiary workflows where chain of custody matters, this is overdue.

Federated stream statistics via PowerShell

A new ShowFederatedStreams debug command accessible through Server Admin or the Genetec PowerShell module gives operators a way to monitor active federated streams, bit rates, and playback sessions without bouncing between interfaces. Useful for federated environments where stream-level visibility was previously buried.

Automation: the next step beyond delays

5.13.3.0 introduced delays between automation response actions. 5.14 adds the next obvious step: a Wait for event action that pauses execution until a specific event occurs (or skips remaining actions if it does not happen within a defined timeout).

Combined with time-zone-aware scheduling (also new in 5.14) and the new Automation Manager health events for overload conditions, the automation engine is starting to look like a real workflow tool rather than the basic event-action pair it used to be.

What is still missing

Same wishlist as my 5.13.3.0 review. None of these landed in 5.14:

Native, structured log streaming to SIEM. Still SDK or third-party connector territory.
Native MFA for local accounts. Still relies on AD or external IdP for second factor.
True hybrid parity between SaaS and on-prem feature sets. The gap is, if anything, wider with this release.

The custom privilege templates feature partially addresses the "finer RBAC" item from my last wishlist. The 64-bit media component is the kind of architectural change that opens doors for future capability without being the door itself. The HID EOL is a forcing function on hardware refresh planning for a chunk of the installed base.

My thought: Genetec's pace is steady, and the changes are mostly the right ones. The frustrations are mostly the things that have not moved.

How 5.14 compares to 5.13.3.0

If you read my 5.13.3.0 review, the comparison is roughly:

5.13.3.0 was a polish release. Batch firmware updates, AV1 codec support, copy-configuration privilege split, time-drift visibility on the client. Useful, low-risk, broadly applicable.
5.14.0.0 is a platform release. Web Client retirement, 64-bit media component, custom privilege templates, automation maturation, HID EOL notice. Bigger surface area, more upgrade considerations, more reason to wait.

If you are on 5.13.2.0, your immediate path forward is still 5.13.3.0, not 5.14.0.0. That is the safer step in any case, and the patch revisions on 5.13.3.x will continue for the foreseeable future.

The upgrade timeline I am telling clients

Now through end of June 2026: stay on 5.13.3.0 (or 5.13.2.0 if you have not moved yet). Read the 5.14 release notes. Identify what affects your environment.
July 2026: watch for the first cumulative update (probably 5.14.0.1 or 5.14.0.2). Read the Known Issues page. Note which issues are resolved and which are deferred.
August through September 2026: if 5.14.1.0 or later has shipped and the Known Issues list looks clean for your deployment profile, plan your upgrade. Test on a non-production system first. Verify your federated systems, your SDK integrations, your custom workflows, and your operator training materials.
Q4 2026: roll the upgrade in your normal maintenance windows, deployment by deployment, not all sites at once.
Through 2027: plan your HID VertX/Edge hardware refresh before 5.15 forces the issue.

This is not a Genetec-specific timeline. It is the same approach for any major platform upgrade on a system that touches life-safety, evidence, and critical operations. Move deliberately. Verify at each step. Do not be the test subject.

My take

5.14 is a real platform release, not a polish release. Architectural changes (64-bit media component, Web App exclusivity, custom privilege templates) outweigh feature additions.
Web Client is gone. The Web App migration is automatic, but your operator training materials and runbooks are not going to update themselves.
Custom privilege templates finally let you build the 10-role hierarchy properly without rebuilding it by hand for every partition. Quiet win, big admin impact.
HID VertX and Edge: the clock is now visible on the wall. One major version of runway. Plan the controller refresh before 5.15 forces it.
64-bit media component opens the door to RTX 50X series GPUs and architectural moves Genetec could not make on the 32-bit stack. Watch this space.
It is a fresh .0 release on a unified security platform. Wait 30 to 60 days. Read the Known Issues page. Watch for 5.14.0.1 and 5.14.1.0. Then plan the upgrade in a real maintenance window.
The integrator pushing you to upgrade in your next maintenance window is either eager for the line-item revenue or has not been burned by a .0 release yet.

CMMC vs CPCSC: The Practitioner's Comparison

hans@hans.study (Hans Study) — Mon, 11 May 2026 00:00:00 GMT

If you supply Canada's Department of National Defence and you also sell into the U.S. defence market, you are about to run two compliance programs that look like twins and behave like cousins. CPCSC on the Canadian side, CMMC on the American one. Same NIST parent standard, same goal of keeping sensitive unclassified information inside the supply chain, different revisions, data categories, and assessors. Suppliers caught on both sides keep asking whether they do the work once or twice. The honest answer is once and a half, and here is the practitioner's read on where the seams are.

Both programs at a glance

If you only have two minutes, this table covers the structural shape. The rest of the article fills in the consequences.

Attribute	CMMC 2.0 U.S.	CPCSC CAN
Owner	U.S. Department of Defense	Public Services and Procurement Canada, with National Defence
Underlying standard	NIST SP 800-171 Rev 2	ITSP.10.171 (adapted from NIST SP 800-171 Rev 3)
Information protected	FCI, CUI	Federal Contract Info, Specified Information (SI)
Levels	3 (Foundational, Advanced, Expert)	3 (Level 1, Level 2, Level 3)
Level 1 controls	17 practices	13 controls
Level 2 controls	110	~97
Level 3 controls	110 + 24 enhanced	~200 (incl. DND additions)
L1 assessment	Annual self-assessment	Annual self-assessment
L2 assessment	Third-party (C3PAO), every 3 years	Third-party (SCC-accredited CB), every 3 years
L3 assessment	DIBCAC (government), every 3 years	National Defence (government), every 3 years
Accreditation body	Cyber AB	Standards Council of Canada
Effective in contracts	Phase 1 began Nov 10, 2025	Level 1 began April 1, 2026
Annual affirmation	Required by senior official	Required (Levels 2 and 3)
POA&M tolerance	L2 allows limited POA&M, 180-day close	To be finalized for L2 with rollout

One family tree, two branches

Both programs trace back to a single document: NIST Special Publication 800-171, "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations." It is the technical baseline for protecting sensitive but unclassified federal data outside government systems.

The U.S. and Canada have integrated defence supply chains. When the Canadian government built CPCSC, deliberate alignment with NIST 800-171 was the point. That alignment is explicit policy, not a coincidence.

// Standards lineage

The branch point matters more than the shared root. CMMC anchors to NIST 800-171 Revision 2. CPCSC's underlying standard, ITSP.10.171, anchors to Revision 3. Same family, different generation. We will come back to this.

CMMC 2.0

The Cybersecurity Maturity Model Certification is the U.S. Department of Defense's mechanism for verifying that contractors and subcontractors actually implement the cybersecurity practices they have been contractually obligated to implement since 2017 under DFARS clause 252.204-7012.

The earlier model relied on self-attestation. Adversaries exploited the gap between what contractors said and what they did. CMMC closes that gap with third-party verification at most levels.

The three levels

Level	Controls	Standard	Assessment	Cadence
Level 1 (Foundational) FCI only	17	FAR 52.204-21 basic safeguarding	Self-assessment	Annual
Level 2 (Advanced) CUI	110	NIST 800-171 Rev 2	C3PAO third-party (some self for non-critical CUI)	Every 3 years, annual affirmation
Level 3 (Expert) Critical CUI / HVA	110 + 24	NIST 800-171 Rev 2 + selected NIST 800-172	DIBCAC (government-led)	Every 3 years, annual affirmation

The phased rollout

The 48 CFR final rule took effect on November 10, 2025. From that date, CMMC requirements began appearing in select DoD contracts. The rollout runs in four phases over three years.

// CMMC 2.0 phased rollout

Most contractors handling CUI need Level 2. DoD estimates 93 percent of CUI-handling organizations fall into Level 2 with C3PAO certification, roughly 5 percent qualify for Level 2 with self-assessment, and 2 percent face Level 3 with DIBCAC.

What CMMC requires beyond NIST 800-171

NIST 800-171 is a security requirements catalog. CMMC is a certification program. The catalog and the program are not the same thing. CMMC adds the verification layer, plus a few mechanics the catalog does not specify:

Third-party assessment by C3PAOs accredited through Cyber AB at Level 2
Government-led assessment by DIBCAC at Level 3
Annual senior leadership attestation of continued compliance
Mandatory flow-down to subcontractors who process, store, or transmit covered data
Submission of assessment results in the Supplier Performance Risk System (SPRS)
Limited POA&M tolerance at Level 2 with a 180-day close window

CPCSC

The Canadian Program for Cyber Security Certification is the Canadian equivalent, jointly run by Public Services and Procurement Canada and National Defence. It exists because Canada's defence supply chain faces the same attack surface as the U.S. supply chain, often with the same adversaries targeting the same primes from a different border.

Budget 2023 allocated $25 million over three years to stand the program up. The Canadian Centre for Cyber Security publishes the underlying standard, ITSP.10.171, titled "Protecting Specified Information in Non-Government of Canada Systems and Organizations." Note the terminology shift. Canada calls it "Specified Information" (SI). The U.S. calls it CUI. The categories are similar in spirit but not identical in scope.

The three levels

Level	Controls	Assessment	Cadence
Level 1 Baseline cyber hygiene	13	Annual self-assessment, filed in CanadaBuys at contract award	Annual
Level 2 Controlled defence info	~97	SCC-accredited third-party certification body	Every 3 years, annual affirmation
Level 3 High-risk / weapons / 5-Eyes	~200	National Defence (Government of Canada)	Every 3 years, annual affirmation

The phased rollout

Level 1 went live April 1, 2026, and becomes a contract-award condition in select defence procurements beginning Summer 2026. Level 2 enters select contracts in Spring 2027. Level 3 follows after the additional Level 3 controls are formally published.

// CPCSC rollout

The cascade effect

Around 600 prime contractors are registered with the Department of National Defence. They are the first to feel the requirement, but the obligation flows down. Primes have to verify their supply chain. That means thousands of tier-2 and tier-3 suppliers who never directly held a DND contract will be asked to prove CPCSC posture, or be replaced.

The families, side by side

The control family structures differ because the two programs pin to different revisions. CMMC's Rev 2 baseline has 14 families. ITSP.10.171's Rev 3 baseline has 17 families. The new families in Rev 3 are Planning, System and Services Acquisition, and Supply Chain Risk Management. These existed informally in Rev 2 as "non-federal organization" expectations. Rev 3 makes them explicit and assessable.

Family	CMMC L2 (Rev 2)	CPCSC L2 (Rev 3 / ITSP.10.171)
Access Control (AC)	22	~17
Awareness and Training (AT)	3	~3
Audit and Accountability (AU)	9	~9
Configuration Management (CM)	9	~8
Identification and Authentication (IA)	11	~9
Incident Response (IR)	3	~6
Maintenance (MA)	6	~6
Media Protection (MP)	9	~7
Personnel Security (PS)	2	~2
Physical Protection (PE)	6	~5
Risk Assessment (RA)	3	~7
Security Assessment (CA)	4	~3
System and Communications Protection (SC)	16	~10
System and Information Integrity (SI)	7	~7
Planning (PL) Rev 3 new	n/a	~2
System and Services Acquisition (SA) Rev 3 new	n/a	~2
Supply Chain Risk Management (SR) Rev 3 new	n/a	~2
Total	110	~97

Family-level counts for ITSP.10.171 are approximate because Rev 3 consolidated and reworded several Rev 2 requirements. The structural delta is what matters. CPCSC L2 explicitly assesses Planning, System and Services Acquisition, and Supply Chain Risk Management. CMMC L2 assesses outcomes that touch those areas without making them their own families.

The Level 1 subset

CPCSC Level 1 picks 13 specific controls from 6 families of ITSP.10.171. These are the foundational hygiene items every organization handling defence information should already have done.

CPCSC L1 Family	Controls	Focus
Access Control (AC)	4	Account management, least privilege, external system limits
Identification and Authentication (IA)	3	User identification, authenticator strength, password reuse
Media Protection (MP)	1	Sanitization of media before disposal or reuse
Physical Protection (PE)	2	Limit physical access, escort visitors, log entry
System and Communications Protection (SC)	1	Boundary protection between trusted and untrusted networks
System and Information Integrity (SI)	2	Flaw remediation, malicious code protection
Total	13	6 families, ~71 assessment objectives

CMMC Level 1 picks 17 practices that map to the 15 basic safeguarding requirements in FAR 52.204-21. The overlap is heavy. If you can meet CMMC L1, you can meet CPCSC L1 with minor tuning, and the reverse holds.

Rev 2 vs Rev 3, and why it matters

This is the single most important detail in the comparison, and the one most organizations get wrong.

CMMC (U.S.)

Locked to Rev 2

The CMMC final rule explicitly states that NIST SP 800-171 Revision 3 is not currently applicable. DoD issued a class deviation requiring contractors to continue using Rev 2 for DFARS 252.204-7012 compliance.

C3PAO assessors are not authorized to evaluate organizations against Rev 3. SPRS scoring runs on Rev 2. Building documentation against Rev 3 risks gaps relative to what assessors actually use.

CPCSC (Canada)

Built on Rev 3

ITSP.10.171 is the Canadian Centre for Cyber Security's adaptation of NIST SP 800-171 Revision 3. It uses Rev 3's structural changes: 17 families, 97 controls, and Organization-Defined Parameters.

That means assessors evaluating CPCSC Level 2 will look for Rev 3 conventions, including ODPs that specify exact values for tunable controls. Rev 2 documentation will not map cleanly.

What changed in Rev 3

Control count dropped from 110 to 97. Some Rev 2 requirements were merged. Others were reworded. None of the underlying security intent was removed.
Three new families were added. Planning (PL), System and Services Acquisition (SA), and Supply Chain Risk Management (SR). These existed informally in Rev 2 as "non-federal organization" expectations. Rev 3 made them explicit.
Organization-Defined Parameters were introduced. ODPs specify exact values for tunable controls, like minimum password length, account lockout thresholds, or audit log retention. DoD has published its own ODP values. Canada will publish its own. They may not match.
NFO controls were removed. Anything required is now stated in the controls. If it is not in the controls, it is not required. This makes the standard cleaner and easier to scope.
Control identifiers changed. Rev 2 used "3.1.1" style identifiers. Rev 3 uses "03.01.01" with two-digit numbers. Mapping work is required.

Where they diverge

The differences are not just paperwork. Each one has operational consequences.

Dimension	CMMC 2.0	CPCSC
Underlying standard	NIST SP 800-171 Rev 2 (110 controls)	ITSP.10.171 / NIST SP 800-171 Rev 3 lineage (97 controls)
Data category	Federal Contract Information, Controlled Unclassified Information	Federal Contract Information, Specified Information
Regulatory authority	DFARS, 32 CFR Part 170, 48 CFR Parts 204/212/217/272	PSPC procurement policy, Treasury Board frameworks
Accreditation body	Cyber AB	Standards Council of Canada
L2 assessor	C3PAO (third-party, Cyber AB accredited)	Accredited certification body (SCC accredited)
L3 assessor	DIBCAC (Defense Industrial Base Cybersecurity Assessment Center)	Department of National Defence
Submission system	SPRS (Supplier Performance Risk System)	CanadaBuys supplier profile
Privacy framework	U.S. privacy regs, no overarching federal statute	PIPEDA, provincial privacy law, Treasury Board policy
Cryptography validation	FIPS 140-2 / 140-3 (NIST CMVP)	FIPS-validated, with CCCS-approved cryptographic algorithms
Data residency	FedRAMP for cloud handling CUI	Canadian deployment options often preferred; sovereignty pressure on SI
Reciprocity	None with CPCSC. Certificates are not interchangeable.	None with CMMC. Certificates are not interchangeable.
Affirmation	Annual senior leadership attestation, False Claims Act exposure	Annual affirmation for Levels 2 and 3
POA&M	Limited at L2, 180-day close, SPRS score ≥80%	To be finalized for L2 rollout

Where they intersect

The overlap is large enough that a serious organization can build one cybersecurity program and harvest two certificates from it. The work is not doubled. It is roughly 1.3x to 1.4x what a single program would cost, assuming the underlying SSP is structured for both lenses.

// Control overlap (schematic)

Practical overlap

Underlying control intent. Access control, audit logging, identification, incident response, media protection, and configuration management have nearly identical objectives in both frameworks.
Three-tier model. Self-assessment at the base, third-party at the middle, government-led at the top. The pattern is the same.
Phased rollout. Both governments learned from the earlier CMMC 1.0 stumble and built phased enforcement curves that give suppliers time to adapt.
Flow-down obligations. Primes must verify supply chain compliance in both programs.
Annual leadership affirmation. Both require a senior official to attest to continued compliance, with legal exposure for false statements.
Cryptographic baselines. Both reference FIPS-validated cryptographic modules. Different validation programs, but the underlying intent matches.
POA&M concept. Both programs accept that small gaps can be closed under a structured remediation plan rather than blocking certification entirely. Tolerances differ.

How to implement both

The goal is one cybersecurity program, two compliance lenses. Do not run two parallel programs. That doubles cost without doubling value. The work below assumes an organization that needs Level 2 in both jurisdictions, which is the most common cross-border scenario.

// Dual compliance implementation flow

Phase 1: Scope

Inventory what you actually handle. FCI, CUI, and SI live in different places. Mark the systems that touch covered data. Mark the systems that do not. The assessment boundary is everything that touches, plus the security infrastructure that protects it. Out-of-scope systems stay out of scope only if you can prove the data does not flow into them.

Map data flows. Where does CUI enter your environment? Where does SI enter your environment? Where does it leave? The flow diagrams become evidence. They also become the foundation for the next phase.

Phase 2: Gap analysis

Run two gap assessments in parallel. One against NIST SP 800-171 Rev 2 with DoD's ODP values. One against ITSP.10.171 (Rev 3) with CCCS-published parameters when they are released. Build a single gap register with columns for both. Most gaps will be identical. A few will not.

The new Rev 3 families that have no Rev 2 equivalent are where most organizations have the biggest gaps. Planning, System and Services Acquisition, and Supply Chain Risk Management require formal documentation that most contractors do not yet have.

Phase 3: SSP and policy

Build the System Security Plan to Rev 2 as the primary structure, because that is what your C3PAO will assess against. Maintain a Rev 3 overlay as an addendum that maps each Rev 2 control to its Rev 3 equivalent and notes any new Rev 3 requirements.

Policy documents should be modular. One identification and authentication policy covers both lenses. The differences are usually in ODP values, not in the underlying control. Document the ODP values you have chosen and why. When CMMC eventually transitions to Rev 3, your work converts cleanly.

Phase 4: Control implementation

Implement to the superset. If Rev 2 requires X and Rev 3 requires X plus Y, you implement X plus Y. You will not be penalized for exceeding Rev 2 on a CMMC assessment as long as you can also demonstrate the Rev 2 requirement. Evidence everything. Screenshots, configuration exports, log samples, signed policies, training rosters, ticket records.

Common implementations that satisfy both programs cleanly:

Identity. Entra ID or Active Directory with conditional access, MFA on all privileged accounts, joiner-mover-leaver workflows, quarterly access reviews.
Endpoint. EDR with active detection, full-disk encryption, USB control, automated patching with measurable SLA.
Network. Segmented architecture with documented trust zones. Egress filtering. Logging to SIEM. No flat networks.
Cloud. FedRAMP Moderate or High for CUI workloads. Canadian-residency options for SI when sovereignty matters.
Logging. Centralized SIEM with retention long enough to satisfy both DoD's Rev 3 ODP for audit log retention and CCCS guidance. Default to the longer of the two.
Incident response. Documented plan, tested annually, with separate reporting paths for U.S. DC3 and Canadian CCCS depending on incident scope.
Supply chain. Vendor assessment program with documented risk tiering. This is where Rev 3's SR family lives.

Phase 5: Assess and certify

The two assessments will happen separately. A C3PAO cannot certify CPCSC, and an SCC-accredited certification body cannot certify CMMC. Plan for two assessment events, two reports, two attestations. The evidence packages are mostly the same. The framing is different.

Submit results to the right systems. CMMC scores go to SPRS. CPCSC self-assessment results go to CanadaBuys. Track expiry dates in your compliance calendar. Annual affirmations are not optional.

The combined calendar

Both rollouts overlap through 2028. If you bid into both markets, your compliance calendar looks like this.

// Combined CMMC + CPCSC calendar

CMMC L2 deadline

Nov 10

2026 // C3PAO required

CPCSC L1 in contracts

Summer

2026 // At contract award

CPCSC L2 in contracts

Spring

2027 // Third-party assess

Average prep time

6 to 12

Months to assessment-ready

Questions that come up

Does a CMMC Level 2 certificate satisfy CPCSC Level 2?

No. There is no reciprocity between the programs. They are administered by different governments, accredited by different bodies, and assessed by different organizations. The underlying technical work overlaps significantly, but the certificates are not interchangeable. Plan for two assessments if you bid in both markets.

If CPCSC uses Rev 3 and CMMC uses Rev 2, should I build to Rev 3 to be forward-looking?

Build to Rev 2 as your primary documentation if you have a near-term C3PAO assessment. Layer Rev 3 mappings on top as an overlay. C3PAO assessors are not authorized to evaluate against Rev 3, and building only to Rev 3 risks creating gaps in what assessors actually look for. When CMMC eventually transitions to Rev 3, the overlay becomes your primary documentation.

I am a Canadian sub-contractor to a Canadian prime. Do I need CPCSC?

If you handle Specified Information on behalf of the prime, then yes. The prime cannot maintain compliance if their suppliers cannot. Expect a CPCSC posture question to appear in supplier onboarding, RFPs, and master service agreements over the next 18 months. The cascade is faster than most suppliers expect.

What is the difference between CUI and Specified Information?

Both refer to sensitive, unclassified government information that requires protection in non-government systems. The categories are similar in intent but not identical in scope or governing policy. CUI is defined in 32 CFR 2002.4(h) under U.S. law. Specified Information is defined in CPCSC and underpinned by Treasury Board policy. The information that one government classifies as Specified might or might not match what the other classifies as CUI.

Can a single cloud platform support both certifications?

In principle, yes. The cloud platform needs FIPS-validated cryptography, FedRAMP authorization for CUI workloads, and Canadian-residency options when SI sovereignty matters. The platform supports the work. The certifications still happen at the organization level, against the organization's policies, procedures, and operational practices, not against the cloud platform itself.

What happens if I fail a C3PAO or SCC-accredited assessment?

At Level 2 in both programs, limited POA&M tolerance allows certain gaps to be closed within a defined window. CMMC's window is 180 days. CPCSC's is being finalized. Outside that tolerance, failure means you do not get the certificate, which means you do not get the contract. There is no shortcut. Remediate, re-engage the assessor, and try again.

Does my ISO 27001 certification count for either program?

No. Neither CMMC nor CPCSC accepts ISO 27001 as a substitute. The control sets overlap meaningfully, and an ISO 27001 program is a strong starting point. The certificate itself does not transfer.

Is the cost difference between CMMC and CPCSC significant?

Assessment costs are roughly comparable. Implementation costs depend on starting maturity. An organization that starts with mature NIST 800-171 controls will spend roughly 1.3x to 1.4x the cost of a single certification to achieve both, primarily in documentation, ODP reconciliation, and the second assessment event. An organization starting from zero will spend more, but the same SSP and evidence package serves both lenses.

What is the single biggest mistake organizations make?

Treating compliance as a documentation exercise rather than an operational discipline. Assessors at both programs are not checking if you wrote a policy. They are checking if the policy is implemented, evidenced, and operational. A well-written SSP with no operational evidence behind it fails. A modestly written SSP backed by daily evidence of practice passes.

The practitioner's read

CMMC and CPCSC are not the same program. They share parentage, structure, and intent, but they are administered by different governments under different authorities with different assessors using different revisions of the same source standard. Treating them as interchangeable creates assessment risk. Treating them as completely separate doubles the cost.

The right read is this. They are two compliance lenses on one cybersecurity program. Build the program properly, anchor your documentation correctly for each lens, and the certificates fall out of the work. The organizations that struggle are the ones treating compliance as paperwork rather than as evidence of an operating practice. The organizations that succeed are the ones that already do the security work and now have to prove it in two languages.

If you are in the Canadian defence supply chain and you sell into the U.S. defence supply chain, the next 18 months will sort the suppliers who built early from the suppliers who waited. Build early.

Related guidance

Defence and CMMC consulting, the service page covering CMMC and CPCSC readiness, SSP development, and assessor preparation engagements.
Hardening Windows Server: Getting Started, the baseline that maps into the Rev 2 and Rev 3 control sets these programs assess against.
Hardening Windows Server: Group Policy Baseline, GPO-driven STIG/CIS settings that satisfy the configuration management family.
Hardening Windows Server: Audit Logging, the auditpol and Windows Event Forwarding setup that satisfies the audit and accountability family.
Security controls for CCTV and access control networks, the parallel controls reference for physical security networks.
Workstation Hardening Config Generator, the tool that produces a SHA-256 fingerprinted PowerShell script aligned to DISA STIG, CIS Benchmark L1, NSA/CISA, and CCCS guidance.

Genetec Security Center: Server Configuration and Performance Tuning

hans@hans.study (Hans Study) — Tue, 04 Nov 2025 00:00:00 GMT

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 (EN.500-BPEN-V5.13.2, updated February 2025) combined with findings from real system assessments. Run the latest stable version of Security Center and keep it patched, 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): [VideoArchive_Drive]:\[GenetecArchivePath] # 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.

Deploying Active Directory for Genetec Security Center Environments

hans@hans.study (Hans Study) — Tue, 30 Sep 2025 00:00:00 GMT

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: Architecture, Roles, and Workstation Best Practices

hans@hans.study (Hans Study) — Tue, 26 Aug 2025 00:00:00 GMT

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.