Hans Study

[Article] What a Drone Adds to a Perimeter Security Assessment

hans@hans.study (Hans Study) — Tue, 29 Sep 2026 00:00:00 GMT

Most perimeter assessments are conducted at eye level by someone walking the fence with a clipboard, which means most perimeter assessments share a blind spot: everything the site looks like from above eye level. Camera fields of view are guessed from the ground. Mast-top mounting hardware hasn't been inspected since the lift left on install day. The fence line gets sampled where it's walkable and assumed where it isn't. I fly a drone on assessments as a certified RPAS pilot, and the aerial pass has become the part of the survey that changes findings rather than confirming them. ## What the flight actually produces The flight produces specific evidence, not a pretty site photo: - **True sightline verification.** An orthographic pass at camera height along the perimeter shows what each camera can see, including the dead zones created by that shipping container someone parked in year two. Comparing this against the coverage map in the O&M manual is reliably humbling. - **Mounting and cable condition at height.** Corroded banding on a pole mount, a drip loop that's become a water feed, conduit pulled away from a mast, a junction box missing its cover: all invisible from the ground, all photographed in ten minutes without a lift rental. - **Fence-line continuity in sequence.** A low pass along the full perimeter produces a continuous, timestamped record. Wash-outs under the fabric, vegetation defeating the clear zone, sagging fabric between posts, and the informal path worn to the exact spot where the fence is climbable all show up without anyone bushwhacking the back 40. - **Lighting and approach documentation.** Dusk flights map real illumination against the photometric plan, and approach routes an intruder would actually use read differently from 60 metres up than they do from the guard shack. - **As-built truth for the drawing set.** Roof-mounted equipment, antenna farms, and pathway routing get documented as they are, which matters when the drawings are three revisions behind the building. ## The part people skip: flying it legally An RPAS survey of an industrial or critical infrastructure site isn't a hobby flight. In Canada that means Part IX of the Canadian Aviation Regulations: registration for anything over 250 grams, a pilot certificate, and an advanced operations certificate plus air traffic control authorization before flying in controlled airspace, which covers a good share of the industrial sites worth assessing because they sit near an aerodrome. Client property doesn't exempt you from any of it, and a security consultant generating regulatory violations while auditing someone's risk posture is a story that writes its own ending. Build the flight into the assessment scope like any other task: airspace check, site notification, weather window, flight log retained with the deliverable. The photos go into the report with coordinates and timestamps, which is also what makes them defensible when a finding gets disputed. ## Where this fits in an assessment The aerial pass covers the axis the walk-down can't reach, and it doesn't replace the ground work. Ninety minutes of flying on a mid-size site typically produces three or four findings that would otherwise have needed a lift rental or plain luck. On one survey the aerial pass settled in an afternoon a camera-coverage dispute that had run for months on the ground, because a photograph from the camera's actual mounting height ends arguments that diagrams start. If your assessor isn't looking at your site from above, part of your site isn't being assessed. Perimeter and CCTV assessments, with the aerial pass in scope, are described under [independent review](/independent-review/).

[Article] The Flat Network Problem: Level 1 From Inside a 30-Person Shop

hans@hans.study (Hans Study) — Thu, 24 Sep 2026 00:00:00 GMT

The compliance guidance for programs like CPCSC assumes an IT department it never names. Somebody who knows what a VLAN is, a server room with a door, a patch cadence. The Canadian defence supply chain doesn't look like that below tier 1. It looks like a 30-person machine shop where the CAD workstations, the CNC controllers, the front-office PCs, the shop-floor wifi, and the owner's laptop all share one flat network behind the same class of router you'd buy for a house. I've done security readiness work inside exactly these environments, small manufacturers preparing for ISO 27001 and NIST-based customer requirements, and the gap between the framework's assumptions and the shop floor's reality is where these projects live or die. ## What "flat" actually costs you On a flat network, the attestation questions collapse into each other. Asked where specified information lives, the true answer is everywhere: the drawing package sits on the CAD station, which shares a broadcast domain with a CNC controller running an embedded OS the vendor stopped patching years ago, which sits next to the wifi the shop floor uses for personal phones. Every control you'd attest to, access restriction, boundary protection, monitoring, has to be true for the whole network, because the whole network is one zone. That's what makes flat networks expensive for compliance. Not that they're indefensible, but that the defensible boundary is enormous. ## The move that changes everything One intervention does most of the work: put the machines that touch sensitive data in their own segment. In practice, for a shop this size, that's a small business-grade firewall and a managed switch, two or three VLANs, and a few deliberate rules. CAD and engineering in one zone. CNC and production equipment in another, because those controllers can't be patched and shouldn't see the internet at all. Everything else, office, wifi, the label printer, in a third. Suddenly the attestation boundary shrinks from "the entire company" to "the engineering VLAN," and every downstream question gets easier. Access control means the six people in that zone, not all 30. Monitoring means one firewall's logs. The unpatched CNC controller stops being a compliance contradiction and becomes an isolated cell with a documented reason for existing. The hardware for this lands in the low four figures. The design and the discipline are the actual product. ## What I tell owners Don't start with a document set. A binder of policies describing a network that doesn't exist is the most common readiness failure I've seen, and assessment regimes are getting better at catching it. Start with the segmentation, spend two or three focused days getting MFA onto the accounts that matter and the drawings out of personal email, and then write policies that describe what you actually built. The paperwork goes fast when it's telling the truth. A shop that does this is ready for more than a Level 1 attestation. The customer questionnaire, the insurance renewal, the bank's security addendum, and the ISO conversation all get easier, because underneath the branding they're all asking about the same flat network. This is the readiness work I do with small manufacturers: segmentation design first, then paperwork that describes reality. If that's the project on your desk, the [CPCSC Level 1 readiness page](/cpcsc/level-1/) is a reasonable place to start, and [the segmentation guidance](/standards-guidance/) in the knowledge base covers the VLAN design in detail. Free book: the scoping method above is chapter 6 of [The Study Guide to CPCSC Readiness](/cpcsc_book/), free to read online or as a PDF.

[Article] Flow-Down Is Coming: What Your Prime Will Ask Before They Can Bid

hans@hans.study (Hans Study) — Mon, 21 Sep 2026 00:00:00 GMT

The letter arrives from your customer, not from Ottawa. That's the part of certification programs that catches lower-tier suppliers off guard: the government never contacts you. Your prime does, because their contract makes them responsible for the cyber posture of everyone underneath them, and they discharge that responsibility by pushing requirements down the chain with a questionnaire and a deadline. Canada hasn't fully built this machinery yet. The allies we align with have, and their model tells you what's coming. ## How the allies run it The UK Ministry of Defence attaches a cyber risk profile to each contract through DEFCON 658, and prime contractors must run a risk assessment on every subcontract they place, cascading the process down through tier 2 and tier 3 until the risk profile drops low enough to stop. The US runs the equivalent through DFARS clauses and CMMC: clause 252.204-7012 requires the contractor to include the clause, without alteration, in every subcontract that involves covered defence information, and CMMC makes the subcontractor's certification a condition of the award. Two different mechanisms, one identical outcome: the prime becomes the enforcement arm, and a subcontractor's cyber posture becomes a bid-eligibility question decided in someone else's procurement office. CPCSC is built to interoperate with these programs. Expecting Canadian defence primes to behave differently than their UK and US counterparts is a bet against every incentive in the system, because a prime whose sub can't attest is a prime who can't close their own compliance obligations. ## What the questionnaire will ask Having sat on the receiving end of supplier assurance questionnaires in other frameworks, the content is predictable: - Whether you hold a current CPCSC attestation or certification, and at what level - What specified information you'd receive under the subcontract, and where it would live - Your sub-subcontractors, because the cascade doesn't stop at you - Incident reporting commitments, usually with timelines tighter than your current IR plan contemplates - Evidence of specific controls when the risk profile is high enough, MFA and encryption at rest being the perennial first two The suppliers who answer in a week win work from the suppliers who answer in a quarter. That's the entire competitive dynamic, and it's brutally simple. ## Getting ahead of the letter If you're a tier 2 or 3 supplier with defence-adjacent revenue, complete your Level 1 self-assessment now, before anyone asks. Not because the contract requires it yet, but because "yes, attested, here's the date" is a one-line answer to the hardest question on the form. Build a one-page data-handling summary you can hand any prime: what you receive, where it's stored, who touches it. Then ask your own subcontractors the questions before your prime asks whether you did. The flow-down letter is coming either way. The only variable is whether it finds you ready. Readiness engagements for suppliers at any tier are described on the [CPCSC readiness page](/cpcsc/). Free book: [The Study Guide to CPCSC Readiness](/cpcsc_book/) covers flow-down, scoping, and all 98 ITSP.10.171 requirements. Read it in the browser or download the PDF.

[Article] The CCSRA: How DND Will Decide Which Level Your Contract Carries

hans@hans.study (Hans Study) — Wed, 16 Sep 2026 00:00:00 GMT

Suppliers keep asking me which CPCSC level they should certify to, and the honest answer is that it's the wrong question. You don't pick your level. Each procurement gets a cyber security risk assessment, which the program's industry briefings call the Contract Cyber Security Risk Assessment, the CCSRA, and that assessment decides which level the contract carries. PSPC's public pages put it plainly: the required level is set on a contract-by-contract basis and communicated in the RFP and the contract clauses. Your only real choice is whether you find out what your contracts look like before the assessment does. ## What the CCSRA weighs The assessment turns on the information the contract exposes, not on the size of your company or the dollar value of the work. Commercial off-the-shelf supply with no specified information attached sits outside the program entirely. Once a contract involves non-COTS activity or specified information, the assessment determines both applicability and level. Specified information itself gets graded. The briefing material sorts it into low, medium, and high sensitivity bands, and the low band, the one mapping to Level 1, covers material most suppliers wouldn't think of as sensitive at all: Protected A information, low-sensitivity technical data on dual-use goods, routine procurement documentation like RFQs, purchase orders, and delivery schedules, and non-critical supplier financial information. Read that list again. Purchase orders and schedules. If DND work touches your business at all, the floor of the program probably touches you too. ## The self-assessment you should run first Before any formal assessment lands on your contracts, walk them yourself with the same lens: - List every active and pipeline contract with a defence connection, direct or through a prime - For each one, write down what information actually moves: drawings, specs, schedules, pricing, technical data, anything marked Protected - Grade honestly against the sensitivity bands rather than against your instinct that "it's just a PO" - Flag contracts where you receive information you never asked for; primes routinely over-share, and what lands in your inbox scopes you whether you wanted it or not - Note where each information type is stored, because the assessment outcome becomes your certification boundary later That last habit, tracking the unrequested over-share, is the one that changes behaviour. Once you see that a prime's habit of attaching the full drawing package to every email is what's dragging your certification level up, you start having a different conversation with that prime. ## Why this matters before 2027 Level 1 is self-attested today: an annual self-assessment against 13 controls, required at contract award rather than at bid. As Level 2 assessments phase in from spring 2027, the assessment outcome on a contract stops being paperwork and starts being a gate with a third-party assessor and a multi-month lead time behind it. A supplier who knows their contract portfolio maps to Level 1 can bid with confidence. A supplier who discovers mid-bid that one legacy contract's data pushes them into Level 2 territory has a scheduling problem no proposal team can write around. Read your contracts the way the assessment will. It costs an afternoon, and it's the cheapest risk assessment your company will run this year. The long form of this is [The Study Guide to CPCSC Readiness](/cpcsc_book/), free to read online or as a PDF, and I run contract-portfolio scoping reviews for suppliers who want a second set of eyes before the assessment provides one. Details on the [CPCSC readiness page](/cpcsc/).

[Article] Genetec vs Milestone vs Avigilon for Enterprise Multi-Site: An Opinionated Comparison From the Field

hans@hans.study (Hans Study) — Fri, 04 Sep 2026 00:00:00 GMT

I get asked this question in one of two forms. The first is from an owner writing a tender who wants to know which platform to specify. The second is from an owner who already has one of them at twelve sites, has just acquired a company running a different one at eight more, and wants to know whether to consolidate. The honest answer to both is that all three run large enterprise estates well, the differences are real, and which differences matter depends on what the estate is for.

What follows is how I read them after fifteen years of designing, auditing, and fixing all three. I hold A&E and channel agreements with vendors in this space so I can reach their engineering resources; none of those agreements pays me anything, and the practice sells no equipment and takes no margin on what gets specified. The independence page says how that works. The opinions below are the ones I would give a client across a table.

The shape of each platform

Genetec Security Center is a unified platform: video, access control, intrusion, and licence plate recognition in one Directory, one client, one audit trail, one set of permissions. Synergis, the access control side, is not a bolt-on; it is the same product. That unification is the whole argument for Genetec, and on estates where the same operators handle video and doors, it is a strong argument. The cost is that you are buying the platform's way of doing things, and it is a large, opinionated platform with a correspondingly large surface to design, harden, and maintain. The architecture article covers what that surface looks like.

Milestone XProtect is a video management system first and an integration platform second. It is the most open of the three: the widest device support, the most permissive SDK, the largest third-party integration network, and the least resistance to being one part of somebody else's design. Access control is by integration, and there are several good ones, but it is integration rather than unification and the seams show in the operator experience and in the audit trail. Where an owner has a strong access control platform already and wants video that fits around it, Milestone fits.

Avigilon, now under Motorola Solutions, is the most vertically integrated: Avigilon cameras, Avigilon analytics, Avigilon appliances, and Unity as the on-premises VMS, with Alta as the cloud-managed line. The analytics are the point, and they are especially good when the cameras are Avigilon's. The platform is at its best on estates that were designed around it from the start, and at its most awkward when asked to manage a mixed fleet of somebody else's cameras. The Motorola relationship also gives it a route into public safety radio and command environments the other two do not have.

Where each one wins

Dimension	Genetec Security Center	Milestone XProtect	Avigilon Unity
Video and access in one system	Unified. One client, one audit trail, one permission model.	Integrated. Access control through partners; separate audit trails reconciled after the fact.	Integrated. Access control through Avigilon's own and partner products.
Openness and device support	Broad, with a preference for its own way. Strong on the major camera families.	Widest. The ONVIF reference for most camera vendors.	Narrowest in practice. Best with Avigilon cameras; workable with the majors.
Multi-site architecture	Federation. Mature, well understood, scales to very large estates. Each site keeps its own Directory.	Interconnect and federated architecture. Works; requires more design to get the operator experience right across sites.	Site families and central management. Cleanest on homogeneous estates.
Analytics	Good; strongest through partner integrations and its own recent work.	Through partners, and there are many.	Strongest native analytics, particularly appearance search and classification, on its own cameras.
Licensing shape	Per connection, with maintenance. Predictable; grows with the estate.	Per device, tiered by edition, with a care plan. Flexible; edition choice matters.	Per channel, appliance-led on Unity; subscription on Alta.
Hardening guidance	Best documented. A published hardening guide, a security score in the product, appliances at CIS Level 2.	Good. A hardening guide exists and is maintained.	Adequate. Appliances ship hardened; the documentation is thinner.
Integrator depth in Canada	Deep, particularly in government, transit, and healthcare.	Deep, particularly in enterprise and commercial.	Deep in retail, education, and anywhere Motorola already is.
What it costs to run well	Highest. It rewards a dedicated administrator and punishes neglect.	Moderate. Simpler to keep healthy; more moving parts at the integration seams.	Lowest on a homogeneous estate; rises fast on a mixed one.

The multi-site question specifically

Every enterprise estate ends up federated, whether the platform calls it that or not. Sites have local operators, local network conditions, and local ownership, and the central control room wants to see everything without being responsible for every site's Archiver. The platforms handle this differently and the difference decides a lot.

Genetec Federation lets each site run its own Directory, with its own administrators and its own database, and presents them to a central Directory as federated entities. The central operators see the cameras and doors; the site keeps control of its system. It scales to hundreds of sites and it survives a site's WAN link failing, because the site's system does not need the centre to record. The trade-off is that every site is a full Security Center system, with everything that implies for the databases, the storage, and the hardening, at every site.

Milestone's answer is Interconnect for remote sites and its federated architecture for larger ones. Both work. The design effort is in making the central operator's experience consistent, because the central site sees remote cameras through an integration layer rather than natively, and features like bookmarks, permissions, and audit do not always cross the boundary the way an operator expects. On estates with a strong central control room and lightly staffed sites, that design effort is worth doing once. On estates where every site is a control room, Genetec's model fits more naturally.

Avigilon groups servers into site families with central management, which is clean and easy to administer when every site runs Avigilon appliances and Avigilon cameras. It is the least flexible of the three at the boundary, and an estate that has grown by acquisition, with a different vendor at each acquired site, is the case where I would not put it in the centre.

The security posture of the security system

This is the part of the comparison that owners under-weight and that I weight heavily, because the video system is now an IT system on the corporate network and it is assessed as one. All three vendors publish hardening guidance. Genetec's is the most complete and the most operationalised: a hardening guide that tracks the release, a security score in Config Tool that tells the administrator what is not done, and appliances that ship at CIS Level 2. Milestone's guide is thorough and maintained. Avigilon's appliances ship hardened and the documentation for doing the same on your own servers is thinner.

What matters more than the guide is whether the integrator followed it, and on that the platforms are equal: I find the same gaps on all three, and they are the gaps in the hardening guide on this site. A platform with excellent hardening documentation that was deployed by an integrator who did not read it is less secure than a platform with adequate documentation deployed by one who did. Specify the hardening in the tender, as a deliverable with evidence, and the platform choice matters less.

Licensing, honestly

I am not going to quote numbers, because they change, they are negotiated, and the list price is not what anyone pays at scale. The shapes matter more than the figures.

Genetec's per-connection model with an annual maintenance agreement is predictable and it grows linearly with the estate. The maintenance agreement is not optional in practice; a system without it cannot upgrade, and the version rules mean a system that stops upgrading eventually cannot be upgraded at all without a multi-step migration.

Milestone's per-device model is tiered by edition, and the edition decision is where owners get it wrong: buying Professional+ for an estate that will need Corporate's federation two years later is an expensive correction. Buy the edition for the estate in year three.

Avigilon's Unity licensing is per channel and often bundled with appliances, which makes it easy to buy and harder to compare. Alta is subscription, which is a different conversation about operating versus capital budgets that finance will want to have before the security team does.

Consolidate, or federate the difference

For the owner with twelve sites on one platform and eight acquired sites on another: do not consolidate on day one. Every one of these platforms can present video from the others through integration, and a year of running both, federated to a central view, tells you which one the operators reach for, which one the integrators in your regions actually know, and which one the incident reports come from. Then consolidate, with evidence, onto the one that earned it. Rip-and-replace at acquisition is how owners end up with the wrong platform at twenty sites instead of the wrong one at eight.

The decision, in the order I would ask the questions

Do the same operators handle video and doors, and does the audit trail need to show both in one place? If yes, Genetec, and the rest of the questions are about whether anything rules it out.
Is there an access control platform that is staying, and is it good? If yes, Milestone fits around it with the least friction.
Is the camera fleet going to be Avigilon, and are the analytics the reason for the project? If yes, Avigilon, and design the estate to stay homogeneous.
Who will run it? A dedicated administrator makes Genetec sing. A generalist IT team keeps Milestone healthy with less effort. An estate with no one to run it should be on appliances, whichever vendor's.
Who will integrate and support it in the regions the sites are in? The best platform with no competent integrator within three hours of the site is the wrong platform.
What does the hardening deliverable look like in the tender? If the answer is "the integrator's standard practice," the platform choice is the least of the risks.

If the answers point in different directions, that is the normal case and it is what a pre-purchase design review is for. If they point at one platform and the tender is specifying a different one because of a relationship, that is worth a conversation before the tender closes rather than after the contract is signed.

And whichever platform it is, the estate will be healthy in year three only if someone checks. The Genetec, Milestone, and Avigilon health checks exist because the failure modes are the same on all three, and they are almost never the platform's fault.

[Article] Upgrading to Genetec Security Center 5.14: The Runbook, the Order of Operations, and What Breaks

hans@hans.study (Hans Study) — Wed, 02 Sep 2026 00:00:00 GMT

The migration paths page answers the question of which route your system can take to 5.14, and whether it needs a stop at 5.11 on the way. This is the next question: it is Friday evening, the change window is open, and the route is decided. What happens, in what order, and what do you check before deciding whether to go home or roll back.

I have run this upgrade on systems from thirty cameras to several thousand. The mechanics of the installer are the easy part and the vendor documents them well. The parts that go wrong are the ones the installer does not know about: the SDK plugin nobody remembered, the federated site three time zones away, and the fact that the Web Client the security manager uses every morning does not exist in 5.14.

What is different about 5.14 specifically

Three things in 5.14 change the upgrade in ways earlier releases did not.

The Web Client is retired. The browser-based Web App replaces it, and it is a different product with a different feature set and a different URL. Anyone who used the Web Client to monitor, to acknowledge alarms, or to run reports needs to be told before the upgrade, shown the Web App before the upgrade, and have their bookmarks changed after. This is a change management item, not a technical one, and it is the one that generates the most calls on Monday.

The media component is 64-bit. Security Desk and the media pipeline underneath it are 64-bit in 5.14. Client workstations that were marginal on 5.13 with 32-bit decoding may behave differently, generally better, but any third-party video plugin or decoder that was 32-bit only stops loading. Check the plugin list on the workstations, not just the servers.

5.14.0.1 followed the initial release within weeks. Upgrade to the current 5.14.x build, not to 5.14.0.0, and read the known issues for that build before the window. The release notes are specific about what was fixed between the two, and some of it matters.

Pre-flight, the week before

Inventory, per component, with build numbers. The Directory, every Archiver, every Access Manager, the Media Router, every workstation, every SDK integration, and both ends of every federation. The migration page explains why the oldest component sets the route. The inventory is also your rollback map.
Platform underneath. Windows Server build and SQL Server version checked against the 5.14 supported matrix. If either needs to move, that is a separate change, done first, with its own soak period. The Server 2025 delta is relevant if the OS move is to 2025.
Database health. Size, free space, recovery model, and a backup that has been restored somewhere. The SQL article covers the checks. An upgrade runs schema changes against the Directory database, and a database on an Express install near its 10 GB limit will fail the upgrade rather than the upgrade failing gracefully.
Licence. The licence must be valid for 5.14 and the SMA current. Genetec's licence check happens at upgrade time, and discovering the maintenance agreement lapsed is not a Friday-night discovery you want.
SDK and plugins. Every integration listed with its vendor and its 5.14 compatibility confirmed in writing. Intercom, intrusion, visitor management, elevator, LPR analytics, custom dashboards. The ones that are not 5.14-compatible either get updated before the window or get a decision: go without them, or postpone.
Federation. Federated Security Center systems have their own version rules. Confirm the remote sites are within the supported range for a 5.14 host, and agree the upgrade order with whoever owns them.
Client workstations. Count them, confirm each meets the 5.14 requirements, and check for 32-bit plugins. A plan for who upgrades each one and when.
Backups, all of them. Directory database, every role database, the Genetec configuration through Server Admin, and a snapshot or image of each server if the platform allows it. Copied off the hosts. Tested.
Communication. The Web Client retirement, the window, the expected outage, and the rollback deadline, sent to everyone who uses the system, a week out and again the day before.

Rehearse it. Restore the Directory backup onto a lab server, upgrade the lab to 5.14, and open Config Tool. This takes an afternoon and it finds the failed schema migration, the expired licence, and the plugin that will not load, on a Tuesday instead of a Friday night. Every upgrade I have seen go badly skipped this step.

Order of operations, the night of

The order matters because 5.14 components will talk to older roles during the transition, but not indefinitely and not in every direction. Directory first, then the roles that depend on it, then the clients.

Stop recording gracefully. Put the Archivers into a state where the last file closes cleanly. Note the time. Any gap in recording starts here and you will be asked about it later.
Final backups. Directory database and configuration, again, now that nothing is changing. This is the rollback point.
Directory server. Run the installer, let it upgrade the Directory database schema, and wait. On a large Directory database the schema migration can take a long time and it will look like nothing is happening. Do not interrupt it. When Server Admin comes back, confirm the Directory role is healthy and the build number is the one you expected before doing anything else.
Expansion servers, one at a time. Archivers, Access Managers, the Media Router, in whatever order minimises the recording gap, which usually means the busiest Archiver first. After each one, confirm the role comes up healthy in Config Tool and that it is recording or managing whatever it is meant to. Then the next.
Verify recording before moving on. Every Archiver recording, every camera streaming, timeline populating. This is the first go or no-go point: if recording is not healthy here, the rest of the night is troubleshooting rather than upgrading, and the rollback decision starts now.
Integrations. Bring up each SDK integration and confirm it connects. The one that fails is the one that was not confirmed in pre-flight.
Federation. Confirm each federated site reconnects and that entities and events flow both ways.
Clients. Upgrade Config Tool and Security Desk on the workstations, starting with the control room. Confirm login, live video, playback, alarm handling, and any plugin the operators depend on. Confirm the Web App is reachable and that the people who used the Web Client can do what they need in it.
Genetec Update Service. Confirm GUS sees the new build and is not about to apply something else on its own schedule.

The rollback decision

Decide the rollback deadline before the window opens, write it down, and hold to it. The usual shape: if recording and alarm handling are not healthy by a fixed time, with enough of the window left to restore, you restore. The decision is made against the checklist, not against how close you feel you are to fixing it.

Rollback for Security Center is a restore, not an uninstall. Restore the Directory database backup taken at step 2, reinstall the previous build on the Directory and the expansion servers, and restore each role's configuration. The database schema was upgraded in place, which is why the pre-upgrade backup is the only way back. Snapshots of the servers make this faster and are worth the storage.

What rollback does not undo: video recorded during the upgraded period stays in whatever format the 5.14 Archiver wrote, and in practice it remains readable. Events written to the 5.14 schema are gone once the database is restored. Note the interval so the incident record is honest.

The first week

Monday morning. Someone in the control room before the shift change, watching operators use the new Security Desk and the Web App. The complaints on Monday are almost never bugs; they are workflow changes nobody was shown. Ten minutes of standing next to an operator resolves most of them.
Retention. Confirm the Archivers are keeping video for the configured period and that the free-space threshold behaviour is what it was. An upgrade is an opportunity for a default to reassert itself.
Health Monitor. Review the health events for the week. An entity that went unhealthy at 02:14 on upgrade night and stayed there is easy to miss under the noise of the upgrade itself.
Database. Re-run the maintenance job and check the Directory database size. The schema migration can leave indexes in a poor state and the first maintenance pass after an upgrade is the one that matters.
Hardening. Apply the 5.14 hardening guide's recommendations that were not in the previous release. An upgrade that leaves the system at the old release's security posture is half done.
Documentation. Build numbers, the date, what was changed, what was skipped, and why. The next person to do this will be reading it, and there is a fair chance it will be you.

Done this way the upgrade is uneventful, which is the only kind of upgrade a security system should have. The interesting part is the pre-flight, and the pre-flight is where the time goes. If a proposal for this work has one line for the upgrade night and nothing for the week before, it is a proposal for a different, more exciting evening than the one you want.

[Article] Genetec Archiver Storage and Retention: The Maths, the Disks, and Where Archivers Actually Fall Over

hans@hans.study (Hans Study) — Mon, 31 Aug 2026 00:00:00 GMT

The Archiver is the role that turns cameras into evidence, and it is the role whose storage was sized once, at tender, from a bitrate somebody picked off a datasheet. Three years later there are more cameras, higher resolutions, a retention policy that got extended after an incident, and a system that silently keeps eleven days of video instead of the thirty the policy says. Nobody notices until the eleventh day is the one that matters.

This is how I size Archiver storage so it still meets the policy after the system has grown, and how I read a storage layout that is about to fail. It picks up where the video drive section of the tuning guide leaves off: that page covers how to configure a volume; this one covers how many you need and what they should be made of.

Retention arithmetic that survives contact with reality

The calculation is simple and everyone does it wrong in the same way.

Storage (TB) = cameras × average bitrate (Mbps) × 3600 × 24 × retention days ÷ 8 ÷ 1,000,000 × overhead

Worked through for 200 cameras at 4 Mbps average with 30 days of retention:

200 × 4 × 86,400 × 30 ÷ 8 ÷ 1,000,000 = 259 TB of video
× 1.15 for file system and index overhead = 298 TB

The number that breaks the calculation is the bitrate. The datasheet figure is an average under the vendor's test scene. A camera facing a car park at night with infrared on and rain falling produces two to three times its daytime average, and it does so for the whole of the winter. A camera on H.264 continuous recording in a busy lobby is not producing the number the calculator was given either. Use one of three sources for the bitrate, in order of preference:

Measured. Security Center's statistics tasks report actual archived bitrate per camera. On an existing system, this is the only number worth using.
Pilot. On a new system, run ten representative cameras for a week and measure.
Datasheet, multiplied by 1.5 for outdoor and 1.2 for indoor. Then write the assumption down so the next person knows why the number is what it is.

Then add the things the calculator forgets: motion-triggered recording that turns out to be continuous because the scene has a flag in it, the 20 percent of cameras that were added after the tender, and the retention extension the security manager will ask for after the first incident review. Size for the system it will be in year three, not the one on the drawing.

Throughput, per Archiver and per volume

Capacity is the number everyone sizes to. Throughput is the number that decides whether the Archiver can actually write the video it has room for.

Each Archiver has a practical ceiling on the aggregate bitrate it can ingest and write, set by CPU, NIC, and above all disk. Genetec's enterprise guidance has long put a comfortable working figure around 300 Mbps per Archiver on conventional hardware, with higher figures achievable on well-specified servers and appliances. Treat the vendor's current number for your release as the ceiling and design to run at two-thirds of it. An Archiver at 90 percent of its ceiling records fine until a firmware update triples the bitrate on a camera family, and then it drops frames on every camera it owns.

Per volume, the constraint is sustained sequential write. A single 7,200 RPM enterprise drive sustains around 150 to 200 MB/s on its own; in a RAID set the array throughput is what matters, and it depends on the level, the controller, and the cache. The Archiver writes many streams concurrently, which the operating system turns into something less than pure sequential I/O. The safe planning figure is that a volume should not be asked to sustain more than half of its benchmarked sequential write rate under Archiver load.

The practical consequence: an Archiver with one large volume is usually throughput-bound before it is capacity-bound. Spread the cameras across volumes, and spread the volumes across controllers where the hardware allows it.

RAID and drive selection

Option	Where it fits	Where it does not
RAID 6	The default for archive volumes. Two-drive fault tolerance, good capacity efficiency, adequate sequential write on a controller with battery-backed or flash-backed cache.	Rebuild times on large drives run to days, during which write performance drops and a third failure loses the volume.
RAID 10	Archivers where throughput matters more than capacity: LPR, high-bitrate cameras, small fast volumes.	Half the raw capacity. Expensive at scale.
RAID 5	Small volumes of small drives, if at all.	Single-drive tolerance on multi-terabyte drives is a rebuild waiting to fail. I do not specify it for video.
No RAID	Nowhere in production.	A single drive failure is missing video with no recovery.

Drives: enterprise or surveillance-class, rated for continuous duty and for the vibration of a chassis full of other drives. Desktop drives fail in archive duty within a year or two, and they fail in groups because they were bought in one batch. Match the drive to the array size; helium-filled high-capacity drives are fine in RAID 6 with a controller that handles the rebuild load, and they are a false economy in RAID 5.

Controller cache with battery or flash backup is not optional. Without it, write-back caching is unsafe and the controller falls back to write-through, and the sequential write figure the array was sized on is now a fraction of itself.

Local, iSCSI, or SMB

Direct-attached storage is the simplest and, per terabyte, usually the cheapest. It is also the one with the fewest moving parts between the Archiver and the disk, which matters when the disk is what makes the video exist.

iSCSI to a SAN or a NAS presenting block storage works well and is the normal pattern for larger deployments. Give it a dedicated network path, jumbo frames end to end, and multipath if the target supports it. The volume appears to Windows as a local disk and the Archiver treats it as one.

SMB shares are supported for archive storage and I avoid them where I can. The path from the Archiver to the file involves the SMB client, the network, and the file server's own file system, each with its own caching behaviour and its own failure modes, and an SMB share that becomes briefly unavailable produces recording gaps that are hard to attribute. Where SMB is the only option, keep the share on a dedicated file server with nothing else on it, disable SMB signing on that path if policy permits, and monitor it as if it were an Archiver, because functionally it is.

What the Archiver does when the disk is full

The Archiver does not stop when a volume fills. It deletes the oldest video on that volume to make room, subject to the retention settings, and carries on. That is the correct behaviour and it is also why nobody notices that retention has silently dropped from thirty days to eleven: the system keeps recording and the timeline keeps working, it just does not go back as far as the policy says it should.

Two settings govern this. The retention period per camera, which is the upper bound on how long video is kept, and the minimum free space threshold on the volume, below which the Archiver starts deleting. If actual retention is shorter than the configured retention, the volume is undersized for its cameras and the deletion is being driven by free space rather than by policy. That condition should be an alarm, and the Health Monitor can raise one. On most systems I audit, it is not configured to.

Protected video. Video that has been flagged as protected is exempt from automatic deletion. On a site where operators protect footage generously and nobody ever unprotects it, protected video accumulates until it is a meaningful share of the volume and the effective retention for everything else shrinks to match. Review the protected footage list quarterly.

Redundancy: archive transfer and redundant archiving

RAID protects against a drive failing. It does nothing about an Archiver failing, a controller failing, a site burning down, or ransomware encrypting the volume. For any of those you need a second copy somewhere else.

Redundant archiving assigns a second Archiver to record the same cameras at the same time. It doubles ingest, doubles storage, and gives you two independent copies from the moment of recording. It is the right answer where the video is truly business-critical or where regulation requires it, and the wrong answer everywhere else because of what it costs.

Archive transfer copies recorded video from one Archiver to another on a schedule, typically the most recent day or the video from specified cameras, to a central or off-site store. It costs a fraction of redundant archiving and it is what most systems should have and do not. Set it up for the cameras whose footage would be requested in an incident, schedule it overnight, and monitor the transfer task the same way you monitor the recording.

Failover archiving is different again: a standby Archiver takes over recording if the primary fails. It protects continuity of recording, not the video already recorded, which stays on the failed Archiver's disks until it comes back.

The failures, by symptom

What operators report	What is usually wrong
Timeline only goes back eleven days on a thirty-day policy	Volume undersized; free-space deletion outrunning retention. Sometimes protected video hoarding.
Recording gaps on many cameras at once, network fine	Volume throughput exceeded. Check disk queue length on the archive volume during the gap.
Recording gaps on cameras on one Archiver	That Archiver over its ingest ceiling, or its antivirus exclusions gone.
Playback stutters, live is fine	Archiver database fragmentation, or read contention on an array that is rebuilding.
Everything fine, then a volume vanishes	RAID rebuild failed, or the iSCSI path dropped. Multipath and controller logs.
Video exists but export is slow or fails	Export share on the same volume as the archive. Move it.

The checklist

Measured bitrate per camera, not datasheet, and a documented growth assumption.
Retention arithmetic with the overhead factor, sized for year three.
Aggregate bitrate per Archiver at two-thirds of the ceiling or less.
Sustained write per volume at half the benchmarked figure or less; cameras spread across volumes.
RAID 6 or RAID 10, enterprise drives, controller cache with battery or flash backup.
Free-space alarm configured in Health Monitor and routed to someone.
Actual retention compared to configured retention, per camera, quarterly.
Protected video reviewed and released.
Archive transfer configured for incident-relevant cameras and monitored.
Antivirus exclusions on every archive path. The exclusion list is separate because it applies to every platform.

Storage is where a video system either keeps its promises or does not, and it is the part that gets sized once and forgotten. If the last time anyone checked actual retention against the policy was commissioning, that is the first thing to check, and it takes about ten minutes in Security Desk.

[Article] SQL Server for Genetec Security Center: Sizing, Maintenance, and the Failures That Follow Neglect

hans@hans.study (Hans Study) — Fri, 28 Aug 2026 00:00:00 GMT

When a Security Center system slows down, the first suspect is usually the Archiver and the second is the network. In my experience the database is the cause more often than either, and it is the one nobody checked, because SQL Server was installed by the Genetec installer five years ago and has not been looked at since.

Security Center is a database-backed application. The Directory role keeps its entire configuration, every event, every alarm, every audit entry, and every user session in SQL Server. Each Archiver keeps a database of its own that indexes every video file it writes. The Access Manager, the LPR Manager, and the Health Monitor each have one too. When those databases are healthy the system feels instant. When they are not, the symptoms show up everywhere except the place they started: Security Desk takes twenty seconds to log in, the timeline crawls, alarms arrive late, and the Directory restarts itself at 03:00 for no reason anyone can find.

This is the database side of the tuning guide, and it is the section of that work that most often turns a slow system into a fast one without buying anything.

Scope. This covers SQL Server as Genetec uses it, on Windows, in the on-premises deployment pattern that still accounts for most enterprise systems. The architecture article covers where each role and its database should sit. This one covers what to do with the databases once they are there.

Express or Standard: the decision most systems never made

The Security Center installer will happily deploy SQL Server Express, and a large share of production systems are still running on it because nobody revisited the choice once the system went live. Express is free and it is fine for small systems. It also has hard limits that do not announce themselves.

Limit	SQL Server Express	What it means under Security Center
Database size	10 GB per database	The Directory database on a busy multi-site system reaches this within a few years of event history. When it does, writes fail and the Directory stops.
Memory	Roughly 1.4 GB buffer pool	Frequently accessed data no longer fits in cache. Every timeline query goes to disk.
Compute	Lesser of one socket or four cores	Parallel query plans are unavailable. Reports and audit searches serialize.
SQL Server Agent	Not included	No built-in scheduler for maintenance. Backups and index work have to be scripted through Task Scheduler.

The 10 GB limit is the one that causes outages. It is enforced per database, so the Directory database is the one that hits it, and it hits it silently. The first sign is usually an event that fails to write, followed by a Directory role that goes unhealthy, followed by a phone call. If the Directory database is over 6 GB today and growing, plan the move to Standard now rather than during the incident.

My rule: Express is acceptable for a single-site system under roughly 150 cameras with short event retention and a documented plan for what happens at 8 GB. Anything federated, anything with access control at scale, anything with LPR, and anything where the Directory is business-critical belongs on Standard. The licence cost is small against the cost of a Directory outage on a site that depends on it.

Max server memory

SQL Server takes as much memory as the operating system will give it. On a dedicated database server that is the correct behaviour. On a Security Center server where SQL shares the box with the Directory service, the Genetec Server service, and whatever else got installed, it starves everything else and the Directory starts paging. This is the single most common configuration gap I find, and it is a one-line fix.

Set max server memory explicitly. The number depends on total RAM and what else runs on the host. A defensible starting point on a server that runs the Directory role alongside SQL:

Total RAM   Reserve for OS + Genetec   SQL max server memory
16 GB       8 GB                       8192 MB
32 GB       12 GB                      20480 MB
64 GB       16 GB                      49152 MB

EXEC sys.sp_configure N'show advanced options', N'1';
RECONFIGURE;
EXEC sys.sp_configure N'max server memory (MB)', N'20480';
RECONFIGURE;

Then watch it. If the buffer cache hit ratio stays high and Page Life Expectancy is stable, the cap is fine. If SQL is consistently at its cap and the Directory is healthy, raise it. If the Directory is paging, lower it. The goal is a cap that keeps the working set in memory without starving the application that owns the server.

Set min server memory as well, to roughly half the max, so that a memory-hungry process cannot squeeze SQL down to nothing during a backup or a video export.

Recovery model and backups

Every Security Center database should be in the Simple recovery model unless you have a specific reason to run Full, and that reason is usually log shipping or point-in-time restore, neither of which most security systems use. Full recovery without regular log backups produces a transaction log that grows until the disk fills, at which point the database stops accepting writes and the Directory stops with it. I have watched a 200 GB transaction log take down a Directory whose actual data was 4 GB.

ALTER DATABASE [Directory] SET RECOVERY SIMPLE;

Check every database, not just the Directory. Archiver databases are created with whatever the model default was at the time, and the model default is not always what you expect.

For backups, use the Server Admin backup schedule that Genetec provides for the Directory and role databases. It handles the Genetec side correctly, it is aware of the roles, and it produces backups that Genetec support will accept. Back up to a different volume than the database files and copy the result off the host. A backup on the same disk as the database it protects is not a backup.

Test the restore. Once a year at least, restore the Directory backup onto a lab server and bring a Directory up on it. A backup that has never been restored is an assumption, and Security Center configuration is exactly the kind of thing that turns out to have been silently incomplete when it is finally needed.

Autogrowth, in megabytes, not percent

SQL Server grows a data file when it fills. The default growth increment on older installs is 1 MB for data and 10 percent for the log. Growing 1 MB at a time on an event-heavy Directory database means thousands of growth operations, each one briefly blocking writes and fragmenting the file on disk. Ten percent growth on a large log produces increasingly enormous growth events, each one taking longer and blocking longer.

Set fixed growth in megabytes on every Security Center database. For the Directory, 256 MB data and 128 MB log is a reasonable start on a system of any size. For Archiver databases, which index video rather than store events, 128 MB is usually enough.

ALTER DATABASE [Directory]
  MODIFY FILE (NAME = N'Directory', FILEGROWTH = 256MB);
ALTER DATABASE [Directory]
  MODIFY FILE (NAME = N'Directory_log', FILEGROWTH = 128MB);

Pre-size the files while you are there. If the Directory database is 5 GB and growing a gigabyte a year, size the data file to 8 GB now and let it grow in 256 MB steps from there. Growth events during operation are the thing you are trying to avoid, and pre-sizing avoids most of them.

Enable instant file initialization by granting the SQL Server service account the Perform Volume Maintenance Tasks right. Data file growth then completes without zeroing the new space first. It does not apply to log files, which is one more reason to size the log sensibly up front.

TempDB

The Directory uses TempDB heavily for report generation, audit searches, and the sort operations behind the timeline. On the default install TempDB is a single file on the system drive, which means it competes with the operating system and the Directory database for the same disk.

Move TempDB to its own volume. Give it one data file per core up to eight, all the same size, and set them to grow in fixed megabyte increments. On a four-core Directory server, four 512 MB files and a 256 MB log is a sensible baseline. This is standard SQL Server practice rather than anything Genetec-specific, and it makes a measurable difference to report and search latency on busy systems.

Index maintenance

Security Center writes events constantly and deletes them on a retention schedule. That pattern fragments indexes faster than most workloads, and a heavily fragmented Directory index turns a timeline query that should take milliseconds into one that takes seconds. The symptom operators report is "the system is slow in the afternoon," because by afternoon the day's events have arrived and the indexes are in their worst state.

On SQL Server Standard, schedule a weekly job through SQL Server Agent that reorganizes indexes over 10 percent fragmented and rebuilds those over 30 percent, then updates statistics. On Express there is no Agent, so the same script runs from Windows Task Scheduler through sqlcmd. Either way, run it in the quietest window the site has, which for a security system is usually not overnight, when the Archiver is at full load, but mid-morning on a weekday when recording is steady and nobody is running reports.

sqlcmd -S .\SQLEXPRESS -E -Q "EXEC sp_MSforeachdb 'USE [?]; IF DB_ID() > 4 BEGIN EXEC sp_updatestats; END'"

That is the minimum. A proper maintenance script that inspects fragmentation per index and acts accordingly is better, and the Ola Hallengren maintenance solution is the one I deploy on Standard installs because it does exactly that and it is free.

Event retention is a database setting wearing a Genetec costume

The Directory keeps every event, every alarm, and every audit trail entry until the retention period tells it to stop. The defaults are generous and on a busy access control site the event tables become the largest thing in the database within months. This is the growth that takes Express installs to their 10 GB limit and Standard installs to the point where index maintenance stops finishing in its window.

Set retention deliberately, per event type, in Server Admin. Decide how long you actually need access events, alarm history, and audit trails, and set those numbers. Ninety days of access events with a year of audit trail is a defensible baseline for a corporate site; a regulated facility will have a policy that sets the number for you. What is not defensible is leaving the default in place because nobody made the decision, and then discovering the decision was made for you by the disk.

The Archiver's database is a different case. It indexes video files rather than storing them, so its size tracks the number of files rather than their duration. A system with short recording segments and many cameras produces a large Archiver database. That is normal, but it should be on the same maintenance schedule as the Directory, and it should never be on SQL Express on a large Archiver.

The failures, by symptom

What operators report	What is usually wrong	Where to look first
Security Desk takes 15 to 30 seconds to log in	Directory index fragmentation, or SQL memory starved	Fragmentation on the Directory's user and entity tables; max server memory
Timeline is slow to populate in the afternoon	Index fragmentation from the day's event writes	Weekly maintenance job, and whether it is actually completing
Directory restarts overnight	Transaction log or data file filled the disk	Recovery model; free space on the SQL volume
Events stop appearing, Directory role unhealthy	Express 10 GB limit reached	Directory database size; event retention
Everything is slow after a reboot for an hour	Cold buffer cache on an undersized memory cap	Max and min server memory; total RAM
Reports time out	TempDB on the system drive, or Express core limit	TempDB placement; edition

The checklist

This is what I check on every Security Center database during a health check, in the order that finds the worst problems fastest.

Edition, and the size of every database against the Express limit if it applies.
Max and min server memory set explicitly, and appropriate for what else runs on the host.
Recovery model on every database, and the size of every transaction log.
Autogrowth in fixed megabytes on every file. Pre-sized data files. Instant file initialization enabled.
TempDB on its own volume with multiple equal files.
A maintenance job that exists, runs, and finishes. The job log, not the schedule, is the evidence.
Backups on a different volume, copied off the host, with a restore that has been tested.
Event retention set deliberately and documented, per event type.
Antivirus exclusions on the SQL data, log, and TempDB paths. The tuning guide has the list.

None of this needs new hardware. Most of it is an afternoon. On the systems where I have done it the difference in login time and timeline responsiveness is the kind of thing operators notice and mention, which for infrastructure work is the highest compliment available.

[Article] Bill C-8 Is Law. What the CCSPA Means If You Service Critical Infrastructure

hans@hans.study (Hans Study) — Mon, 24 Aug 2026 00:00:00 GMT

Bill C-8 received Royal Assent on 15 June 2026. It is now Statutes of Canada 2026, chapter 9. If you have been tracking this as Bill C-26, that bill died at the 2025 prorogation and came back under a new number. Same architecture, new label. Most of the coverage since June has been written for boardrooms. This is the version for the people who actually install and maintain the systems, because the supply chain clauses reach further down than the headlines suggest. ## Two parts, and only one of them is live The single most useful thing to understand about C-8 is that it did two different things on two different timelines. **Part 1 amends the Telecommunications Act.** It is in force now. It added security as an explicit policy objective and gave the government authority to compel action against threats in the telecom sector. That happened on Royal Assent. No further step was required. **Part 2 is the Critical Cyber Systems Protection Act.** It is not in force. The CCSPA comes into effect by order in council, phased, and as of late August 2026 no date has been announced. Both facts are true at once, which is why you will see confident articles claiming C-8 is either fully in effect or entirely theoretical. Neither is right. ## Schedule 2 is empty, and that is the number to watch Here is the detail that decides whether any of this applies to you today. CCSPA obligations do not attach to sectors in the abstract. They attach to classes of operators listed in Schedule 2 of the Act. Schedule 2 is currently empty. No organization in Canada carries a CCSPA obligation right now. Not one. So if a vendor is selling you a CCSPA readiness package against a deadline, ask them which order in council created it. There isn't one yet. That is a reason to prepare on your own schedule, and a reason to be sceptical of anybody manufacturing urgency. The sectors expected to be designated are the ones you would guess: telecommunications, banking, energy including pipelines and power lines, nuclear, interprovincial and international transport, and clearing and settlement. If you work in any of those, the order is coming. You just do not have a date. ## Ninety days is the part that should worry operators When a class does get designated, the operators in it have ninety days to have a cyber security programme in place. Ninety days is nothing. It is not enough time to inventory an OT estate, let alone build a programme around it, get it approved, and stand up the evidence to show it is operating. Any operator who waits for the order in council before starting will spend those ninety days discovering what they own. The programme itself has to do more than tick an IT box. It has to identify and manage cyber security risks including supply chain and third-party product risk, protect critical cyber systems from compromise, detect incidents, and minimise their impact. If that shape looks familiar, it is the NIST identify, protect, detect, respond, recover cycle wearing Canadian clothes. On top of the programme there is an annual review, an obligation to notify the regulator of changes, incident reporting to the Communications Security Establishment, and compliance with confidential cyber security directions that the operator may not be permitted to discuss. One requirement that gets less attention than it deserves: cyber security records have to be kept in Canada. If your client's logging, monitoring, or documentation lives in a cloud region outside the country, that is a design problem with a delivery date attached. Penalties run to fifteen million dollars for operators and one million for directors. I do not think the number is the interesting part. What is interesting is what a penalty of that size does to how seriously an operator treats the questionnaire it sends its vendors. ## Why this lands on integrators You will not be designated. You will be asked. A designated operator cannot satisfy the supply chain and third-party risk obligation without reaching into the people who install, configure, patch, and remotely access its critical systems. That is the integrator, the maintenance contractor, and the vendor with a support tunnel into the plant. So the mechanism is commercial rather than regulatory. Nobody from the government audits your shop. Your client audits your shop, because their programme requires it, and the questions arrive as a condition of the next contract. Based on what CPCSC did to defence suppliers, expect the questions to look roughly like this. Who has remote access to the client's systems and how is it brokered. What happens to credentials when your technician leaves. How you patch, and how you handle equipment you cannot patch. Where your records live. Whether you have ever had an incident, and what you did about it. None of those are hard questions if you have already answered them. All of them are hard if the first time you see them is in a procurement portal with a deadline. ## What I would actually do now Not much, and deliberately so. There is no deadline, and building a compliance programme against an order in council that does not exist is how budgets get wasted. What is worth doing is cheap. Find out whether your clients sit in a sector that is likely to be designated. If they do, they will be asking you questions inside the next couple of years, and knowing that changes how you scope work today. Write down your own answers to the questions above. Not a policy document. A page. Who has access, how it is controlled, what you do when something goes wrong. That page is most of what a vendor questionnaire asks for, and writing it once beats improvising it five times. Fix the things you already know are wrong. The forgotten cellular modem on a panel. The shared vendor account with a password from 2019. The flat network where the historian and the safety system share a broadcast domain. Those are findings today, regardless of what any Act says, and they are covered in more depth in [OT network security controls](/ot-network-security-controls/) and [who owns the network](/who-owns-the-network/). Watch for the order in council rather than the news cycle. The Canada Gazette is where the designation will actually appear. ## The honest summary C-8 is law. The CCSPA is not yet operative. Schedule 2 is empty, no organization is currently obligated, and no compliance deadline exists. And the work still arrives before the deadline does, because it arrives through your clients rather than through the regulator. Ninety days after designation is far too late to start, so the operators who handle this well will start early, and they will start by asking their vendors questions. Have answers ready. If you supply or maintain systems for an organization in one of the designated sectors and you want the vendor-side answers written down before somebody asks for them, [that is the kind of engagement I take](/advisory/).

[Article] 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 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. Applying this baseline, or auditing it against a system already in production, is what a [Genetec Health Check](/genetec-health-check/) covers across servers, network, and security. [Independent Genetec consulting](/genetec-consulting/) is where the hardening, architecture review, and troubleshooting work gets done, alongside your integrator and on your behalf.

[Article] 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. Uptime is absolute, and a control you would apply without thinking on the corporate network can take a plant offline. That is why OT advice copied out of IT playbooks fails in the field. The controls below hold up, because they respect how industrial systems actually run. ## Zones and conduits, not a flat plant Segmentation is the foundation. The OT version is more deliberate than [VLANs on the corporate side](/standards-guidance/vlan-segmentation-physical-security-networks/). IEC 62443 frames it as zones and conduits. Group assets by function and risk into zones. Define exactly what crosses between them, through controlled conduits. Default to deny. The Purdue model gives you the layers to start from. Watch for the flat plant network where the historian and the safety system share a broadcast domain. That is the most common OT finding I see, and the most dangerous. ## Put an iDMZ between the plant and the business IT and OT converged whether anyone planned it or not. What matters now is whether the boundary is controlled. Build an industrial DMZ. Nothing on the business network talks directly to the plant. Data that has to move, historian replication or remote views, moves through brokered services in the iDMZ. A compromise on the corporate side then hits the DMZ instead of the controllers. If a business-network machine can open a socket straight to a PLC, you do not have a boundary. You have a label. ## Know the protocols, because they will not defend themselves Modbus, DNP3, S7, EtherNet/IP, and OPC have little or no authentication by design. You cannot patch that away. So account for it. Protocol-aware segmentation. Deep packet inspection where it earns its keep. A clear answer to what each conduit is allowed to carry. Treating industrial protocols like HTTP is how IT-style controls break OT. ## Monitor passively, because active scanning breaks things A vulnerability scanner that is routine on the corporate network can knock an old PLC offline just by probing it. I have watched it happen. Monitor passively instead. Tap the traffic, baseline what normal looks like, and alert on the deviation, without ever sending an unsolicited packet to a control device. You get visibility into the 200 devices nobody inventoried. You also avoid being the reason the line stopped. ## Make remote access deliberate Vendors and operators need in. The default is a flat VPN into the plant, or a forgotten cellular modem on a panel, and that is how the quiet intrusions get their foothold. Broker it. Route remote access through a jump host in the iDMZ, monitored and time-boxed, with multi-factor on the way in and a recording of what was done. Convenient back doors are how state-linked actors live off the land inside critical infrastructure for months at a time. ## Patch on the plant's terms, and compensate when you cannot OT patches lag for real reasons. A reboot is a production event. Vendor certification takes time. Some systems will never be patched, because the vendor is gone. Pretending otherwise is not a plan. Tie a patch cadence to maintenance windows for what you can patch. Then wrap compensating controls around what you cannot: tighter segmentation, monitoring, access restriction. An unpatchable system behind a tight conduit is defensible. An unpatchable system on a flat network is an incident waiting for a date. ## Keep safety systems separate Safety instrumented systems exist to bring a process to a safe state. They do not belong on the same network as everything else. Separate the SIS from the basic process control system, physically or logically. Get that wrong and a security incident becomes a safety incident. Keep them apart. ## Own it across the boundary The hardest part of OT security is the seam, not any single control. The plant team owns uptime. IT owns the network. Security owns policy. The OT network falls in the gap between all three. It is [the same ownership gap that swallows physical security networks](/who-owns-the-network/). Someone has to own the converged environment end to end, with the authority and the budget that go with it. Name them before the next integration, not during the incident review. Unowned infrastructure does not get secured, and on a plant network the cost of that is measured in more than data. If your clients sit in a sector that will be designated under the [Critical Cyber Systems Protection Act](/bill-c-8-ccspa-critical-infrastructure/), these are the controls their supply chain questions will reach for. None of these controls require breaking the process to secure it. They require understanding the process well enough to secure it the way it actually runs. That is the whole job. If you are working this on a live plant network, [industrial and OT network advisory](/industrial-ot-networks/) is the engagement that covers it.

[Article] 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, CISSP, is an independent network and security consultant and fractional CISO in Ontario, Canada.*

[Article] 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, CISSP, is an independent network and security consultant and fractional CISO in Ontario, Canada, focused on the boundary where physical security, OT, and IT meet.*

[Article] 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, CISSP, is an independent network and security consultant and fractional CISO in Ontario, Canada. He has spent 15+ years on critical infrastructure, defence, and public safety networks.*

[Article] 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 turns a software upgrade into a hardware refresh, and on Genetec's schedule rather than yours. Where the system lives is a live decision now. On-premises, cloud, or hybrid. SaaS wasn't a serious option when most of these 5.9 systems were built. It is today, and it's worth weighing before you default to same-as-before. And licensing decides what you're actually allowed to do. Your upgrade entitlement and your Advantage status set the menu and the price. Check that first. Plan around it second. The supported route off 5.9 and what it involves is laid out in the [Genetec Security Center migration paths](/migrations/genetec-security-center/) reference. **End of life is a clock, not a fire.** You don't have to move this week. You do have to move, and the version of this that goes badly is always the one where somebody else picks the date. An auditor. An insurer. Whoever ends up writing the incident report. Pick it yourself. Map the path, find out what hardware lives through the jump, decide where the system should sit for the next 5 years, and get it on a calendar while it's still your call. Once it stops being your call, it gets expensive, and you don't get to argue the timeline. Mapping that path is exactly what a [Genetec Health Check](/genetec-health-check/) is built for. It tells you what hardware survives the jump, what the upgrade route looks like, and where the system should sit next. If you want a hand planning the move, [independent Genetec consulting](/genetec-consulting/) covers upgrade planning and deployment oversight. [Start a conversation](/contact/) while the timeline is still yours to set.

[Article] 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 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 →

[Article] Axis Camera Station Pro 6.14: AI, Analytics, and Search Have Finally 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 skeptical of Axis Camera Station for years, without saying so loudly. Not because the product was bad, but because Axis spent the better part of a decade trying to position it as a "good enough" VMS for small-to-medium deployments while letting Genetec, Milestone, and Avigilon own the enterprise conversation. ACS was the camera-vendor's afterthought. It worked. Nobody got excited about it.

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

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

Where the version stands today

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

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

Smart Search 2: the feature that changes the conversation

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

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

Two search modes:

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

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

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

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

The technical caveats:

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

AXIS Object Analytics: the engine behind the search

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

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

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

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

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

AXIS Data Insights Dashboard

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

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

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

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

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

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

AXIS License Plate Verifier

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

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

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

Axis Secure Entry: the access control side

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

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

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

What is worth using, what is worth waiting on

Going feature by feature, my current field guidance:

Use today:

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

Test before deploying:

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

Mind the gap:

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

Architectural notes:

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

How ACS Pro stacks against Genetec

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

ACS Pro wins on:

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

Genetec wins on:

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

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

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

Where I land on this one

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

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

[Article] 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.

Where the version stands today

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

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

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

Platform changes that actually matter

Time drift monitoring against the Directory

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

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

Copy configuration tool now requires its own privilege

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

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

CSV report limits

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

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

Debug console disabled by default

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

Permanent alarm muting from Investigate

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

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

Enhanced Network view with proxy and archiver co-location

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

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

Automation enhancements

Delays between response actions

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

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

New contextualised actions

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

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

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

Map designer enhancements

Auto-positioning of georeferenced devices

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

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

Bulk synchronisation of map objects with linked entities

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

Video enhancements

Batch firmware upgrade

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

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

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

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

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

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

AV1 device support

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

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

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

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

Expanded archive viewing limits

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

Archiver role warning toggle

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

Access control enhancements

Improved visitor credential display

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

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

Partitions for temporary access rules

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

What is still on the wishlist

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

Native, structured log streaming to SIEM

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

Finer-grained RBAC

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

Native MFA for local accounts

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

True hybrid parity

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

Web App parity

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

Better SDK documentation

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

Should you upgrade?

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

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

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

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

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

[Article] 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 released on May 12, 2026 and hit Genetec techdocs the following day. The release is real, it is public, the techdocs are live, the installer is downloadable, and the marketing page is up. My phone rang for a fortnight after 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 without fanfare. 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 truly 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 fully 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 changes how administrators manage their systems with little fanfare. 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

For the supported routes themselves, including which versions need a two-step hop through 5.11, see the Security Center migration paths reference.

Timeline updated 23 August 2026. The first cumulative update landed slightly ahead of where I expected it. 5.14.0.1 shipped on 29 June 2026, not in July. The steps below are re-dated against what has actually happened.

Done, May and 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. 5.14.0.1 arrived 29 June and is the first cumulative update.
Now, August and September 2026: this is the evaluation window. Read the Known Issues page against 5.14.0.1, note which issues are resolved and which are deferred, and check whether 5.14.1.0 has shipped for your deployment profile. Test on a non-production system. Verify your federated systems, your SDK integrations, your custom workflows, and your operator training materials.
Q4 2026: if the evaluation is clean, 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.

A .0 platform release is exactly when a pre-upgrade Genetec Health Check earns its keep. It confirms the servers, hardware, and controllers can take 5.14 before you commit a maintenance window. If you would rather hand the planning and the upgrade itself to someone independent, that is independent Genetec consulting.

[Article] 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, checked against the 5.14 guide in August 2026, combined with findings from real system assessments. Run a current, stable, patched release rather than the newest one, current versions contain performance improvements that make some older configuration recommendations obsolete.

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

Power Plan: High Performance

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

Set all Genetec servers to the High Performance power plan:

powercfg /setactive SCHEME_MIN

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

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

NIC Buffer Settings

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

Increase NIC buffers in Device Manager or via PowerShell:

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

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

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

SQL Server Memory Configuration

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

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

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

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

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

Antivirus Exclusions

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

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

``` # Genetec installation directory (default): C:\Program Files (x86)\Genetec Security Center 5.x # Health monitoring cache agent folder (default): C:\ProgramData\Genetec Security Center 5.x\MonitoringCache\Agent # Video archive directories (all drives used for video storage): [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. Many of the symptoms tuning fixes also show up in the 10 most common Genetec Security Center issues.

[Article] 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.

[Article] 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.