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.