# Hans Study — Full Content Corpus

Concatenated plain-text body of every public Article, News item, KB entry,
and book description on hans.study. Companion to /llms.txt (which holds
the URL inventory, entity card, and citation policy).

This file is auto-generated at build time. Source files live in
src/content/blog/ and src/content/kb/ as MDX. To cite a passage, refer
back to the canonical URL listed in the header of each section.

Generated: build-time. Author: Hans Study, CISSP. Canonical site:
https://hans.study/.

================================================================

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

URL: https://hans.study/axis-camera-station-pro-6-14-ai-analytics-search/
Type: article
Date: 2026-05-25
Description: AXIS Camera Station Pro reached version 6.14 in mid-2026, and the AI/analytics/search story is finally cohesive. Smart Search 2 with free text, Object Analytics integration, Data Insights dashboards, License Plate Verifier maturation. A field-level review of what works, what doesn't, and where it fits in a real deployment.

Image courtesy of Axis Communications . Used with attribution. 
 

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

 That changed somewhere between version 6.1 (when Axis Camera Station Pro split from the original ACS lineage) and the current 6.14 release. The product I am evaluating today is fundamentally different from the one I dismissed in 2020. The AI, analytics, and search story is finally cohesive. 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. 

 

 The version landscape 

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

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

 

 Smart Search 2: the feature that changes the conversation 

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

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

 Two search modes: 

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

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

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

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

 The technical caveats: 

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

 

 AXIS Object Analytics: the engine behind the search 

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

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

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

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

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

 

 AXIS Data Insights Dashboard 

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

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

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

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

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

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

 

 AXIS License Plate Verifier 

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

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

 The caveat: License Plate Verifier capabilities depend on the camera. License Plate Verifier kit cameras with OS 12.8 or the License Plate Verifier version 3 ACAP on standalone cameras 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 deeper third-party integration ecosystem. 
 

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

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

 

 Where I land on this one 

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

 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 security controls for CCTV and access control networks for hardening it.

================================================================

## CMMC vs CPCSC: The Practitioner's Comparison

URL: https://hans.study/cmmc-vs-cpcsc-practitioners-comparison/
Type: article
Date: 2026-05-11
Description: A field guide comparing the U.S. Cybersecurity Maturity Model Certification and Canada's CPCSC. Controls, differences, overlap, and how to implement both.

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

 
 // Contents 
 
 The TL;DR comparison 
 Shared lineage: NIST SP 800-171 
 CMMC 2.0, the U.S. side 
 CPCSC, the Canadian side 
 Control counts and families 
 The Rev 2 vs Rev 3 problem 
 Where they diverge 
 Where they intersect 
 Implementing both 
 The combined timeline 
 FAQ 
 
 

 Both programs at a glance 

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

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

 
 // Study Note 
 Both programs gate procurement. If you cannot show certification at the level the contract requires, you do not get the contract. The distinction is no longer aspirational. It is contractual. 
 

 One family tree, two branches 

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

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

 
 // Standards lineage 

 

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

 CMMC 2.0 

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

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

 The three levels 

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

 For the Canadian critical-infrastructure side of the same picture, which is a separate regime with a separate timeline, see Bill C-8 and the CCSPA . 

 The phased rollout 

 
 // Status, updated 23 August 2026 
 Phase 2 is suspended. On 13 July 2026 the Department of War suspended the Phase 2 assessment requirements that were to begin 10 November 2026, and stood up a CMMC Reform Task Force to run a 60-day review. Industry responses closed 14 August 2026. Background on the memo and its scope is covered in WilmerHale's client alert and in DefenseScoop's reporting . 
 Phase 1 is untouched and still applies: DFARS 252.204-7012, NIST SP 800-171 Rev 2, self-assessment, SPRS score posting, and annual affirmation all continue. What is on hold is the third-party C3PAO assessment gate for Level 2, and with the whole programme under review the Phase 3 and Phase 4 dates below should be read as proposed rather than fixed. 
 If you are mid-remediation, keep going. The control set is not what is being reviewed, the assessment mechanism is. Work done against 800-171 Rev 2 holds its value whatever the task force reports. 
 

 The 48 CFR final rule took effect on November 10, 2025. From that date, CMMC requirements began appearing in select DoD contracts. The rollout was written as four phases over three years, and the diagram below shows that original schedule with the current status of each phase marked. 

 
 // CMMC 2.0 phased rollout, as amended July 2026 

 

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

 What CMMC requires beyond NIST 800-171 

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

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

 CPCSC 

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

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

 The three levels 

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

 The phased rollout 

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

 
 // CPCSC rollout 

 

 The cascade effect 

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

 
 // Field standard 
 If you supply software, components, calibration services, engineering, CAD, or IT services to any prime in the Canadian defence supply chain, your CPCSC clock has already started. The prime cannot keep you in their supplier base if you cannot prove the standard. 
 

 The families, side by side 

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

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

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

 The Level 1 subset 

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

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

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

 Rev 2 vs Rev 3, and why it matters 

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

 
 
 CMMC (U.S.) 
 Locked to Rev 2 
 The CMMC final rule explicitly states that NIST SP 800-171 Revision 3 is not currently applicable. DoD issued a class deviation requiring contractors to continue using Rev 2 for DFARS 252.204-7012 compliance. 
 C3PAO assessors are not authorized to evaluate organizations against Rev 3. SPRS scoring runs on Rev 2. Building documentation against Rev 3 risks gaps relative to what assessors actually use. 
 
 
 CPCSC (Canada) 
 Built on Rev 3 
 ITSP.10.171 is the Canadian Centre for Cyber Security's adaptation of NIST SP 800-171 Revision 3. It uses Rev 3's structural changes: 17 families, 97 controls, and Organization-Defined Parameters. 
 That means assessors evaluating CPCSC Level 2 will look for Rev 3 conventions, including ODPs that specify exact values for tunable controls. Rev 2 documentation will not map cleanly. 
 
 

 What changed in Rev 3 

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

 
 // Watch your footing 
 Organizations rushing to "modernize" to Rev 3 to look forward-thinking can fail a C3PAO assessment if their SSP is structured around Rev 3 controls while assessors evaluate against Rev 2. The smart move is to maintain Rev 2 as the master compliance document for CMMC and overlay Rev 3 mappings for CPCSC and future CMMC transition. Two lenses, one program. 
 

 Where they diverge 

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

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

 
 // No reciprocity 
 This bears repeating. A CMMC Level 2 certificate does not satisfy a CPCSC Level 2 requirement. The reverse is also true. The standards are technically close enough that the work overlaps, but certificates are issued by different programs under different authorities with different assessors. Plan for two assessment events if you bid in both markets. 
 

 Where they intersect 

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

 
 // Control overlap (schematic) 

 

 Practical overlap 

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

 
 // The takeaway 
 If your security program is grounded in NIST 800-171 with a proper SSP, POA&M, and evidence binders, you are roughly 80 percent of the way to both certificates. The remaining 20 percent is reconciling Rev 2 vs Rev 3 documentation, mapping to two assessment bodies, and producing two attestations. 
 

 How to implement both 

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

 
 // Dual compliance implementation flow 

 

 Phase 1: Scope 

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

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

 Phase 2: Gap analysis 

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

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

 Phase 3: SSP and policy 

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

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

 Phase 4: Control implementation 

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

 Common implementations that satisfy both programs cleanly: 

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

 Phase 5: Assess and certify 

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

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

 
 // Field standard 
 Pick one compliance program owner inside the organization. Not a team. Not a committee. One person who owns the calendar, the SSP, the evidence repository, and the assessor relationships. The certificates depend on this person being credible to both assessors. Splitting the role across two leads creates seams that assessors find. 
 

 The combined calendar 

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

 
 // Combined CMMC + CPCSC calendar 

 

 
 CMMC Phase 2 On hold Suspended 13 Jul 2026 
 CPCSC L1 in contracts Summer 2026 // At contract award 
 CPCSC L2 in contracts Spring 2027 // Third-party assess 
 Average prep time 6 to 12 Months to assessment-ready 
 

 
 // The narrow window 
 Organizations that wait for the official enforcement date to start preparing are already behind. Average readiness time for a Level 2 assessment is 6 to 12 months. C3PAO and SCC-accredited CB capacity is finite. The bottleneck will be assessor availability, not your willingness to spend. 
 

 Questions that come up 

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

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

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

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

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

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

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

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

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

 The practitioner's read 

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

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

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

 Related guidance 

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

 
 // Hans Study 
 Hans Study supports organizations across both jurisdictions on CMMC and CPCSC readiness, gap analysis, SSP development, and assessor preparation. If you are scoping a dual-compliance program and want a practitioner's read on where you stand, get in touch .

================================================================

## Genetec Security Center: Server Configuration and Performance Tuning

URL: https://hans.study/configuring-and-tuning-genetec-security-center/
Type: article
Date: 2025-11-04
Description: Power plan, NIC buffers, SQL Server memory, antivirus exclusions, video drive configuration, and camera stream settings for Genetec servers.

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 0% 
 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 .

================================================================

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

URL: https://hans.study/genetec-archiver-storage-and-retention-design/
Type: article
Date: 2026-08-31
Description: Retention arithmetic that survives contact with real bitrates, throughput per Archiver and per volume, RAID and drive selection, iSCSI versus SMB, and the failure modes that produce missing video.

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

================================================================

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

URL: https://hans.study/genetec-security-center-5-13-3-release-review/
Type: article
Date: 2026-05-14
Description: Field-level look at Genetec Security Center 5.13.3.0 (May 2026). What changed since 5.13.2.0, which features are worth the upgrade, which are marketing fluff, and the gaps that keep getting punted release after release.

<source srcset="/images/articles/genetec-5-13-3.avif" type="image/avif" />
 <source srcset="/images/articles/genetec-5-13-3.webp" type="image/webp" />
 
 </picture>
 Image courtesy of Genetec . Used with attribution. 
 

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

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

 

 The version landscape 

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

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

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

 

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

 Platform changes that actually matter 

 Time drift monitoring against the Directory 

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

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

 Copy configuration tool now requires its own privilege 

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

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

 CSV report limits 

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

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

 Debug console disabled by default 

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

 Permanent alarm muting from Investigate 

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

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

 Enhanced Network view with proxy and archiver co-location 

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

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

 

 Automation enhancements 

 Delays between response actions 

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

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

 New contextualised actions 

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

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

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

 

 Map designer enhancements 

 Auto-positioning of georeferenced devices 

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

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

 Bulk synchronisation of map objects with linked entities 

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

 

 Video enhancements 

 Batch firmware upgrade 

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

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

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

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

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

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

 AV1 device support 

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

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

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

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

 Expanded archive viewing limits 

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

 Archiver role warning toggle 

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

 

 Access control enhancements 

 Improved visitor credential display 

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

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

 Partitions for temporary access rules 

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

 

 What is still on the wishlist 

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

 Native, structured log streaming to SIEM 

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

 Finer-grained RBAC 

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

 Native MFA for local accounts 

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

 True hybrid parity 

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

 Web App parity 

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

 Better SDK documentation 

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

 

 Should you upgrade? 

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

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

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

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

 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.

================================================================

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

URL: https://hans.study/genetec-security-center-5-14-outlook/
Type: article
Date: 2026-05-13
Description: Security Center 5.14.0.0 released on May 12, 2026. Web App replaces Web Client, custom privilege templates land, the media component goes 64-bit, and HID VertX/Edge gets its retirement notice. What's in the release and why my upgrade clock starts at 30 to 60 days, not day 1.

<source srcset="/images/articles/genetec-5-14.avif" type="image/avif" />
 <source srcset="/images/articles/genetec-5-14.webp" type="image/webp" />
 
 </picture>
 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 quietly. The patch revision (5.14.1.0) ships with the real "production-ready" version of the platform. 

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

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

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

 

 The big platform shifts 

 Web App replaces Web Client, exclusively 

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

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

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

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

 Custom privilege templates 

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

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

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

 Microsoft Entra OAuth for SMTP 

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

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

 Media component now runs 64-bit 

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

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

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

 Time drift alerts between Directory and failover/expansion servers 

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

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

 Retain audit trail when replacing a camera 

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

 

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

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

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

<blockquote> 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. </blockquote>

 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 .

================================================================

## Deploying Active Directory for Genetec Security Center Environments

URL: https://hans.study/genetec-security-center-active-directory-deployment/
Type: article
Date: 2025-09-30
Description: AD prerequisites, OU structure, service accounts, Group Policy, Kerberos configuration, and common pitfalls for Genetec AD integration.

Active Directory Integration, Authentication Flow 
 
 
 Security Desk Operator Workstation 
 Web Client Browser 
 Config Tool Admin Workstation 
 
 
 
 Kerberos / LDAP → 
 
 
 
 Active Directory Domain Controller 
 
 
 
 ← Auth token + group membership 
 
 
 
 Directory Server Security Center 
 
 
 
 Group → Role mapping 
 
 
 
 Archiver · Access Manager Service Accounts via AD 
 
 
 AD handles authentication. Security Center uses group membership to assign roles and access privileges. 
 
 If you are running a multi-server Genetec Security Center deployment without Active Directory, you are making everything harder than it needs to be. I see this regularly. Environments with a dozen servers, multiple client workstations, hundreds of cameras, and all of it managed through local accounts. Passwords shared across systems. No centralized policy enforcement. No reliable audit trail that ties actions to specific users. No time synchronization that you can trust. 
 Local accounts scale poorly. They are maintained inconsistently. When an operator leaves, their access has to be revoked on every system individually. When a password needs to change, it changes on some systems and gets forgotten on others. When something goes wrong and you need to reconstruct who did what, the answer is "someone logged into the shared admin account." 
 Active Directory solves all of that. It also introduces dependencies and configuration requirements that, if missed, cause authentication failures that are difficult to diagnose. This post covers the AD integration for Genetec Security Center environments: what it requires, how to set it up, and what to watch for. AD integration is one of the standard items reviewed during a Genetec Health Check ; broader scope around the Genetec stack lives under Genetec consulting . 
 
 Prerequisites 
 Before integrating Genetec with Active Directory, the following must be in place: 
 Domain membership. The Genetec servers must be domain-joined. This is a prerequisite for Kerberos authentication, which is the preferred authentication method for AD-integrated Genetec environments. Attempting to configure AD authentication without domain-joining the servers will result in fallback to NTLM, which has known weaknesses and should not be relied on in environments where Kerberos is available. 
 Time synchronization. Kerberos authentication requires that the time difference between the Genetec servers and the domain controller is under 5 minutes. In practice, keep it under 2 minutes. A time skew that exceeds the Kerberos tolerance causes authentication failures that are cryptic to diagnose if you do not know to look for them. Configure all Genetec servers to synchronize time from the domain hierarchy. In environments with multiple sites, verify that the time synchronization path goes through the domain hierarchy and not through an independent NTP source that may drift relative to the domain. 
 DNS resolution. The Genetec servers must be able to resolve the fully qualified domain name of the domain controllers. Use the domain's own DNS servers as the primary DNS for Genetec servers. Using external DNS (8.8.8.8, 1.1.1.1) as the primary DNS for domain-joined servers creates intermittent authentication problems when those servers cannot resolve domain resources. 
 Active Directory Users and Computers access. You will need permission to create Organizational Units, security groups, and service accounts in AD. Coordinate with the domain administrator before starting the configuration. 
 
 Organizational Unit Structure 
 Create a dedicated OU for Genetec-related AD objects. This keeps Genetec objects organized, makes Group Policy application easier to scope, and makes it straightforward to identify everything related to the Genetec deployment in a single location. 
 Suggested structure: 
```
OU=Physical Security
 OU=Servers
 [Genetec server computer accounts]
 OU=Workstations
 [Genetec client workstation accounts]
 OU=Service Accounts
 [Genetec service accounts]
 OU=Security Groups
 [Genetec role groups]
```
 Apply Group Policy to the Physical Security OU for settings specific to Genetec servers and workstations. This includes Windows Firewall rules for Genetec ports, exclusion paths for Genetec processes in Windows Defender, and any performance-related OS settings. Keeping these in a dedicated OU means they do not affect general-purpose servers and can be modified without touching broader domain policy. 
 
 Service Accounts 
 Genetec roles communicate with each other and with the directory using service accounts. Create dedicated service accounts for the Genetec environment rather than using the built-in local system account or a shared general-purpose account. 
 Create a service account for each Genetec role that requires one: 
 
 GSC-SVC-DIRECTORY: Account used by the Directory role 
 GSC-SVC-ARCHIVER: Account used by Archiver roles 
 GSC-SVC-ACCESSMGR: Account used by the Access Manager role 
 GSC-SVC-SQL: Account used by SQL Server for the Genetec database 
 
 Configure these accounts with passwords that do not expire (service accounts do not interactively log in, so password expiration causes service failures rather than prompting for a change). Use strong, randomly generated passwords and store them securely. Restrict these accounts to log on only as a service, they should not be usable for interactive login. This is one of the hardening baselines that gets skipped most often in deployments that pass commissioning. 
 If your environment's security policy requires password rotation on service accounts, use Group Managed Service Accounts (gMSA). gMSAs are AD accounts where the password is managed automatically by the domain, removing the operational overhead of manual password rotation. Genetec supports gMSAs on current versions. 
 
 Security Groups and Role Mapping 
 Genetec uses AD security groups to determine role assignment. When an AD user logs into Security Center, their group memberships are read and mapped to Security Center roles that have been linked to those AD groups. 
 Create security groups that correspond to Genetec access levels: 
 
 Group Name Genetec Role Who Gets This 
 
 GSC-Operators Security Desk Operator Monitoring center staff 
 GSC-Supervisors Supervisor / Investigator Team leads, investigators 
 GSC-Administrators System Administrator IT and security admin staff 
 GSC-AccessAdmin Access Control Administrator HR, access control managers 
 GSC-VideoAudit Video Investigator (read-only) Compliance, legal, audit 
 
 
 In the Security Center Configuration Tool, link each security group to the corresponding Security Center role. When an AD user is added to GSC-Operators , they automatically get Operator-level access to Security Center on their next login. When they leave the organization and their AD account is disabled, their Security Center access is immediately revoked as well. 
 
 Group Policy for Genetec Environments 
 Create a Group Policy Object linked to the Physical Security OU with settings specific to Genetec servers and workstations. 
 Windows Defender exclusions. Add exclusions for Genetec processes, the installation directory, the media storage directories, and the database files. Incorrect exclusions are one of the most common causes of Genetec performance problems. Genetec publishes the specific exclusion paths in their best practices documentation, apply them precisely. Do not exclude entire drives or root directories. 
 Windows Firewall rules. Configure inbound rules for the Genetec role ports. The specific ports depend on the roles running on the server and the Genetec version. At minimum: TCP 5500 and 5501 for the Directory, TCP 554 for RTSP streams, and the port ranges for any other roles deployed. Create the firewall rules through Group Policy rather than manually configuring them on each server, this ensures consistency and survives server rebuilds. 
 Power plan. Set the power plan to High Performance for Genetec servers and workstations. The Balanced power plan throttles CPU and GPU performance in ways that degrade both recording and video display. Configure this through Group Policy to ensure it is applied consistently and not overridden by default settings after a Windows update or restart. 
 NTP client configuration. Ensure all servers in the Physical Security OU synchronize time from the domain hierarchy. A GPO preference setting that configures the Windows Time service as a domain client is more reliable than manual configuration and ensures consistency. 
 
 Kerberos Configuration 
 Genetec Security Center supports both Kerberos and LDAP authentication for AD integration. Kerberos is strongly preferred. It is more secure, does not require the Security Center service to bind to the domain controller with a service account, and provides better performance in larger environments. 
 For Kerberos authentication to work correctly with Genetec, the Security Principal Name (SPN) for the Genetec service must be registered in Active Directory. Genetec handles this automatically when the server is properly domain-joined and the service account has the necessary permissions. If authentication is failing in ways that suggest Kerberos ticket issues, verify the SPNs are registered using setspn -L [account-name] . 
 If LDAP is required (for environments where Kerberos cannot be used), configure LDAP over SSL (LDAPS) rather than unencrypted LDAP. Unencrypted LDAP sends credentials in cleartext. LDAPS requires a certificate installed on the domain controller, but it is the only acceptable option for production environments. 
 
 Common Pitfalls 
 Time synchronization drift. This is the most common cause of intermittent AD authentication failures in Genetec environments. The failure mode is that login works most of the time but fails periodically or for specific users. Check the time difference between the Genetec servers and the domain controller immediately whenever AD authentication starts failing intermittently. 
 DNS pointing to external resolver. A Genetec server configured with 8.8.8.8 as its primary DNS cannot reliably resolve domain resources. Kerberos ticket requests go to the domain controller by hostname. If the hostname cannot be resolved, authentication fails. This is especially common in environments where the Genetec servers were set up before the network was finalized and the DNS configuration was not updated. 
 Service account password expiration. If Genetec service accounts have passwords set to expire, the services will fail when the password expires and nobody notices until something stops working. Either set service account passwords to never expire, or use gMSAs, or build a process to rotate them before expiration. Whichever approach you take, document it so the next person who inherits the system knows what to expect. 
 Missing SPNs after server migration. When Genetec servers are migrated to new hardware or new IP addresses, SPNs may need to be re-registered. If AD authentication stops working after a server migration and everything else looks correct, SPN registration is the next thing to check. 
 Insufficient SPN registration rights. The service account needs specific permissions to register SPNs in AD. If the service account does not have those permissions, SPNs are silently not registered and Kerberos authentication fails. Verify with the domain administrator that the service account has the ability to register SPNs for the hostnames and IP addresses of the Genetec servers.

================================================================

## Genetec Security Center: Architecture, Roles, and Workstation Best Practices

URL: https://hans.study/genetec-security-center-architecture-roles-workstations/
Type: article
Date: 2025-08-26
Description: Genetec Security Center server role architecture, sizing guidance, workstation optimization, federation, and common design mistakes.

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. 
 Directory 
 The Directory is the core of Security Center. It hosts the Security Center database (SQL Server), manages licensing, handles authentication and authorization for all users and roles, maintains system configuration, and serves as the communication hub between all other roles. Every role in the system must be able to reach the Directory to function. 
 In a single-server deployment, everything runs on the server running the Directory. In distributed deployments, the Directory server is the one server that absolutely cannot go down without taking the entire system with it. Failover configuration for the Directory is covered in the high-availability section below. 
 The SQL Server instance hosting the Genetec database should be sized appropriately. Insufficient SQL memory is one of the most common performance bottlenecks on Directory servers. SQL will consume as much memory as you allow. On servers where SQL shares resources with Genetec roles, you must configure the SQL Server max memory setting explicitly, or SQL will crowd out the Genetec processes. 
 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.

================================================================

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

URL: https://hans.study/genetec-vs-milestone-vs-avigilon-enterprise-multi-site/
Type: article
Date: 2026-09-04
Description: Where each platform actually wins on multi-site enterprise deployments: unification versus openness versus integration, licensing shape, federation, analytics, hardening posture, the integrator ecosystem in Canada, and a decision table you can argue with.

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 ecosystem, 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 genuinely 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.

================================================================

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

URL: https://hans.study/sql-server-for-genetec-security-center/
Type: article
Date: 2026-08-28
Description: Express versus Standard, max server memory, recovery models, autogrowth, index maintenance, event retention, and the SQL failures that take Security Center down.

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.

================================================================

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

URL: https://hans.study/top-genetec-security-center-issues/
Type: article
Date: 2026-06-01
Description: The ten Genetec Security Center problems I see most often in the field, what they look like under load, and how to fix them. Field-tested, vendor-agnostic.

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

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

 

 1. Under-spec'd or misconfigured servers 

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

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

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

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

 2. Storage designed for capacity, not performance 

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

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

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

 3. Network congestion and streaming mismatches 

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

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

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

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

 4. Ignoring built-in health monitoring 

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

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

 5. Testing changes directly in production 

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

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

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

 6. Cameras left at factory defaults 

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

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

 7. Weak security hardening 

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

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

 8. Misdesigned federation and multi-site architecture 

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

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

 9. Poor upgrade discipline 

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

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

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

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

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

 

 Where to start 

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

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

 Start a conversation →

================================================================

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

URL: https://hans.study/upgrading-to-genetec-security-center-5-14-runbook/
Type: article
Date: 2026-09-02
Description: The upgrade night itself: pre-flight checks, the order roles and clients go in, the Web Client retirement, the 64-bit media component, SDK plugins and federation, the rollback decision, and the first week after.

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.

================================================================

## ALE OmniSwitch 6360 and 6560 Base Configuration for CCTV and Security Networks

URL: https://hans.study/standards-guidance/ale-omniswitch-base-configuration-for-cctv-and-security-networks/
Type: kb
Date: 2026-03-04
Description: Alcatel-Lucent Enterprise OmniSwitch 6360/6560 (AOS 8) configuration template: VLANs, SSH, AAA, Virtual Chassis, port security, BPDU guard, link aggregation, QoS, and syslog for physical security networks.

Alcatel-Lucent OmniSwitch 6360, Front Panel and VLAN Port Allocation 
 

 
 
 CCTV · VLAN 101 (1-12) 
 Access · VLAN 102 (13-16) 
 Systems · VLAN 100 (17-22) 
 Unused · VLAN 666 (23-24) 
 LAG · 1/1/25-1/1/26 
 
 

 Over the last 15+ years, when I get brought in to look at a CCTV or security network, it is almost a guarantee that the network devices are not configured correctly. Or just not configured at all. 

 Switches running factory defaults. No VLANs. No port security. Default credentials on everything. No redundancy between switches. Management interfaces sitting wide open on the same network as cameras. These are systems protecting physical assets, running on networks that nobody thought to protect. 

 Over the years I have built a set of configuration templates that provide initial setup, baseline hardening, and performance tuning for security network switches. This is one of them. It is focused on the Alcatel-Lucent Enterprise OmniSwitch series running AOS Release 8 and covers VLAN segmentation, SSH access, AAA, port security, QoS, trunk hardening, and inter-switch connectivity. 

 This is not a one-size-fits-all configuration. Every environment is different. Review each section against your requirements and test before deploying into production. 

 A note on AOS syntax. AOS Release 8 uses a flat command structure. Commands take effect immediately. There is no commit step. Before making changes that affect management access, save your current configuration with write memory , and have a console connection open. If you lose remote access, the console is your recovery path. 

 Change every placeholder before deploying. The double-hash placeholder ( ## ) appears throughout this template where site-specific values belong. Deploying a configuration with placeholder values intact is a misconfiguration waiting to cause problems. 

 

 Initial System Configuration 

```
system name SWITCH_NAME
user admin password ##CHANGEME## read-write all
session timeout cli 5
```

 system name sets the device identity. Use a consistent naming convention across your environment. This matters for logging, monitoring, and troubleshooting. When you are looking at syslog entries from 40 switches, meaningful hostnames save time. 

 user admin password sets the administrative account password. AOS Release 8 stores passwords as hashed values. Passwords are not stored in plain text in the running configuration. 

 Unlike Cisco IOS, AOS does not have a separate enable password. Access levels are assigned per user account through the read-write all permission set, which grants full administrative access. 

 session timeout cli 5 disconnects idle CLI sessions after 5 minutes. Unattended authenticated sessions are a security risk on any network device. 

 Set a minimum password length and lockout policy: 

```
user password-size min 12
user lockout-threshold 5
user lockout-duration 30
user lockout-window 10
```

 Every device should have unique credentials assigned before going into production. The placeholders in this template are exactly that. 

 

 VLAN Configuration and Segmentation 

```
vlan 1 admin-state enable name DEFAULT
vlan 99 admin-state enable name MANAGEMENT
vlan 100 admin-state enable name SYSTEMS
vlan 101 admin-state enable name CCTV
vlan 102 admin-state enable name ACCESS_CONTROL
vlan 666 admin-state enable name BLACKHOLE
```

 The VLAN IDs and names below are an example, not a standard. Use whatever VLAN scheme the customer already runs, or pick numbers appropriate to the deployment. The principle is what matters: one VLAN per device class, a dedicated management VLAN, a blackhole VLAN for unused ports, and consistency across every site in the same environment. 

 VLAN segmentation is one of the most important things you can do on a security network. By default, every port on a new switch sits in VLAN 1. Everything can talk to everything. That is not acceptable in a security environment. 

 VLAN 1 (DEFAULT): Keep it but do not use it. Default VLAN has well-known behaviors and is the target of certain VLAN-hopping attacks. Do not put production traffic on VLAN 1. 

 VLAN 99 (MANAGEMENT): Dedicated to switch management traffic. Management interfaces should be isolated from camera traffic, user traffic, and everything else. This is where your IP interfaces for device management will live. 

 VLAN 100 (SYSTEMS): For servers, recording platforms, workstations, and other infrastructure that supports the security systems. 

 VLAN 101 (CCTV): Dedicated to cameras. Camera traffic is bandwidth-heavy and predictable. Isolating it simplifies QoS, troubleshooting, and security policy. 

 VLAN 102 (ACCESS_CONTROL): Dedicated to access control panels, controllers, and associated devices. These devices have different traffic patterns and security requirements than cameras. 

 VLAN 666 (BLACKHOLE): The dead-end VLAN. Every unused port gets assigned here. It is not routable and carries no traffic. Its purpose is to ensure that unused ports cannot be used as entry points. 

 The specific VLAN numbers are not magic. Use whatever numbering scheme makes sense for your environment. What matters is that services are separated, and unused ports are isolated. 

 

 Virtual Chassis (Multi-Switch Environments) 

 ALE OmniSwitch supports Virtual Chassis (VC), which combines multiple physical switches into a single logical unit. Virtual Chassis is the preferred approach for co-located switches. 

```
virtual-chassis chassis-id 1 priority 200
virtual-chassis chassis-id 2 priority 100
virtual-chassis admin-state enable
```

 Virtual Chassis creates a single management plane across all member switches. Configuration changes applied to the primary chassis propagate to all members. This simplifies management significantly and reduces the number of independent devices to configure and monitor. 

 AOS does not use VTP for VLAN synchronization. In a Virtual Chassis configuration, VLANs are configured once and automatically synchronized across all members. In standalone multi-switch environments, VLANs must be configured consistently on each switch manually. 

 priority 200 on the primary chassis makes it more likely to be elected as the master. Higher priority values win in ALE's election model, which is the inverse of Cisco's and Juniper's STP priority convention. 

 Virtual Chassis should be configured and validated before the switch goes into production. Adding a switch to a Virtual Chassis after cameras are live requires a maintenance window. 

 

 Stacking vs Link Aggregation (Inter-Switch Connectivity) 

 Before configuring inter-switch connectivity, decide whether your switches will use Virtual Chassis or standalone with link aggregation uplinks. 

 Virtual Chassis 

 Virtual Chassis combines multiple physical switches into a single logical unit managed as one device. It is the preferred approach when switches are co-located in the same rack or closet. 

 Benefits of Virtual Chassis: 

 
 Single management plane across all members 
 Single configuration to manage 
 Redundant control plane 
 Cross-chassis link aggregation support 
 Simplified spanning tree topology 
 

 The tradeoff is that a Virtual Chassis shares a single control plane. A software defect or a bad upgrade can impact all members simultaneously. Plan firmware upgrades carefully, and always have a rollback plan. 

 Standalone Switches with LACP/Link Aggregation 

 When switches cannot use Virtual Chassis, inter-switch links should use LACP link aggregation rather than single links. 

 A single uplink between switches is a single point of failure. If that link goes down, everything behind the downstream switch is disconnected. Link aggregation bundles multiple physical links into a single logical interface. LACP negotiates and manages the bundle dynamically. 

 Benefits include redundancy (if one physical link fails, traffic continues on the remaining links), increased throughput (aggregate bandwidth of all member links), and automatic failover without spanning tree reconvergence. 

 For security networks specifically, this matters because camera systems generate constant, predictable traffic. Losing an inter-switch link means losing visibility from every camera on that switch. Link aggregation reduces that risk significantly. 

 

 Logging and AAA Configuration 

```
swlog output socket 10.254.99.10 level info
swlog output socket 10.254.99.10 facility local7
swlog appid all output socket
swlog appid port-security output socket
swlog appid authentication output socket
swlog appid session output socket
swlog appid configuration output socket
!
aaa authentication default local
aaa authentication console local
aaa accounting session default start-stop "local"
!
session banner /flash/banner.txt
```

 swlog output socket sends syslog to a centralized log server. Local switch logs are finite and get overwritten. A centralized syslog server retains logs for investigation, auditing, and compliance. 

 swlog appid captures specific event categories. Port security, authentication, session, and configuration events are the four categories most important for security network auditing. 

 AAA (Authentication, Authorization, and Accounting) is the framework that controls who can access the device and what they can do. aaa authentication default local uses local accounts for authentication. This is appropriate for smaller environments or as a fallback. 

 For environments with more than a few switches, centralize AAA using RADIUS or TACACS+. This provides centralized credential management, role-based access, and detailed accounting. Local authentication should still exist as a fallback. 

```
aaa radius-server "PRIMARY" host 10.254.99.20 key ##CHANGEME##
aaa server-group "MGMT-RADIUS" server "PRIMARY"
aaa authentication default "MGMT-RADIUS" local
```

 aaa accounting session records session start and stop events. This creates an audit trail of who accessed the device, and for how long. 

 The session banner displays a legal warning before authentication. Create the banner file on flash storage: 

```
vi /flash/banner.txt
```

 Enter your organization's legal warning. In regulated environments and government deployments, this banner is required. Have legal counsel review the text. The specifics matter by jurisdiction. 

 

 Spanning Tree Configuration 

```
spantree mode rstp
spantree priority 4096
```

 Spanning Tree Protocol prevents network loops. Without it, a single cable plugged into the wrong ports can take down an entire VLAN. 

 AOS supports RSTP (Rapid Spanning Tree), MSTP, and legacy STP. RSTP is the correct choice for most security network deployments. When a link fails or recovers, RSTP recalculates the topology in seconds rather than the 30 to 50 seconds that legacy STP requires. In a security environment where camera uptime matters, faster convergence means shorter outage windows during topology changes. 

 spantree priority 4096 sets a lower priority value on this switch, making it more likely to be elected as the root bridge. In a predictable topology, you want to control which switch is root. Lower priority values win. Default is 32768. 

 BPDU Guard should be enabled on all access ports. If a switch or bridge device is connected to a port configured as an access port, BPDU Guard will block that port rather than allowing it to participate in spanning tree. 

```
bridge port-security port 1/1/1 bpduguard enable
bridge port-security port 1/1/1 bpduguard recovery-time 300
```

 The recovery-time 300 setting automatically re-enables a blocked port after 5 minutes following a BPDU Guard event. Adjust based on your operational requirements. 

 

 LLDP 

```
lldp admin-status all tx-and-rx
```

 LLDP (Link Layer Discovery Protocol) allows devices to advertise their identity and capabilities to directly connected neighbors. This is useful in CCTV environments because it helps identify what is connected to each port, including camera model, IP address, and capabilities. 

 Many IP cameras support LLDP and will advertise their information to the switch. This makes inventory and troubleshooting significantly easier. You can see what device is connected to what port without tracing cables. 

 LLDP operates at Layer 2 and does not cross VLAN boundaries. It is informational only and does not affect traffic forwarding. 

 On ports facing untrusted segments, disable LLDP to limit topology disclosure: 

```
no lldp admin-status 1/1/1 tx-and-rx
```

 

 SSH Configuration 

```
no session telnet
ssh server enable
ssh server version 2
no ssh server version 1
ssh server login-max-attempts 3
!
ip access-list MGMT-SSH
 permit ip 10.254.99.0/24 any
 deny ip any any
interface mgmt
 ip access-group MGMT-SSH in
```

 no session telnet disables Telnet. Telnet transmits credentials in plain text. There is no legitimate reason to use Telnet for switch management. 

 ssh server version 2 enforces SSHv2 only. SSHv1 has known vulnerabilities and should never be used. 

 no ssh server version 1 explicitly removes SSHv1 support. Both commands should be applied together. 

 ssh server login-max-attempts 3 limits failed login attempts to 3 before disconnecting the session. This slows down brute force attempts. 

 The access list restricts SSH access to the management network only. Only authorized management stations and monitoring systems should be able to reach the management interface. Any host outside the management subnet is denied. 

 AOS does not have dynamic trunk negotiation equivalent to Cisco's DTP, so there is no corresponding protocol to disable. Trunk configuration is always explicit in AOS. 

 

 Management Interface Configuration 

```
ip interface "mgmt" vlan 99 address 10.254.99.## mask 255.255.255.0
ip default-gateway 10.254.99.1
```

 This creates the in-band management IP interface on the management VLAN. On ALE OmniSwitch platforms with a dedicated management port, use that port for out-of-band management and configure the management IP separately. 

 Management traffic should live on its own VLAN, separate from camera traffic, access control traffic, and user traffic. This ensures that management access to the switch is not competing with production traffic and is not exposed to devices that do not need to reach it. 

 The access list from the SSH section should be applied to this management interface to restrict which hosts can reach it. 

 

 Layer 3 IP Interfaces (Optional, Inter-VLAN Routing) 

```
ip interface "systems" vlan 100 address 10.254.100.## mask 255.255.255.0
ip interface "cctv" vlan 101 address 10.254.101.## mask 255.255.255.0
ip interface "access-control" vlan 102 address 10.254.102.## mask 255.255.255.0
```

 These IP interfaces are only required if you intend to use this switch as a Layer 3 device for routing traffic between VLANs. OmniSwitch supports inter-VLAN routing natively. 

 If your network design uses a dedicated router or firewall for inter-VLAN routing, you do not need these interfaces on the switch. Only the management interface is required for device management. 

 If you do enable inter-VLAN routing, implement ACLs between VLANs to restrict traffic flow. Just because VLANs can route between each other does not mean they should do so without policy. 

 For example, cameras on VLAN 101 need to reach recording servers on VLAN 100, but they should not be able to reach management interfaces on VLAN 99, or access control systems on VLAN 102. 

 For QoS on camera traffic, AOS uses policy maps and traffic classification: 

```
policy condition CCTV-TRAFFIC source ip 10.254.101.0/24
policy action CCTV-PRIORITY priority 6
policy rule CCTV-QOS condition CCTV-TRAFFIC action CCTV-PRIORITY
qos apply
```

 Apply the QoS policy and commit it with qos apply . AOS QoS policy changes are staged and require explicit application. 

 

 Trunk Port and Link Aggregation Configuration 

 Inter-Switch Trunk (Link Aggregation with LACP) 

```
lacp linkagg ## size 2 admin-state enable
lacp linkagg ## actor admin-key ##
lacp linkagg ## actor system-priority 100
!
lacp agg 1/1/51 actor admin-key ##
lacp agg 1/1/52 actor admin-key ##
!
vlan 99-102 802.1q ## "Uplink to SWITCH_NAME"
vlan 666 802.1q ##
```

 lacp linkagg creates a link aggregation group with LACP. The size parameter specifies the maximum number of physical ports in the group. 

 actor admin-key assigns a key value to the aggregation. Ports with matching admin-keys are eligible to join the same aggregation group. This is how AOS binds physical ports to a logical aggregation without per-port channel-group commands. 

 vlan 99-102 802.1q ## assigns the VLANs as tagged members of the aggregation interface. AOS uses this syntax to trunk VLANs over an aggregation link. The ## is the aggregation group number. 

 vlan 666 802.1q ## adds the blackhole VLAN to the trunk as a tagged member. In AOS, the default VLAN for a port is the untagged VLAN. Setting an appropriate default VLAN for the aggregation prevents untagged traffic from reaching VLAN 1. 

 To set the untagged (native) VLAN on the trunk to the blackhole VLAN: 

```
vlan 666 port default ##
```

 This ensures any untagged traffic hitting the trunk goes to the blackhole VLAN rather than VLAN 1. 

 Server Link Aggregation (Access Mode) 

```
lacp linkagg ## size 2 admin-state enable
lacp agg 1/1/10 actor admin-key ##
lacp agg 1/1/11 actor admin-key ##
vlan 100 port default ##
```

 For servers connecting to the switch, a link aggregation can also be configured in access mode on a single VLAN. This provides redundancy and throughput without trunking. 

 vlan 100 port default ## sets the aggregation to forward untagged traffic to the SYSTEMS VLAN. The server NIC teaming configuration must match the LACP settings on the switch side. Mismatched settings are a common cause of connectivity issues. 

 

 Access Port Configuration (Camera Ports) 

```
vlan 101 port default 1/1/1
!
port-security port 1/1/1 admin-state enable
port-security port 1/1/1 max-filtering 1
port-security port 1/1/1 violation shutdown
port-security port 1/1/1 learn-as-static
!
spantree port 1/1/1 admin-edge-port enable
bridge port-security port 1/1/1 bpduguard enable
```

 vlan 101 port default 1/1/1 assigns the port to the CCTV VLAN as the default (untagged) VLAN. Cameras do not need trunk access. 

 spantree port admin-edge-port enable is the AOS equivalent of PortFast. It skips the listening and learning states and brings the port up immediately. This is appropriate for ports connecting to end devices rather than other switches. 

 bpduguard enable shuts the port down if a BPDU is received, preventing unauthorized switches from being connected to camera ports. 

 Port security is critical on camera ports. Cameras do not change. The same camera sits on the same port for years. Port security takes advantage of that predictability. 

 port-security max-filtering 1 allows only one MAC address per port. If a camera is the only thing that should be connected, one is the right number. 

 port-security violation shutdown err-disables the port if a different MAC address is detected. If someone disconnects a camera and plugs in a laptop or another device, the port goes down immediately. This is the correct response in a security environment. 

 port-security learn-as-static converts the learned MAC address to a static entry in the configuration. This is the AOS equivalent of sticky MAC. Once the camera's MAC is learned, it is retained across reboots. 

 When a port enters a disabled state due to a violation, it requires manual intervention to bring it back up. This is intentional. You want to know why a camera port had an unauthorized device connected to it before re-enabling it. 

 

 Unused Port Handling 

```
vlan 666 port default 1/1/45
interfaces 1/1/45 admin-state disable
interfaces 1/1/45 alias UNUSED
```

 Any port not connected to a device should be assigned to the blackhole VLAN and administratively disabled. Unused ports are entry points. Putting them on the blackhole VLAN and disabling them ensures they cannot be used to access any production VLAN. 

 The alias "UNUSED" makes it immediately clear during troubleshooting or auditing which ports are intentionally disabled. 

 When a port is needed in the future, remove it from the blackhole VLAN, assign it to the correct VLAN, apply appropriate port security, and enable it. 

 

 HTTP and NTP Configuration 

```
no http server
no https server
!
ntp server ##.##.##.##
ntp server ##.##.##.## prefer
system timezone EST
```

 no http server and no https server disable the web management interface. If you manage the switch exclusively through SSH and CLI, the web interface is an unnecessary attack surface. Disable it. 

 If web management is required for your environment, use HTTPS only and restrict access to management network addresses using an ACL applied to the management interface. 

 NTP (Network Time Protocol) is critical. Without accurate time, your logs, your camera timestamps, and your access control events cannot be correlated reliably. Time is evidence. If systems are out of sync, the timeline of any investigation becomes unreliable. 

 ntp server prefer designates the preferred NTP source. If multiple NTP servers are configured, the preferred server is used first. Point all switches to a reliable NTP source. If the network is isolated, use a GPS-based NTP server. If the network has controlled internet access, use a trusted public NTP source such as the National Research Council of Canada's NTP service. 

 Every device on the security network should use the same time source. 

 

 What This Template Does Not Cover 

 This is a baseline. It gets you to a reasonable starting point for a CCTV and security network. There are additional configurations that should be considered depending on the environment: 

 
 DHCP snooping and Dynamic ARP Inspection (DAI) for additional Layer 2 security 
 802.1x for network access control beyond port security 
 SNMPv3 configuration for secure monitoring 
 TACACS+ or RADIUS for centralized AAA 
 ACLs between VLANs for traffic policy enforcement 
 DHCP relay configuration if using centralized DHCP 
 Firmware update and lifecycle management 
 Configuration backup and change management 
 

 Each of these deserves its own discussion and should be implemented based on the specific requirements of your environment. 

 

 Final Thoughts 

 A switch out of the box is designed to forward traffic. It is not designed to be secure. Security comes from configuration. 

 The controls in this template are not advanced. They are fundamentals. VLAN segmentation, port security, SSH-only access, AAA, trunk hardening, and NTP. These are the baseline that every CCTV and security network should have before a single camera goes live. 

 If your current network does not have these in place, it is worth a review. The systems protecting your organization deserve a network that is configured with the same level of care.

================================================================

## Antivirus and Defender Exclusions for Video Management Systems

URL: https://hans.study/standards-guidance/antivirus-exclusions-for-video-management-systems/
Type: kb
Date: 2026-08-29
Description: Why real-time scanning breaks video recording, the exclusion lists for Genetec, Milestone, Avigilon, and Axis Camera Station, how to apply them in Defender, and how to prove they took.

Of all the questions I get about video servers, this is the one I get most, and it is the one where the wrong answer does the most damage in both directions. Leave antivirus scanning the archive and the Archiver drops frames, the recording server falls behind, and eventually video is missing when someone needs it. Exclude the whole drive because the vendor told you to and the server that holds the evidence is now the least protected machine on the network. 
 The right answer is narrow, specific exclusions, applied to the paths and processes that actually need them, verified after the fact. This page is that list for the four platforms I see most, and the Defender mechanics for applying it. It applies to any endpoint product; Defender is the worked example because it is what most Windows servers now run. 
 

 Why scanning breaks recording 
 A recording server writes video continuously. The Genetec Archiver writes .g64x files at a steady rate for every camera it owns. Milestone's recording server writes into its media database in blocks. Every one of those writes is a file operation, and real-time protection intercepts file operations. Scanning a large file that changes every few seconds means scanning it over and over, and the scan holds the write until it completes. 
 At small scale the cost hides. At two hundred cameras it is visible as a recording server that cannot keep up with its own cameras, disk queue lengths that never drop, and gaps in the timeline that nobody can explain because the network was fine and the disks were fine. The video files are not executable and are not a plausible malware vector in the format the recorder writes. Scanning them costs a great deal and protects against nothing. 
 The same applies to the database files under the platform: SQL data and log files, the Milestone configuration database, the index files that make the timeline work. They are opened for exclusive write and scanned repeatedly for the same non-benefit. 
 

 The rules before the lists 
 
 Exclude paths and processes, not drives. A drive-level exclusion is a security finding on every audit framework you are likely to face, and it is unnecessary. The recorder writes to specific directories. 
 Prefer process exclusions where the product supports them. Excluding the recording process from scanning means files it writes are not scanned on write, regardless of path. That covers archive volumes that get added later without anyone updating the exclusion list. 
 Extension exclusions are a supplement, not a substitute. They catch video files wherever they land, which matters for exports and archive transfer targets, but they are broad, so keep them to the formats the recorder actually produces. 
 Disable the bundled extras. Network inspection, firewall modules, and "scan on definition update" features in third-party suites interfere with camera traffic and add load. The scanning engine is the part you want; the rest is usually a problem. 
 Keep the exclusions in Group Policy or Intune, not on the server. A local exclusion survives until someone reimages the box. A policy survives. 
 Write them down. The exclusion list is a security decision, and the auditor will ask for it. 
 
 

 Genetec Security Center 
 Genetec publishes its list in the Enterprise Best Practices guide, and the paths below follow it. Adjust for non-default install locations, and add every volume the Archiver writes to. 
```
# Installation
C:\Program Files (x86)\Genetec Security Center 5.14\
C:\ProgramData\Genetec Security Center 5.14\

# Health Monitor cache (the .tik / .xml / .units / .cameras churn lives here)
C:\ProgramData\Genetec Security Center 5.14\HealthMonitoring\

# Every video archive root, on every Archiver
D:\VideoArchive\
E:\VideoArchive\

# SQL Server data, log, TempDB, and backup paths
D:\SQLData\
L:\SQLLog\
T:\TempDB\
B:\SQLBackup\

# Processes
GenetecServer.exe
GenetecWatchdog.exe
sqlservr.exe

# Extensions
.g64 .g64x .gek .mdf .ldf .ndf .bak
```
 On StreamVault appliances the bundled endpoint protection ships with these exclusions already configured. If you replace it with Defender or a corporate suite, every one of them has to be re-created. This is the most common way a StreamVault ends up with an unhappy Archiver six months after a security team "standardised" it. 
 

 Milestone XProtect 
 Milestone's recording server keeps its media database in a directory tree of fixed-size block files, plus the configuration and the log database on the management server. The list Milestone recommends covers the install, the data, and the media database file types. 
```
# Installation and data
C:\Program Files\Milestone\
C:\ProgramData\Milestone\

# Media database roots (every recording server, every storage and archive path)
D:\MediaDatabase\
E:\MediaDatabase\

# SQL Server (management server) data and log paths, as above

# Processes
VideoOS.Recorder.Service.exe
VideoOS.Server.Service.exe
VideoOS.Recorder.Service.Host.exe
sqlservr.exe

# Media database extensions
.blk .idx .pic .pqz .sts .ts
```
 Milestone archives by moving blocks from live storage to archive storage on a schedule. Both roots need excluding, and the archive root is the one that gets forgotten, because it was added after commissioning when the first storage filled up. 
 

 Avigilon Unity (ACC) 
 Avigilon documents exclusions for the server install directory and the configured data volumes. The data volumes are set per server in the ACC Admin Tool, and every one of them needs to be on the list. 
```
# Installation
C:\Program Files\Avigilon\
C:\ProgramData\Avigilon\

# Every configured data volume from ACC Admin Tool
D:\AvigilonData\
E:\AvigilonData\

# Processes
The ACC server service executable under the install directory
```
 Avigilon appliances ship with the exclusions present. The same warning as StreamVault applies: replacing the endpoint product means recreating them, and the appliance will not warn you when they are gone. 
 

 Axis Camera Station 
 Camera Station keeps its configuration and its recording index under ProgramData and writes recordings to whatever storage was configured per camera or per site. 
```
# Installation and data
C:\Program Files\Axis Communications\
C:\ProgramData\Axis Communications\

# Every configured recording location
D:\Recordings\

# Processes
The AXIS Camera Station server service executable under the install directory
```
 

 Applying them in Microsoft Defender 
 Defender takes exclusions as paths, processes, and extensions, and applies them to real-time protection and scheduled scans. Apply them through Group Policy under Windows Components, Microsoft Defender Antivirus, Exclusions , or through Intune, so that they survive a rebuild. For a lab or a one-off, PowerShell does the same thing locally: 
```
Add-MpPreference -ExclusionPath "D:\VideoArchive"
Add-MpPreference -ExclusionPath "C:\ProgramData\Genetec Security Center 5.14"
Add-MpPreference -ExclusionProcess "GenetecServer.exe"
Add-MpPreference -ExclusionProcess "sqlservr.exe"
Add-MpPreference -ExclusionExtension ".g64x"
```
 Two Defender features beyond the scanning engine will stop a recorder cold and neither is an exclusion: 
 
 Controlled Folder Access blocks unrecognised processes from writing to protected folders. If it is on, the recording process must be added as an allowed application, or the archive root must not be a protected folder. Turning it on through a corporate baseline without the allow entry is a reliable way to stop all recording at once. 
 Attack Surface Reduction rules can block the child processes and script activity some platforms use during install and update. Test the baseline in audit mode on a recorder before enforcing it. 
 
 

 Proving they took 
 An exclusion that is in the policy but not on the server is worth nothing, and policy inheritance on a server that was moved between OUs is not something to assume. Check the effective state on the machine: 
```
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess, ExclusionExtension
Get-MpComputerStatus | Select-Object RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
```
 Then check the thing you actually care about. Recording servers expose disk write latency and queue length in Performance Monitor; the platform's own health dashboard shows dropped frames or recording gaps. Take a baseline before the exclusions, apply them, and compare. On a server that was suffering, the disk queue length on the archive volume drops visibly within minutes. 
 Finally, put the exclusion list in the system documentation next to the retention policy and the network diagram. It is part of the design. When the security team next standardises the endpoint fleet, it is the document that keeps the recorder recording.

================================================================

## Aruba CX 6200 and 6300 Base Configuration for CCTV and Security Networks

URL: https://hans.study/standards-guidance/aruba-cx-switch-base-configuration-for-cctv-and-security-networks/
Type: kb
Date: 2026-02-11
Description: Aruba CX 6200/6300 (AOS-CX) configuration template: VLANs, SSH, AAA, VSF, port security, BPDU guard, LACP LAG, QoS, and syslog for physical security networks.

Aruba CX 6300, Front Panel and VLAN Port Allocation 
 

 
 
 CCTV · VLAN 101 (1-12) 
 Access · VLAN 102 (13-16) 
 Systems · VLAN 100 (17-22) 
 Unused · VLAN 666 (23-24) 
 LAG · 1/1/49-1/1/50 
 
 

 Over the last 15+ years, when I get brought in to look at a CCTV or security network, it is almost a guarantee that the network devices are not configured correctly. Or just not configured at all. 

 Switches running factory defaults. No VLANs. No port security. Default credentials on everything. No redundancy between switches. Management interfaces sitting wide open on the same network as cameras. These are systems protecting physical assets, running on networks that nobody thought to protect. 

 Over the years I have built a set of configuration templates that provide initial setup, baseline hardening, and performance tuning for security network switches. This is one of them. It is focused on the HPE Aruba CX series running AOS-CX and covers VLAN segmentation, SSH access, AAA, port security, QoS, trunk hardening, and inter-switch connectivity. 

 This is not a one-size-fits-all configuration. Every environment is different. Review each section against your requirements and test before deploying into production. 

 Change every placeholder before deploying. The double-hash placeholder ( ## ) appears throughout this template where site-specific values belong. Deploying a configuration with placeholder values intact is a misconfiguration waiting to cause problems. 

 

 Initial System Configuration 

```
configure terminal
hostname SWITCH_NAME
user netadmin group administrators password ciphertext ##CHANGEME##
```

 hostname sets the device identity. Use a consistent naming convention across your environment. This matters for logging, monitoring, and troubleshooting. When you are looking at syslog entries from 40 switches, meaningful hostnames save time. 

 AOS-CX stores all local passwords using SHA-256 hashing by default. There is no equivalent to Cisco's service password-encryption because passwords are never stored in plain text in AOS-CX. This is the correct approach. Credentials defined with password ciphertext are stored as hashed values in the configuration file. 

 Unlike Cisco IOS, AOS-CX uses a role-based model with predefined groups. The administrators group provides full administrative access. Create individual named accounts rather than sharing credentials. Every person who manages the switch should have their own account. 

 

 VLAN Configuration and Segmentation 

```
vlan 1
 name DEFAULT
vlan 99
 name MANAGEMENT
vlan 100
 name SYSTEMS
vlan 101
 name CCTV
vlan 102
 name ACCESS_CONTROL
vlan 666
 name BLACKHOLE
```

 The VLAN IDs and names below are an example, not a standard. Use whatever VLAN scheme the customer already runs, or pick numbers appropriate to the deployment. The principle is what matters: one VLAN per device class, a dedicated management VLAN, a blackhole VLAN for unused ports, and consistency across every site in the same environment. 

 VLAN segmentation is one of the most important things you can do on a security network. By default, every port on a new switch sits in VLAN 1. Everything can talk to everything. That is not acceptable in a security environment. 

 VLAN 1 (DEFAULT): Keep it but do not use it. Default VLAN has well-known behaviors and is the target of certain VLAN-hopping attacks. Do not put production traffic on VLAN 1. 

 VLAN 99 (MANAGEMENT): Dedicated to switch management traffic. Management interfaces should be isolated from camera traffic, user traffic, and everything else. This is where your SVIs for device management will live. 

 VLAN 100 (SYSTEMS): For servers, recording platforms, workstations, and other infrastructure that supports the security systems. 

 VLAN 101 (CCTV): Dedicated to cameras. Camera traffic is bandwidth-heavy and predictable. Isolating it simplifies QoS, troubleshooting, and security policy. 

 VLAN 102 (ACCESS_CONTROL): Dedicated to access control panels, controllers, and associated devices. These devices have different traffic patterns and security requirements than cameras. 

 VLAN 666 (BLACKHOLE): The dead-end VLAN. Every unused port gets assigned here. It is not routable and carries no traffic. Its purpose is to ensure that unused ports cannot be used as entry points. It can also be configured with monitoring to detect unauthorized devices attempting to connect. 

 The specific VLAN numbers are not magic. Use whatever numbering scheme makes sense for your environment. What matters is that services are separated, and unused ports are isolated. 

 

 VSF (Multi-Switch Environments) 

 If your environment has multiple switches, Aruba's Virtual Switching Framework (VSF) is the equivalent of Cisco's stacking. VSF combines multiple physical CX switches into a single logical unit. 

```
vsf member 1
 type JL658A
 link 1 lag 256
vsf member 2
 type JL658A
 link 1 lag 256
```

 VSF creates a single management plane across all member switches. Configuration changes applied to the VSF stack apply to all members. This simplifies management significantly and reduces the number of independent devices to configure and monitor. 

 AOS-CX does not use VTP for VLAN synchronization the way Cisco IOS does. In a VSF stack, VLANs are configured once and automatically synchronized across all members. In standalone multi-switch environments, VLANs must be configured consistently on each switch. 

 If VSF is not in use and you are managing standalone switches, document your VLAN configuration carefully and apply it consistently. A VLAN that exists on one switch but not on a connected trunk partner will cause connectivity failures that can be difficult to trace. 

 VSF should be configured and validated before the switch goes into production. Adding a switch to a VSF stack after cameras are live requires planning. 

 

 Stacking vs LAG (Inter-Switch Connectivity) 

 Before configuring inter-switch connectivity, decide whether your switches will use VSF or standalone with LAG uplinks. 

 VSF Stacking 

 VSF combines multiple physical switches into a single logical unit managed as one device. It is the preferred approach when switches are co-located in the same rack or closet, and the cabling infrastructure supports it. 

 Benefits of VSF: 

 
 Single management plane across all members 
 Single configuration to manage 
 Redundant control plane 
 Cross-stack LAG support 
 Simplified spanning tree topology 
 

 The tradeoff is that a VSF stack shares a single control plane. A software defect or a bad upgrade can impact all members simultaneously. Plan firmware upgrades carefully, and always have a rollback plan. 

 Standalone Switches with LACP/LAG 

 When switches cannot use VSF (different locations, different models, or design preference), inter-switch links should use LACP LAG rather than single links. 

 A single uplink between switches is a single point of failure. If that link goes down, everything behind the downstream switch is disconnected. LAG bundles multiple physical links into a single logical interface. LACP negotiates and manages the bundle dynamically. 

 Benefits include redundancy (if one physical link fails, traffic continues on the remaining links), increased throughput (aggregate bandwidth of all member links), and automatic failover without spanning tree reconvergence. 

 For security networks specifically, this matters because camera systems generate constant, predictable traffic. Losing an inter-switch link means losing visibility from every camera on that switch. LAG reduces that risk significantly. 

 Always use LACP ( mode active ) rather than static LAG. LACP detects link failures and misconfigurations that static bundles cannot. 

 

 Logging and AAA Configuration 

```
logging facility local7
logging severity informational
logging host 10.254.99.10

login authentication default local
aaa authentication login default local

banner motd "Unauthorized Access Prohibited"

event-handler CONFIG_LOG
 trigger post-provision
 action cli show running-config
```

 logging host sends syslog to a centralized log server. Local switch logs are finite and get overwritten. A centralized syslog server retains logs for investigation, auditing, and compliance. 

 logging severity informational captures authentication events, configuration changes, interface state changes, and other operationally significant events without flooding the log with debug noise. 

 AAA (Authentication, Authorization, and Accounting) is the framework that controls who can access the device and what they can do. aaa authentication login default local sets the default authentication method to local accounts. This is appropriate for smaller environments or as a fallback. 

 For environments with more than a few switches, centralize AAA using RADIUS or TACACS+ tied into Active Directory. This provides centralized credential management, role-based access, and detailed accounting. Local authentication should still exist as a fallback in case the AAA server is unreachable. 

 The banner motd sets a legal warning that displays before authentication. In regulated environments and government deployments, this banner is required. Have legal counsel review the text. The specifics matter by jurisdiction. 

 AOS-CX logs configuration changes through the event subsystem. The configuration log captures what changed and when, which is essential for troubleshooting and for answering the question "who changed what and when" after something breaks. 

 

 Spanning Tree Configuration 

```
spanning-tree mode rapid-pvst
spanning-tree priority 4096
```

 Spanning Tree Protocol prevents network loops. Without it, a single cable plugged into the wrong ports can take down an entire VLAN. 

 AOS-CX supports MSTP, RPVST+, and RSTP. For environments with multiple VLANs on shared infrastructure, Rapid Per-VLAN Spanning Tree (rapid-pvst) provides per-VLAN topology control with fast convergence. When a link fails or recovers, rapid-pvst recalculates the topology in seconds rather than the 30 to 50 seconds that legacy STP requires. In a security environment where camera uptime matters, faster convergence means shorter outage windows during topology changes. 

 spanning-tree priority 4096 sets a lower priority value on this switch, making it more likely to be elected as the root bridge. In a predictable topology, you want to control which switch is root. Lower priority values win. Default is 32768. 

 BPDU Guard should be enabled on all access ports. If a switch or bridge device is connected to a port configured as an access port, BPDU Guard will err-disable that port rather than allowing it to participate in spanning tree. This prevents accidental loops from unauthorized switches. 

```
interface 1/1/1
 spanning-tree bpdu-guard
 spanning-tree port-type admin-edge
```

 

 LLDP 

```
lldp run
```

 LLDP (Link Layer Discovery Protocol) allows devices to advertise their identity and capabilities to directly connected neighbors. This is useful in CCTV environments because it helps identify what is connected to each port, including camera model, IP address, and capabilities. 

 Many IP cameras support LLDP and will advertise their information to the switch. This makes inventory and troubleshooting significantly easier. You can see what device is connected to what port without tracing cables. 

 LLDP operates at Layer 2 and does not cross VLAN boundaries. It is informational only and does not affect traffic forwarding. 

 On AOS-CX, LLDP can be selectively disabled per interface on ports facing untrusted segments while remaining enabled on management and uplink ports. On access ports connecting to public or untrusted networks, consider disabling LLDP transmission to limit topology disclosure: 

```
interface 1/1/1
 no lldp transmit
 no lldp receive
```

 

 SSH Configuration 

```
ssh server vrf mgmt
no ssh server vrf default
!
line vty
 session-timeout 5
 login authentication default
```

 AOS-CX enables SSH by default but defaults to accepting connections on all VRFs. Restricting SSH to the management VRF isolates remote management to the dedicated management interface. 

 no ssh server vrf default removes SSH access from the default routing VRF, preventing SSH connections from reaching the switch through production VLANs. Management access should only be possible through the management plane, not through camera or access control VLANs. 

 session-timeout 5 disconnects idle VTY sessions after 5 minutes. An authenticated, idle management session is an open window. 

 AOS-CX enforces SSHv2 by default. There is no need to explicitly disable SSHv1 as it is not supported. Telnet is disabled by default and should never be enabled on a production switch. 

 To restrict SSH access to specific management workstations, apply an access control list to the management interface: 

```
ip access-list MGMT-ACCESS
 10 permit tcp 10.254.99.0/24 any eq 22
 20 deny tcp any any eq 22 log
 exit
interface mgmt
 ip access-group MGMT-ACCESS in
```

 

 Management Interface Configuration 

```
interface mgmt
 ip address 10.254.99.## /24
 default-gateway 10.254.99.1
 description Management Network
 no shutdown
```

 AOS-CX switches have a dedicated out-of-band management port ( interface mgmt ) that is separate from the data plane. This is the preferred management interface. Traffic on this interface uses the management VRF and does not mix with production traffic. 

 Management traffic should live on its own VLAN and interface, separate from camera traffic, access control traffic, and user traffic. This ensures that management access to the switch is not competing with production traffic and is not exposed to devices that do not need to reach it. 

 Where out-of-band management is not possible, use an in-band management SVI on VLAN 99 and restrict access with ACLs as shown in the SSH section above. 

 

 Layer 3 SVIs (Optional, Inter-VLAN Routing) 

```
interface vlan 100
 ip address 10.254.100.## /24
 description System Network
 no shutdown
interface vlan 101
 ip address 10.254.101.## /24
 description CCTV Network
 no shutdown
interface vlan 102
 ip address 10.254.102.## /24
 description Access Control Network
 no shutdown
```

 These SVIs are only required if you intend to use this switch as a Layer 3 device for routing traffic between VLANs. Aruba CX switches support inter-VLAN routing natively on platforms with the IP routing license. 

 If your network design uses a dedicated router or firewall for inter-VLAN routing, you do not need these SVIs on the switch. Only the management interface is required for device management. 

 If you do enable inter-VLAN routing on the switch, implement access control lists between VLANs to restrict traffic flow. Just because VLANs can route between each other does not mean they should do so without policy. 

 For example, cameras on VLAN 101 need to reach recording servers on VLAN 100, but they should not be able to reach management interfaces, or access control systems on VLAN 102. 

 AOS-CX does not have a direct equivalent of Cisco's auto qos video ip-camera command. QoS for camera traffic is configured through policy maps applied at the interface level: 

```
qos trust dscp
qos dscp-map 46 name VOICE_VIDEO local-priority 7
```

 Apply QoS policy at the interface level for camera-facing ports where latency and jitter sensitivity require prioritization. 

 

 Trunk Port and LAG Configuration 

 Inter-Switch Trunk (LAG with LACP) 

```
interface lag ##
 description Uplink to SWITCH_NAME
 no shutdown
 no routing
 vlan trunk native 666
 vlan trunk allowed 99-102,666
 lacp mode active
 lacp timeout short
!
interface 1/1/51
 no shutdown
 no routing
 lag ##
!
interface 1/1/52
 no shutdown
 no routing
 lag ##
```

 This configures a LAG using LACP between two switches using 10-gigabit or 25-gigabit uplinks. 

 vlan trunk native 666 sets the native VLAN to the blackhole VLAN. The native VLAN carries untagged traffic. By setting it to an unused VLAN, any untagged traffic hitting this trunk goes nowhere. This is a security measure against VLAN hopping attacks that exploit the default native VLAN (VLAN 1). 

 vlan trunk allowed 99-102,666 explicitly limits which VLANs are permitted on the trunk. Never leave the allowed VLAN list open. Only permit the VLANs that need to traverse this link. 

 lacp mode active configures both sides to actively negotiate the LAG. Both switches should be set to active. LACP will negotiate the bundle and detect any link or configuration mismatches. 

 lacp timeout short reduces the LACP keepalive interval from 30 seconds to 1 second. Failed links are detected and removed from the bundle much faster, reducing the traffic loss window during a link failure. 

 AOS-CX does not have a DTP equivalent. Dynamic trunk negotiation is not a feature of AOS-CX, so there is no need to explicitly disable it. Trunk mode is configured intentionally. This is the correct behavior. 

 Server LAG (Access Mode) 

```
interface lag ##
 description Recording Server
 no shutdown
 no routing
 vlan access 100
 lacp mode active
```

 For servers connecting to the switch, a LAG can also be configured in access mode on a single VLAN. This provides redundancy and throughput without trunking. If the server is using NIC teaming or LACP bonding, the switch-side LAG configuration must match. Mismatched LACP settings between the server and switch are a common cause of connectivity issues. 

 

 Access Port Configuration (Camera Ports) 

```
interface 1/1/1
 description Camera Port
 no shutdown
 no routing
 vlan access 101
 spanning-tree port-type admin-edge
 spanning-tree bpdu-guard
 port-security
 port-security maximum 1
 port-security violation shutdown
 port-security mac-address sticky
```

 This is where the cameras connect. Every camera port is configured with the same baseline settings. 

 vlan access 101 assigns the port to the CCTV VLAN. Cameras do not need trunk access. 

 spanning-tree port-type admin-edge is the AOS-CX equivalent of Cisco's PortFast. It skips the listening and learning states and brings the port up immediately. This is appropriate for ports connecting to end devices rather than other switches. 

 spanning-tree bpdu-guard shuts the port down if a BPDU is received, preventing unauthorized switches from being connected to camera ports. 

 Port security is critical on camera ports. Cameras do not change. The same camera sits on the same port for years. Port security takes advantage of that predictability. 

 port-security mac-address sticky learns the MAC address of the connected camera and locks it to that port. Once the MAC is learned, it is retained in the configuration. 

 port-security maximum 1 allows only one MAC address per port. If a camera is the only thing that should be connected, one is the right number. 

 port-security violation shutdown err-disables the port if a different MAC address is detected. If someone disconnects a camera and plugs in a laptop or another device, the port goes down immediately. This is the correct response in a security environment. 

 When a port enters err-disabled state due to a violation, it requires manual intervention to bring it back up. This is intentional. You want to know why a camera port had an unauthorized device connected to it before re-enabling it. 

 

 Unused Port Handling 

```
interface 1/1/45
 description UNUSED
 no routing
 vlan access 666
 shutdown
```

 Any port not connected to a device should be assigned to the blackhole VLAN and shut down. Unused ports are entry points. Putting them on the blackhole VLAN and shutting them down ensures they cannot be used to access any production VLAN. 

 The description "UNUSED" makes it immediately clear during troubleshooting or auditing which ports are intentionally disabled. 

 When a port is needed in the future, remove it from the blackhole VLAN, assign it to the correct VLAN, apply appropriate port security, and bring it up. 

 

 HTTP and NTP Configuration 

```
no ip http server
ip https-server vrf mgmt
!
ntp server ##.##.##.## version 4
ntp vrf mgmt
```

 no ip http server disables the unencrypted HTTP management interface. If you use the web interface for management, HTTPS only. If you manage the switch exclusively through SSH, disable the HTTPS server as well to reduce the attack surface. 

 AOS-CX's web management interface is limited compared to CLI and is not required in most environments. Disabling it removes an unnecessary service. 

 NTP (Network Time Protocol) is critical. Without accurate time, your logs, your camera timestamps, and your access control events cannot be correlated reliably. Time is evidence. If systems are out of sync, the timeline of any investigation becomes unreliable. 

 ntp vrf mgmt restricts NTP to the management VRF, keeping time synchronization traffic on the management plane rather than mixing it with production traffic. 

 Point all switches to a reliable NTP source. If the network is isolated, use a GPS-based NTP server. If the network has controlled internet access, use a trusted public NTP source such as the National Research Council of Canada's NTP service. Every device on the security network should use the same time source. 

 

 What This Template Does Not Cover 

 This is a baseline. It gets you to a reasonable starting point for a CCTV and security network. There are additional configurations that should be considered depending on the environment: 

 
 DHCP snooping and Dynamic ARP Inspection (DAI) for additional Layer 2 security 
 802.1x for network access control beyond port security 
 SNMPv3 configuration for secure monitoring 
 TACACS+ or RADIUS for centralized AAA 
 ACLs between VLANs for traffic policy enforcement 
 DHCP relay configuration if using centralized DHCP 
 Firmware update and lifecycle management 
 Configuration backup and change management 
 

 Each of these deserves its own discussion and should be implemented based on the specific requirements of your environment. 

 

 Final Thoughts 

 A switch out of the box is designed to forward traffic. It is not designed to be secure. Security comes from configuration. 

 The controls in this template are not advanced. They are fundamentals. VLAN segmentation, port security, SSH-only access, AAA, trunk hardening, and NTP. These are the baseline that every CCTV and security network should have before a single camera goes live. 

 If your current network does not have these in place, it is worth a review. The systems protecting your organization deserve a network that is configured with the same level of care.

================================================================

## Building a Network for CCTV and Access Control

URL: https://hans.study/standards-guidance/building-a-cctv-network/
Type: kb
Date: 2025-01-23
Description: Most physical security deployments I walk into are not engineered. They are assembled. Somebody ran cable, somebody plugged in cameras, somebody configured...

Most physical security deployments I walk into are not engineered. They are assembled. Somebody ran cable, somebody plugged in cameras, somebody configured the NVR, and at some point it started recording. The fact that it works is treated as evidence that it was done correctly. 

 The difference between assembled and engineered shows up later. When the client wants to add cameras. When something fails and troubleshooting takes three days instead of three hours. When a vendor remotely accessing the system gets onto a network that has no business being accessible from the outside. When the camera count doubles because of an expansion and the existing switches cannot handle the load. 

 This post covers how to approach a physical security network from the start. Not just which cables to run and which switches to buy, but how to think about the design so that the system you commission is the same one that performs well in two or three years. 

 

 Physical Layer First 

 The physical layer is where a lot of projects quietly go wrong. Problems in the physical layer surface slowly. A cable with a marginal connection will often work at installation and start dropping frames months later when the termination degrades. An undersized conduit gets filled at commissioning and becomes a problem when the client wants to add cameras during an expansion. 

 Cable selection 

 For standard IP cameras, Cat6A is the right choice. Not Cat5e, not Cat6. Cat6A. The reasons are straightforward. Cat6A is rated for 10Gbps up to 100 metres and handles PoE better than Cat6. The tighter specifications reduce crosstalk and noise, which matters in environments with long cable runs, high camera densities, or significant electrical interference. The price difference over the project is minimal. The performance difference when the environment is not ideal is not. 

 Run conduit where you can. Cameras get moved. Systems get expanded. A camera that was adequate two years ago gets replaced by one with four times the resolution. Pulling new cable through an occupied building with no conduit is expensive and disruptive. Pull conduit during construction and save that cost and disruption later. 

 For inter-switch links, run fibre where the distance exceeds the 100-metre copper limit or where runs pass through areas with significant electrical interference. Industrial environments, mechanical rooms, and areas near heavy equipment are candidates. Fibre also provides galvanic isolation between buildings, which eliminates ground loop issues. 

 PoE budgets 

 Every camera that draws power over Ethernet adds to the PoE budget requirement on that switch. Add them up. A switch with a 370W total PoE budget and 24 ports does not mean you have 370W on each port. It means you have 370W to split across all active PoE ports. 

 
 15.4W 802.3af max Standard PoE 
 30W 802.3at max PoE Plus 
 60W 802.3bt Type 3 PoE++ 
 90W 802.3bt Type 4 PoE++ max 
 

 Most fixed IP cameras draw between 5 and 12 watts. PTZ cameras draw 20 to 30 watts. Cameras with built-in heaters or specialty features can draw more. Get the specifications for the equipment you are installing and calculate the actual draw before specifying the switch. A 24-port switch with a 15W PTZ camera on each port needs 360W of PoE capacity, which most mid-range 24-port PoE switches cannot deliver simultaneously. 

 
 16 × fixed cameras @ 8W each 128W 
 4 × PTZ cameras @ 25W each 100W 
 4 × access control panels @ 10W each 40W 
 2 × intercoms @ 7W each 14W 
 Minimum PoE budget required 282W 
 

 That is before adding any spare capacity for expansion. Specify switches with at least 20 to 30 percent headroom above the calculated load. Switches running at their maximum PoE budget throttle power, which causes cameras to power cycle at unpredictable times and generates the kind of intermittent problem that is extremely frustrating to track down. 

 

 Bandwidth Planning 

 Cameras are the largest bandwidth consumer on a physical security network. The amount of bandwidth each camera generates depends on resolution, frame rate, codec, and scene complexity. The numbers below are representative estimates for typical scenes. 

 
 
 
 Resolution 
 Megapixels 
 H.264 (Mbps) 
 H.265 (Mbps) 
 Notes 
 
 
 
 
 1080p 
 2MP 
 4, 6 
 2, 3 
 Standard indoor fixed camera 
 
 
 4MP 
 4MP 
 6, 8 
 3, 4 
 High-detail indoor or entrance 
 
 
 5MP 
 5MP 
 8, 12 
 4, 6 
 Wide-area outdoor coverage 
 
 
 4K / 8MP 
 8MP 
 15, 25 
 8, 12 
 Forensic or licence plate capture 
 
 
 PTZ 
 Varies 
 8, 20 
 4, 10 
 Depends on configuration and scene 
 
 
 

 H.265 (HEVC) typically cuts bandwidth in half compared to H.264 for equivalent quality. If your VMS and cameras both support H.265, use it. The bandwidth savings add up quickly on a 50 or 100-camera deployment. 

 Calculate total bandwidth for the camera VLAN by adding up the maximum expected bitrate for each camera. Add 30 percent overhead. That is your minimum camera VLAN capacity. The uplink from the camera switch to the rest of the network needs to handle that total, plus whatever management traffic traverses it. 

 

 The Network Architecture 

 Before the detail, the shape. A segmented security network is four planes stacked on each other,
 and every path from a camera to an operator crosses all four in order. Draw it flat and that
 ordering disappears. Draw it in projection and it is the first thing you see. 

 
 The Four Planes 
 
 
 
 

 
 Physical Security Network, Layered Architecture 

 
 
 
 Each layer is isolated by VLAN. The firewall enforces what can cross between segments. Camera traffic stays in VLAN 101. 
 
 

 The diagram above shows the architecture that most mid-sized physical security deployments should target. Internet access terminates at a firewall, which provides the perimeter and handles routing between VLANs. The core switch connects to the firewall via a trunk carrying all production VLANs. Access layer switches connect downstream to the core and have cameras, access control panels, and other field devices on access ports in their respective VLANs. 

 This is not a complicated design. Every component in it is standard. What makes it work is that it is planned before the first cable goes in the wall. 

 

 Switch Selection and Placement 

 The switch selection conversation usually starts with port count and ends with price. There is a third item that matters as much as both of those: PoE budget. Calculate your PoE requirement before you specify the switch. This was covered in the physical layer section above, but it is worth repeating: more projects have PoE problems than port-count problems. 

 Managed switches only. An unmanaged switch has no VLAN support, no port security, no QoS, no logging, and no ability to restrict what connects to it. In a physical security context, unmanaged switches on the camera network are a liability. They are also not significantly cheaper than entry-level managed switches on a per-port basis. Specify managed switches throughout. 

 Placement matters for PoE efficiency. PoE runs on the cable between the switch and the camera. The longer the cable run, the more power is lost to resistance. Keep switch closets or IDF rooms positioned so that most camera runs are under 60 metres. Runs approaching 100 metres will see meaningful voltage drop on the PoE circuit. On longer runs, check the camera's minimum operating voltage and confirm it is within spec at the end of the cable. 

 Uplinks need to handle aggregated camera traffic. A 24-port access switch with 24 cameras generating 6 Mbps each has 144 Mbps of camera traffic going up the uplink. A single 1Gbps uplink handles that comfortably. A 48-port switch fully loaded with 5MP cameras generating 10 Mbps each has 480 Mbps going upstream. In that scenario, a 2-port 1Gbps LACP uplink or a 10Gbps uplink is appropriate. 

 

 Firewall and Remote Access 

 Every physical security network that has any external access needs a firewall. This is not optional. 

 Remote access for the VMS and for system management should go through a VPN. Not an open RDP port. Not a camera exposed directly to the internet with a port forward. A VPN with MFA. The integrator accounts should exist only when access is needed and be disabled when it is not. 

 
 Port forwards to cameras and VMS servers are a significant security risk. Every exposed port is a potential attack surface. Camera firmware vulnerabilities are real and discovered regularly. If you are maintaining installations with direct camera access via port forwarding, it is worth having that conversation with the client. 
 

 The firewall inter-VLAN policy for a security network should be explicit rather than permissive. The default stance is deny. You then add specific permit rules for the communication that needs to happen. Cameras need to reach the VMS server on specific ports. The VMS server needs to be able to query cameras on specific ports. Operators on the SYSTEMS VLAN need to reach the access control server on the ports the access control software uses. Everything else is denied. 

 Document the firewall policy as part of the project. What is allowed, from where, to where, on which ports. That document is the reference when something stops working and you need to figure out whether it is a firewall rule, a VLAN problem, or something else. 

 

 Documentation as Infrastructure 

 The network documentation for a physical security deployment should include: 

 
 IP address map , every device, its address, its MAC, its physical location, its switch port 
 VLAN assignment table , which VLAN each device is in and why 
 Switch port map , which device is on which port of which switch, with port configuration notes 
 Trunk diagram , which VLANs traverse which uplinks 
 Firewall policy summary , what is permitted between VLANs 
 Credentials inventory , what accounts exist, where, with a rotation schedule 
 PoE budget worksheet , actual measured draw per switch vs rated budget 
 

 This documentation does not need to be elaborate. A well-organized spreadsheet and a network diagram cover most of it. What matters is that it exists, that it is accurate at commissioning, and that there is a process for keeping it current when changes are made. 

 I have worked on remediation projects where the documentation for a 200-camera deployment was a photograph of a whiteboard that was taken before the install and never updated. The system had changed significantly in the three years since commissioning. Troubleshooting took days longer than it should have because nobody knew what was at most of the addresses. 

 

 Common Deployment Mistakes 

 Flat network as a cost-saving measure. The conversation usually goes: "We'll add segmentation later." Later becomes never, because re-segmenting a live deployment is more work than doing it at commissioning and requires a maintenance window on a production system. 

 Undersized PoE budget. A switch with 48 PoE ports and a 370W PoE budget seems like it has room for 48 cameras. At 8W each, 48 cameras draw 384W. The switch will throttle power. Cameras will restart unpredictably. The troubleshooting path to "undersized PoE budget" is longer than it should be the first time you encounter it. 

 Cameras on the corporate network. Cameras on the same flat network as user workstations, printers, and guest Wi-Fi. This is more common than it should be. It provides zero lateral movement protection if something on the user network is compromised. 

 No firewall on VPN access. A VPN concentrator that terminates VPN connections directly into the camera VLAN, with no firewall between the VPN exit and the production network. Everything the VPN user can reach from their laptop, they can reach after connecting. That is not a VPN policy. That is full network access. 

 Default credentials left in place. Every camera and switch that ships with default credentials and is never changed is an open door. This is covered in depth in the security controls post, but it belongs on any list of common deployment mistakes because it remains pervasive. 

 No spare capacity. Switches specified for exact port count with no room for expansion. PoE budgets specified to within 5% of load with no headroom. Uplinks sized for current traffic with nothing left for growth. Every system expands. Specify for where the system will be, not just where it is. 

 

 Putting It Together 

 A well-designed physical security network is not complicated. It is a managed infrastructure with logical segmentation, appropriate switch capacity, a clear firewall policy, and accurate documentation. The design decisions that matter most are made before the first cable goes in: the VLAN scheme, the IP addressing plan, the PoE budget calculation, and the uplink sizing. 

 The previous two posts in this series, IP Addressing for Security Integrators and VLAN Segmentation for Physical Security Networks , cover the addressing and segmentation decisions in more detail. Read those before sitting down to design the network for a new project. 

 If you have a specific deployment you want to think through or questions about any part of the design process, reach out through the site.

================================================================

## Cisco Catalyst 9200 and 9300 Base Configuration for CCTV and Security Networks

URL: https://hans.study/standards-guidance/cisco-catalyst-9200-and-9300-series-base-configuration-template-for-cctv-and-security-networks/
Type: kb
Date: 2026-01-14
Description: Complete Cisco Catalyst 9200/9300 configuration template: VLANs, SSH, AAA, port security, DHCP snooping, DAI, QoS, and syslog for physical security networks.

Cisco Catalyst 9200, Front Panel and VLAN Port Allocation 
 

 
 
 CCTV · VLAN 101 (1-12) 
 Access · VLAN 102 (13-16) 
 Systems · VLAN 100 (17-22) 
 Unused · VLAN 666 (23-24) 
 LAG · Te1/1/1-Te1/1/2 
 
 
 This template is designed as a starting point for configuring Cisco Catalyst 9000 series switches in CCTV, access control, and physical security network environments. It covers baseline hardening, VLAN segmentation, SSH access, AAA, port security, QoS, and inter-switch connectivity. 
 This is not a one-size-fits-all configuration. Every environment is different. Review each section against your requirements and test before deploying into production. 
 Change every placeholder before deploying. The double-hash placeholder ( ## ) appears throughout this template where site-specific values belong. Deploying a configuration with placeholder values intact is a misconfiguration waiting to cause problems. 
 
 Initial System Configuration 
```
configure terminal
service password-encryption
hostname SWITCH-SITE-##
enable algorithm-type scrypt secret ##CHANGEME##
username netadmin privilege 15 algorithm-type scrypt secret ##CHANGEME##
ip domain name site.domain.local
clock timezone EST -5 0
clock summer-time EDT recurring
```
 service password-encryption enables basic Type 7 encryption for passwords stored in the running configuration. This prevents passwords from appearing in plain text when the config is viewed. Type 7 is not cryptographically strong and can be reversed trivially with freely available tools. It is a deterrent for casual observation, not a security control. The important passwords (enable secret, username passwords) use algorithm-type scrypt, which is a strong hash. 
 hostname sets the device identity. Use a consistent naming convention. When you are looking at syslog entries from 40 switches, meaningful hostnames make the difference between a 10-minute and a 60-minute troubleshooting session. Include the site identifier and switch function in the name. 
 enable algorithm-type scrypt secret configures the enable password using scrypt hashing. This replaces the older MD5-based Type 5 hashing that was the previous best practice. Scrypt is significantly more resistant to offline brute-force cracking. Always use algorithm-type scrypt for any locally defined credentials on the Catalyst 9000 platform. 
 ip domain name is required for RSA key generation, which SSH requires. Set it to something meaningful for the environment. 
 
 VLAN Configuration 
```
vlan 1
 name DEFAULT
!
vlan 99
 name MANAGEMENT
!
vlan 100
 name SYSTEMS
!
vlan 101
 name CCTV
!
vlan 102
 name ACCESS_CONTROL
!
vlan 666
 name BLACKHOLE
!
no vlan 1002
no vlan 1003
no vlan 1004
no vlan 1005
```
 The VLAN IDs and names below are an example, not a standard. Use whatever VLAN scheme the customer already runs, or pick numbers that make sense for the deployment. What matters is the principle: one VLAN per device class, a dedicated management VLAN, a blackhole VLAN for unused ports, and consistency across every site in the same environment so trunks agree on what each ID means. The values shown here are the ones the courseware uses for illustration. 
 VLAN segmentation is one of the most important things you can do on a security network. By default, every port on a new switch sits in VLAN 1. Everything can talk to everything. That is not acceptable in a security environment. 
 VLAN 1 (DEFAULT): Keep it but do not use it. VLAN 1 has specific behaviors around tagged and untagged traffic handling and is the target of VLAN hopping attacks. Do not put production traffic on VLAN 1. 
 VLAN 99 (MANAGEMENT): Switch management traffic only. The management SVI and any management access to the switch lives here. Isolated from production traffic. 
 VLAN 100 (SYSTEMS): Servers, recording platforms, workstations, and other infrastructure that supports the security systems. 
 VLAN 101 (CCTV): IP cameras only. Camera traffic is bandwidth-heavy and predictable. Isolating it simplifies QoS, troubleshooting, and security policy. 
 VLAN 102 (ACCESS CONTROL): Access control panels, door controllers, intercoms. Different traffic patterns and security requirements than cameras. 
 VLAN 666 (BLACKHOLE): Every unused port gets assigned here. Not routable. No services. An unauthorized device connecting to an unused port gets no network access and generates a log event. 
 VLANs 1002-1005: These legacy FDDI and Token Ring VLANs exist by default. Remove them to clean up the VLAN database. 
 
 Management Interface 
```
interface vlan 99
 description Management-SVI
 ip address 10.42.67.253 255.255.255.0
 no shutdown
!
ip default-gateway 10.42.67.254
```
 The management SVI provides IP connectivity to the switch for management purposes. Using the site brand address 10.42.67.0/24 for the management VLAN of a single-site deployment. The SVI gets .253 , SVIs are assigned descending from .253 to keep them visually distinct from the default gateway at .254 . 
 The default gateway points to 10.42.67.254 , which is the firewall or Layer 3 switch providing routing for this environment. Always use .254 for the gateway. When you see a management address, .253 tells you it is a switch SVI and .254 tells you it is the gateway, no lookup needed. 
```
ip access-list standard MGMT-ACCESS
 permit 10.42.67.11 0.0.0.0 ! VMS server
 permit 10.42.67.12 0.0.0.0 ! Secondary server / management workstation
 permit 10.42.67.0 0.0.0.63 ! Authorized management range
 deny any log
!
line vty 0 15
 access-class MGMT-ACCESS in
 transport input ssh
 exec-timeout 10 0
 login local
```
 The management access-list restricts SSH access to the switch to specific authorized addresses. The VMS and server addresses follow the .11 and .12 convention for servers in this subnet. Devices in the general management range use the lower part of the address space ( .0-.63 ). Adjust these to match your actual addressing scheme. 
 exec-timeout 10 0 disconnects idle VTY sessions after 10 minutes. An authenticated, idle management session is an open window. 
 
 SSH Configuration 
```
crypto key generate rsa modulus 4096
!
ip ssh version 2
ip ssh authentication-retries 3
ip ssh time-out 60
!
ip ssh server algorithm kex diffie-hellman-group14-sha256 diffie-hellman-group16-sha512
ip ssh server algorithm mac hmac-sha2-256 hmac-sha2-512
ip ssh server algorithm encryption aes256-ctr aes192-ctr aes128-ctr
```
 SSH version 2 only. Version 1 has known vulnerabilities and must not be used. The 4096-bit RSA key length provides adequate security for the key exchange. The algorithm settings restrict SSH to modern key exchange, MAC, and encryption algorithms, preventing negotiation down to legacy algorithms that have known weaknesses. 
 Telnet should not be enabled on any production network device. If it is enabled by default on your platform, disable it explicitly: 
```
line vty 0 15
 transport input ssh
 no transport input telnet
```
 
 AAA Configuration with RADIUS 
```
aaa new-model
!
radius server RADIUS-01
 address ipv4 10.42.67.11 auth-port 1812 acct-port 1813
 key ##CHANGEME##
!
aaa group server radius RADIUS-GROUP
 server name RADIUS-01
!
aaa authentication login default group RADIUS-GROUP local
aaa authentication enable default group RADIUS-GROUP enable
aaa authorization exec default group RADIUS-GROUP local
aaa accounting exec default start-stop group RADIUS-GROUP
```
 AAA with RADIUS centralizes authentication through your network management system or a dedicated RADIUS server. The RADIUS server address points to 10.42.67.11 , the primary management server. The fallback local keyword ensures that local credentials work if the RADIUS server is unreachable, so a RADIUS outage does not lock you out of your own devices. 
 Accounting with start-stop logging records every management session: who logged in, when, and when they logged off. This is the audit trail for switch management access. 
 
 Access Port Configuration 
 Camera Ports (VLAN 101) 
```
interface range GigabitEthernet1/0/1 - 12
 description CCTV-CAM-##
 switchport mode access
 switchport access vlan 101
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable
 ip dhcp snooping limit rate 15
 storm-control broadcast level 20.00
 storm-control multicast level 20.00
 storm-control action shutdown
 no cdp enable
 no lldp transmit
 no lldp receive
 no shutdown
```
 switchport nonegotiate disables DTP (Dynamic Trunking Protocol) on the port. DTP is a Cisco-proprietary protocol that negotiates trunk formation. On access ports facing cameras, there is no reason to allow trunk negotiation. Disabling DTP prevents VLAN hopping attacks that exploit DTP. 
 spanning-tree portfast skips the listening and learning states of Spanning Tree and brings the port up immediately. Appropriate for access ports connecting to end devices. Reduces the time cameras take to come online after a reboot or link restoration. 
 spanning-tree bpduguard enable err-disables the port if a BPDU (Bridge Protocol Data Unit) is received. Cameras do not send BPDUs. If a BPDU is received, it means someone connected a switch or a device running a bridging protocol to a camera port. The port shuts down immediately. This prevents unauthorized switches from being introduced to the camera network. 
 ip dhcp snooping limit rate 15 rate-limits DHCP packets on camera ports. This prevents DHCP starvation attacks where a device floods the network with DHCP requests to exhaust the DHCP pool. 
 no cdp enable / no lldp disables Cisco Discovery Protocol and LLDP on camera ports. These protocols advertise information about the network infrastructure, device models, software versions, addressing, to anything connected to the port. Cameras do not need this information. Disabling it prevents cameras (or anything else connected to these ports) from discovering the network topology. 
 Port Security on Camera Ports 
```
interface range GigabitEthernet1/0/1 - 12
 switchport port-security maximum 2
 switchport port-security violation restrict
 switchport port-security aging time 1
 switchport port-security
```
 Port security limits the number of MAC addresses allowed on a port. Cameras have one or two MACs (some cameras with two network interfaces). Setting maximum to 2 accommodates those cameras while preventing a camera port from being used as a connection point for a hub or unmanaged switch that then allows multiple devices onto the camera VLAN. 
 Violation action is set to restrict rather than shutdown . A restrict action drops packets from unauthorized MACs and generates a log event but does not err-disable the port. This is appropriate for camera ports where a brief address irregularity (camera reboot that changes the MAC, a camera replacement) should not take the port offline. If your security policy requires more aggressive enforcement, use shutdown . 
 Access Control Ports (VLAN 102) 
```
interface range GigabitEthernet1/0/13 - 20
 description ACCESS-CTRL-##
 switchport mode access
 switchport access vlan 102
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable
 storm-control broadcast level 10.00
 no cdp enable
 no lldp transmit
 no lldp receive
 no shutdown
```
 Unused Ports (VLAN 666) 
```
interface range GigabitEthernet1/0/23 - 48
 description UNUSED-BLACKHOLE
 switchport mode access
 switchport access vlan 666
 shutdown
```
 Unused ports get assigned to VLAN 666 and administratively shut down. A port in VLAN 666 that is administratively down provides no network access. If a port is needed later, it gets configured explicitly before being brought up. 
 
 Trunk Port and Uplink Configuration 
```
interface range TenGigabitEthernet1/1/1 - 2
 description UPLINK-TO-CORE-SWITCH-##
 switchport mode trunk
 switchport trunk native vlan 666
 switchport trunk allowed vlan 99,100,101,102
 channel-group 1 mode active
 no shutdown
!
interface port-channel 1
 description LAG-UPLINK-TO-CORE
 switchport mode trunk
 switchport trunk native vlan 666
 switchport trunk allowed vlan 99,100,101,102
```
 switchport trunk native vlan 666 assigns the blackhole VLAN as the native (untagged) VLAN on trunk ports. Any untagged traffic arriving on the trunk lands in the blackhole VLAN rather than VLAN 1. This is one of the primary mitigations for native VLAN-based VLAN hopping attacks. 
 switchport trunk allowed vlan 99,100,101,102 explicitly defines which VLANs can traverse this trunk. All other VLANs are pruned. If a VLAN is not in this list, traffic from that VLAN cannot cross the trunk. This enforces the principle of least privilege at the VLAN level. 
 LACP port-channel: Two uplinks bundled with LACP provide redundancy and bandwidth aggregation. If one physical link fails, the port-channel continues to function on the remaining link. LACP mode active initiates the bundle negotiation from this end. 
 
 DHCP Snooping 
```
ip dhcp snooping
ip dhcp snooping vlan 100,101,102
no ip dhcp snooping information option
!
interface port-channel 1
 ip dhcp snooping trust
```
 DHCP snooping prevents unauthorized DHCP servers from issuing addresses on the network. When enabled, only ports marked as trusted can respond to DHCP requests. The uplink port-channel is trusted because the legitimate DHCP server lives upstream. Camera ports and access control ports are untrusted by default, so a device connected to a camera port cannot act as a rogue DHCP server. 
 no ip dhcp snooping information option disables DHCP Option 82 insertion. Option 82 adds relay agent information to DHCP packets, which can cause issues with DHCP servers that are not configured to accept it. Disable it unless your DHCP infrastructure specifically requires it. 
 
 Dynamic ARP Inspection 
```
ip arp inspection vlan 100,101,102
!
interface port-channel 1
 ip arp inspection trust
```
 Dynamic ARP Inspection (DAI) validates ARP packets against the DHCP snooping binding table. This prevents ARP spoofing, where a device sends gratuitous ARP replies to poison the ARP caches of other devices and intercept traffic. DAI drops ARP packets that do not match the binding table. The uplink is trusted because upstream devices are authoritative. 
 Note: DAI works in conjunction with DHCP snooping. Devices with statically configured IP addresses need a static entry in the DHCP snooping binding table for DAI to validate their ARP packets: 
 ip dhcp snooping binding 001a.2b3c.4d5e vlan 101 10.42.67.100 interface GigabitEthernet1/0/1 expiry 86400 
 
 QoS for Camera Traffic 
```
mls qos
!
class-map match-any CAMERA-TRAFFIC
 match access-group name CAMERA-ACL
!
ip access-list extended CAMERA-ACL
 permit ip 10.42.67.0 0.0.0.255 any
!
policy-map CAMERA-QOS
 class CAMERA-TRAFFIC
 set dscp af31
 class class-default
 set dscp default
!
interface range GigabitEthernet1/0/1 - 12
 service-policy input CAMERA-QOS
```
 QoS marks camera traffic with DSCP AF31, which places it in the Assured Forwarding queue. In congested conditions, camera traffic is given priority over unmarked (best-effort) traffic. This is particularly relevant on uplinks that carry mixed traffic types. 
 This is a basic QoS policy. Complex environments with strict QoS requirements may need more sophisticated queuing policies. If your VMS vendor has specific DSCP recommendations for their platform, use those values. 
 
 System Logging 
```
service timestamps log datetime msec localtime show-timezone
service timestamps debug datetime msec
!
logging on
logging buffered 512000 informational
logging trap informational
logging source-interface vlan 99
logging host 10.42.67.11
```
 Syslog forwarding to the management server at 10.42.67.11 . Logs originate from the management SVI (VLAN 99) so they are identifiable by source IP. The buffer size of 512KB keeps local logs available for recent troubleshooting even if the syslog server is temporarily unavailable. 
 The logging level of informational captures connection events, configuration changes, BPDU guard and port security violations, and other relevant operational events without generating excessive noise from debug-level messages. 
 
 SNMP Configuration 
```
snmp-server community ##READ-ONLY-STRING## RO MGMT-ACCESS
snmp-server location Site-##-IDF-##
snmp-server contact netops@domain.local
snmp-server host 10.42.67.11 version 2c ##READ-ONLY-STRING##
no snmp-server community public
no snmp-server community private
```
 SNMP v2c with a strong community string, read-only, restricted to the management access-list defined earlier. Remove the default public and private community strings. These are the SNMP equivalent of default passwords. They are publicly known, and any device with SNMP enabled using them is accessible to anyone who knows to look. 
 SNMPv3 is preferred for new deployments because it supports authentication and encryption. If your monitoring platform supports SNMPv3, use it: 
```
snmp-server group MGMT-GROUP v3 priv
snmp-server user MGMT-USER MGMT-GROUP v3 auth sha ##AUTHPW## priv aes 128 ##PRIVPW##
```

================================================================

## Why this exists

URL: https://hans.study/standards-guidance/cssir-00-why-this-exists/
Type: kb
Date: 2026-05-10
Description: Why this reference exists, who it is for, what it is not.

import Callout from '../../components/kb/Callout.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import DefList from '../../components/kb/DefList.astro';

 If you are working on access control, video surveillance, or intrusion detection in Canada, you have already noticed the gap. The American trade publications cover the protocols. The European standards cover detention and high-security work. Canadian guidance is scattered across CSA, ULC, the National Building Code, provincial supplements, and a handful of manufacturer documents that do not always agree with each other. 

 BICSI publishes the manuals that govern North American structured cabling practice. CSA publishes the T-series for Canadian commercial telecommunications. ULC publishes the alarm and central station standards. The Canadian Electrical Code dictates how the cable is supported, separated, and protected. Health Canada publishes the rules for cannabis facilities. CSA Z246 covers oil and gas. CSA Z32 covers healthcare. Each of these documents costs money, sits behind a portal, and assumes the reader already understands the others. The technician on the truck does not have time to triangulate between half a dozen paid standards every time a question comes up. 

 Who this is for 

 Five audiences 

<DefList>
 <dt>Working integrators</dt>
 <dd>The technician on the truck pulling cable, terminating readers, commissioning doors. Most of the document is written for this reader. The voice assumes you know what a punchdown tool is, what the inside of a strike looks like, and what AHJ stands for.</dd>

 <dt>Designers and consultants</dt>
 <dd>The person writing the spec, sizing the IDF, deciding which rooms get cameras. Chapters on cabling, fiber, terminations, and testing are written for you. The detention, healthcare, education, and critical-infrastructure chapters tell you what each environment actually needs so the spec does not have to be rebuilt at IFC.</dd>

 <dt>Architects and engineers of record</dt>
 <dd>The person reviewing the security drawings against the building drawings. Chapters on pathways, firestop, grounding, and labelling are written so a non-specialist can confirm the security work coordinates with the rest of the building.</dd>

 <dt>Project managers</dt>
 <dd>The person scoping the bid, coordinating trades, signing off at close-out. Chapters on codes, identification, network devices, and commissioning are written for you. The detailed install sections help you read install reports without taking the integrator's word for everything.</dd>

 <dt>Owner-side technical staff</dt>
 <dd>IT directors, facility managers, security leads running the building after the install is done. The systems chapters and the commissioning chapter help you ask better questions during the project and operate the system better afterwards.</dd>
</DefList>

 How to use this document 

 Linear or by chapter 

 Linear if you are new. Direct to the chapter you need if you are not. The TOC on the left holds every section. The document is one page on purpose. Trade references work better when the reader can search a single source than when they have to chase links through a dozen tabs. 

 Organized against construction divisions 

 The chapters follow the order of the work, organized against the construction divisions in the spec book. 

 
 Foundations and codes first 
 Division 26 (electrical) next: pathways, power, grounding, firestop, labelling 
 Division 27 (structured cabling and network) third: cable selection, fiber, terminations, testing, switches 
 Division 28 (electronic safety) fourth: access head-end, doors, video, intrusion 
 Then specialized environments: detention, healthcare, education and transit, critical infrastructure 
 Then the practice that holds it together: rack hardware, tools, commissioning 
 

 Reading the section structure 

 Every chapter is broken down into topic sections. Every topic has three default sub-sections: 

 
 When the rule applies : plain-English explanation of the situation the rule covers 
 The spec : the formal rule, the dimensions, the ratings, the code reference 
 Study Note : what has worked on real projects, with product references where they help 
 

 Some sections add task-specific sub-sections: "Worked example", "What the AHJ fails you for", "Common defects", and similar. Each sub-section is self-contained and can be referenced on its own. 

 What this is not 

 Not a code book 

 The Canadian Electrical Code, the Ontario Building Code, the National Building Code, provincial fire codes, and the standards (CSA, ULC, ANSI/TIA, BICSI) are the authoritative sources. The reference cites them where relevant and works against them throughout. Buy the codes that apply to your work and read them when in doubt. 

 Not a manufacturer's manual 

 Product references appear throughout in Study Notes, dated as 2026 snapshots, because you need to know what to actually order. Study Notes describe what has been used and what has held up. They are not mandatory parts lists. Substitute equivalent products that meet the spec; stay inside the spec on dimensions, ratings, and CSA listings. 

 Not a substitute for licensing or accreditation 

 Canadian institutional security work involves licensed trades (electrical, security technician, low-voltage), licensed professionals (the engineer of record where one is required), and accredited organisations (ULC for monitoring, CSA for product listing). The reference does not replace any of these. 

 Where the reference and a published standard conflict, the standard wins. Where the reference and the project specification conflict, the specification wins. Where the reference and the AHJ inspector conflict, the inspector wins, and the reference gets updated if the inspector's interpretation is the better one. 

 Canadian security install work is a trade. Trades have standards. There is no excuse, in 2026, for unsupervised analog Wiegand on a new build, for unshielded twisted pair on an OSDP run, for plenum cable rated only to FT4, for indoor cable run outdoors in conduit, for twist-on connectors at a junction box, or for a door labelled DR-12 on the drawing and 5-A on the panel. None of this is opinion. Read the rest of the document and the reasoning is on every page. 

 Last reviewed 2026-08-23 by Hans Study, CISSP, principal at Hans Study in Ontario, Canada. Updates ship as the codes change and as the field hands me more lessons.

================================================================

## Codes and standards

URL: https://hans.study/standards-guidance/cssir-01-codes-standards/
Type: kb
Date: 2026-05-10
Description: Canadian codes and standards that govern institutional security install work. CEC, OBC, NBC, CSA T-series, ULC alarm and central station standards, ANSI/TIA, BICSI, NFPA, OHSA. How to read them, when they apply, and how to handle AHJ interpretation.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Note from '../../components/kb/Note.astro';
import Take from '../../components/kb/Take.astro';
import Tip from '../../components/kb/Tip.astro';
import Warn from '../../components/kb/Warn.astro';
import DefList from '../../components/kb/DefList.astro';

 Codes and standards are the answer to "why does it have to be done that way." The CEC tells you how to support the conduit. The OBC tells you what the wall has to do during a fire. CSA T-series tells you how to terminate the cable. ULC tells you how the alarm reaches the central station. NFPA tells you how the smoke detector ties into the system. Read the ones that apply to your work and the rest of this document makes sense; skip them and every recommendation reads as opinion. 

 The Canadian Electrical Code (CSA C22.1) 

 When the code applies 

 Every electrical install in Canada. The CEC is published by CSA Group as Standard C22.1 and adopted by every province with its own provincial amendments. The current edition is the 2024 CEC; provincial adoption varies by 12 to 24 months behind publication, so verify which edition the AHJ in your project's jurisdiction is enforcing. 

 The sections that touch security work most 

 
 Section 2 : General rules: applies to every install, defines the responsibilities and the inspection process 
 Section 4 : Conductors: ampacity, temperature ratings, conductor sizing 
 Section 10 : Grounding and bonding: applies in full to security work, references the TGB and TMGB hardware 
 Section 12 : Wiring methods: conduit, cable, raceway, support spacing, fill, bend radius 
 Section 16 : Class 1, 2, and 3 circuits: this is where low-voltage security signal cabling lives. Class 1 is supervised, Class 2 is energy-limited, Class 3 is the broader power-limited classification. 
 Section 18 : Hazardous locations: classified-area work, Division 1 and 2, Zone 0 / 1 / 2 
 Section 20 : Flammable liquids, dispensing pumps: relevant for fleet, fuelling, and transit installs 
 Section 26 : Installation of electrical equipment: working clearances, panel mounting, terminal torque 
 Section 32 : Fire alarm systems and unit smoke alarms: the security install's interface to the fire alarm system 
 Section 60 : Communications circuits: structured cabling, telecom, the low-voltage parts of network and security 
 

 Reading "shall," "should," and "may" 

 The CEC uses three terms with specific meanings: 
 
 Shall : mandatory. The work has to do it. 
 Should : best practice. The work does it unless there is a documented reason not to, agreed with the engineer of record. 
 May : permitted but optional. The work has a choice. 
 
 Every "shall" is a code requirement. Every "should" is a default-on rule. Every "may" is integrator discretion within the bounds of the project specification. 

 Study Note 

 I keep the current CEC on the laptop and the current provincial adoption summary pinned in the truck. Both Ontario and Alberta publish AHJ interpretations regularly; the AHJ interpretation is what the inspector enforces on site, not the federal text alone. When the AHJ and the federal CEC differ, the AHJ wins on that project. Argue the interpretation through formal channels after the install closes; do not argue with the inspector at rough-in. 

 Provincial building codes 

 When the code applies 

 Every building project in Canada falls under a provincial or territorial building code. The codes overlap heavily with the National Building Code of Canada but each province adopts its own version with regional amendments. The OBC (Ontario), the BC Building Code, the Alberta Building Code, and the Quebec Code de la Construction are the four largest in volume. Each is updated on a separate cycle. 

 What touches security work 

 
 Fire-rated wall and floor penetrations (driven by the assembly's rating, applies to every cable and conduit penetration) 
 Smoke barrier and smoke-stop penetrations (additional rating that may be separate from the fire rating) 
 Egress requirements: every door secured by access control has to meet the building code's egress provisions for the occupancy 
 Accessibility requirements (CSA B651 referenced by the OBC and others): reader heights, intercom heights, operator interface placement 
 Acoustical separation: any backbox crossing a sound-rated wall has to maintain the assembly's STC rating 
 Outdoor design: ice-load values, wind-load values, snow accumulation by region (NBC Appendix C climatic data) 
 

 Study Note 

 The single most-common code failure on access control work is a door that locks the egress side or that does not release on fire alarm. The building code is unambiguous: occupants must be able to leave without special knowledge, special tools, or more than one operation. Verify your egress hardware against the project occupancy type at design, and verify the fire alarm interface at commissioning. Get this wrong and you fail the building inspection and the fire inspection at the same time. 

 CSA T-series telecommunications standards 

 When the standards apply 

 The CSA T-series are the Canadian commercial telecommunications cabling standards. They parallel the US ANSI/TIA-568 family and align with the international ISO/IEC 11801. Every structured cabling install in Canada that is specified as institutional-grade references these. 

 The standards in the T-series 

 
 CSA T528 : Commercial Building Telecommunications Administration Standard. Labelling, identifiers, records, drawings. Parallels TIA-606-D. 
 CSA T529 : Commercial Building Telecommunications Cabling Standard. Cable categories, performance, channel and link models. Parallels TIA-568. 
 CSA T530 : Building Facilities, Design Guidelines for Telecommunications. Pathway and space planning. Parallels TIA-569. 
 CSA T568 : Commercial Building Telecommunications Cabling. Cable category specifics, connector pinouts, channel and permanent link. 
 CSA T607 : Commercial Building Grounding and Bonding Requirements for Telecommunications. TGB, TMGB, TBB. Parallels J-STD-607. 
 

 Study Note 

 Most Canadian institutional specs reference both the CSA T-series and the ANSI/TIA equivalents. The TIA documents are more readable and have more diagrams. The CSA documents are the legally-binding Canadian text. Read both; use the diagrams from TIA to understand the rule, then verify the wording in the CSA version for the as-built record. 

 ULC alarm and central station standards 

 When the standards apply 

 Every alarm system in Canada that is monitored by a third-party central station, and every alarm system in a building where ULC listing is required by the AHJ, the insurer, or the institutional standard. 

 The ULC standards that touch security work 

 
 CAN/ULC-S301 : Installation and Services for Fire Signal Receiving Centres and Systems 
 CAN/ULC-S302 : Installation, Inspection, Testing, and Maintenance of Electrical Supervised Burglar Alarm Systems 
 CAN/ULC-S303 : Local Burglar Alarm Units and Systems 
 CAN/ULC-S304 : Signal Receiving Centre and Premises Burglar Alarm Control Units 
 CAN/ULC-S319 : Electronic Access Control Systems 
 CAN/ULC-S536 : Inspection and Testing of Fire Alarm Systems 
 CAN/ULC-S537 : Verification of Fire Alarm Systems 
 CAN/ULC-S559 : Equipment for Fire Signal Receiving Centres and Systems 
 

 The integrator's role versus the central station's role 

 The integrator installs equipment that meets ULC-S304 (alarm control units) and ULC-S319 (access control). The integrator does not run a central station; the contracted central station is ULC-S301-listed for fire and ULC-S302-listed for burglar. Verify the central station's listing at the start of every monitored project; the institution's procurement may have specified a central station that has lapsed its listing or changed its scope. The integrator's responsibility is verification, not certification. 

 ANSI/TIA structured cabling standards 

 When the standards apply 

 Most institutional projects in Canada reference both CSA T-series and ANSI/TIA documents. The ANSI/TIA standards are referenced for product-level specifications (cable category, connector pinout) where the manufacturer's data sheet cites them. 

 The TIA documents that hit the work 

 
 ANSI/TIA-568.0-E (2020): Generic Telecommunications Cabling for Customer Premises (the unified standard) 
 ANSI/TIA-568.1-E (2020): Commercial Building Telecommunications Cabling Standard 
 ANSI/TIA-568.2-E (2024): Balanced Twisted-Pair Telecommunications Cabling and Components Standard (Cat 5e through Cat 8) 
 ANSI/TIA-568.3-E (2022): Optical Fiber Cabling Components Standard 
 ANSI/TIA-569-E (2019): Telecommunications Pathways and Spaces 
 ANSI/TIA-606-D (2021): Administration Standard for Telecommunications Infrastructure (labelling) 
 ANSI/TIA-607-D : Generic Telecommunications Bonding and Grounding 
 ANSI/TIA-942-C (2024): Telecommunications Infrastructure Standard for Data Centers 
 ANSI/TIA-1005-A : Telecommunications Infrastructure Standard for Industrial Premises 
 ANSI/TIA-4966 : Telecommunications Infrastructure Standard for Educational Facilities 
 

 BICSI manuals 

 When the manuals apply 

 BICSI publishes the operational practice manuals that govern North American structured cabling. The Telecommunications Distribution Methods Manual (TDMM) is the field reference; the Information Technology Systems Installation Methods Manual (ITSIMM) and the Outside Plant Design Reference Manual (OSPDRM) cover the in-building and outside-plant work respectively. BICSI's RCDD certification verifies that a designer has working knowledge of these manuals. 

 Study Note 

 BICSI is not a code; the AHJ does not enforce it. BICSI is the operational practice that explains how to do the work the codes and standards require. The TDMM is on the shelf for the engineer of record and the lead integrator on every institutional project. The RCDD certification is the design-side credential that confirms the designer has read the manuals. 

 NFPA and Canadian fire codes 

 When the standards apply 

 Fire alarm and life-safety system work, plus any security install that interfaces with the fire alarm system (which is almost every institutional access control project). 

 The fire-related documents 

 
 NFPA 72 : National Fire Alarm and Signaling Code (US, referenced in Canada by some institutional specifications and by manufacturers) 
 CAN/ULC-S524 : Installation of Fire Alarm Systems 
 CAN/ULC-S536 : Inspection and Testing of Fire Alarm Systems 
 CAN/ULC-S537 : Verification of Fire Alarm Systems 
 CAN/ULC-S1001 : Integrated Systems Testing of Fire Protection and Life Safety Systems 
 NFPA 101 : Life Safety Code (US, referenced by some Canadian projects, particularly federal) 
 Provincial Fire Code (e.g., Ontario Fire Code, BC Fire Code): adopts and amends the NBC's fire-related sections 
 

 Integrated systems testing 

 CAN/ULC-S1001 governs the integrated test that confirms every life-safety-related system (fire alarm, voice evacuation, smoke control, sprinkler, elevator recall, access control release, magnetic lock release, security override) actually works together during a fire. The security integrator is one of several trades that participates in this test. Get the door release logic right at design, verify each interface at commissioning, then pass the S1001 test as the final acceptance step. Skip any of those and the building does not get its occupancy permit. 

 OHSA and worker safety 

 When the standards apply 

 Every project. The Occupational Health and Safety Act is provincial; each province publishes its own version with regional amendments. The integrator is the employer for their technicians and is responsible for compliance. 

 The standards that touch security work 

 
 Provincial OHSA : the legal framework 
 CSA Z460 : Control of Hazardous Energy (lockout-tagout) 
 CSA Z462 : Workplace Electrical Safety (arc flash, energised work, PPE) 
 CSA Z259 series : Fall Protection (relevant for any rooftop or elevated work) 
 CSA Z1610 : Protection of First Responders from Chemical, Biological, Radiological, and Nuclear (CBRN) Events (relevant for critical infrastructure work) 
 

 Study Note 

 Energised electrical work practices come from Z462, even when the work is low-voltage. Working live on a 24 VDC access control panel does not require arc-flash PPE, but the lockout procedures, the approach boundaries, and the safe-work permits still apply. Have the OHSA safety paperwork in place before the technician opens the panel. 

 How to handle AHJ interpretation 

 When you encounter a disagreement 

 The Authority Having Jurisdiction inspector reads the code through the lens of the AHJ's local interpretation. Different AHJs read the same clause differently. The inspector on site is the local interpretation that matters for your project. 

 What to do at rough-in or final inspection 

 
 Do not argue at the install. The inspector wins on site. 
 Document the disagreement in writing: clause cited, inspector's interpretation, your interpretation 
 Bring the disagreement to the engineer of record and to the institution's project manager 
 Where the disagreement is material, request a written clarification from the AHJ's chief inspector or chief electrical inspector 
 Where the AHJ's interpretation is more conservative than the spec, comply. Where the AHJ's interpretation is less conservative, comply with the spec (which is also code-compliant). 
 Update the reference if the AHJ interpretation is the better one 
 

 Edition currency 

 Working to the current edition 

 Every standard above is published in editions. Work to the current edition unless the project specification explicitly references an older edition (sometimes the case on phased projects where consistency with earlier phases matters). Verify which edition the AHJ in the project's jurisdiction is enforcing. 

 Study Note 

 Provincial code adoption lags federal publication by 12 to 24 months. A 2024 CEC change may not be enforced in your province until 2026 or 2027. Check the provincial adoption summary, not just the CSA publication date. When the project specification references a code edition that the AHJ has not yet adopted, the AHJ's enforced edition governs unless the spec specifically asks for the newer one. 

 Codes and standards are the spine. Read the CEC sections that touch security work (Sections 2, 4, 10, 12, 16, 18, 26, 32, 60), keep the current provincial building code at hand, reference the CSA T-series for cabling, the ULC standards for monitored alarm and access, ANSI/TIA for product-level cabling, BICSI for operational practice, NFPA and ULC for fire interface, and provincial OHSA for worker safety. When the AHJ disagrees with the spec, the AHJ wins on site and the disagreement gets resolved on paper afterwards. Every refusal to spec a particular item or do a particular thing has a code reference behind it. Cite the code in the spec and the project specifications hold up at audit.

================================================================

## Pathways and conduit

URL: https://hans.study/standards-guidance/cssir-02-pathways-conduit/
Type: kb
Date: 2026-05-10
Description: Conduit, raceway, and supports for Canadian institutional security installs. Conduit type by environment, support spacing, fittings, pull boxes, backboxes, fill, expansion, sealing, mounting heights, surface raceway, cable tray, J-hooks, underground pathway, detention envelope.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Pathway decisions outlive every other part of the install. Cable gets replaced. Devices get replaced. The conduit and the supports stay in the walls for the life of the building. Get this layer right at design and the next twenty years of cable refreshes are pulls, not rebuilds. Get it wrong and the second cable refresh becomes a new conduit bid. 

 This chapter is the longest in the document because pathway choices touch every other chapter. Read it once cover to cover. The rest of the document references the rules below instead of repeating them. 

 Conduit type by environment 

 When the rule applies 

 Every conduit run on the project. The conduit material is decided by where the conduit lives, not by what is in it or what is on the truck. The CEC and the OBC define what is permitted in each environment; the project specification narrows it further. The list below is the working default for institutional security work in Canada. 

 The spec 

 
 EMT (electrical metallic tubing) : interior horizontal runs above 1200 mm AFF in finished and unfinished non-detention spaces. CSA C22.2 No. 83. Insulated-throat connectors. Rain-tight fittings on any 53 mm and smaller EMT in damp or condensation-prone locations. 
 RGS (rigid galvanized steel) : exposed exterior, semi-exterior, all interior conduit below 1200 mm AFF in mechanical and electrical rooms, conduit feeding any service over 600 V, and every conduit run inside a detention envelope. 
 IMC (intermediate metallic conduit) : acceptable wherever RGS is required, except inside detention envelopes (where the project specification almost always names RGS) and inside classified hazardous locations. Saves labour on long exterior runs. 
 Epoxy-coated RGS : corrosive-atmosphere indoor and outdoor: chemical storage, water and wastewater plants, indoor pools, kitchen back-of-house, salt-storage buildings, fleet wash bays. 
 LFMC (liquid-tight flexible metal conduit) : final connections to motorized equipment, distribution transformers, vibrating equipment, outdoor enclosures. Minimum 450 mm and maximum 600 mm with a 180° loop where possible. CSA C22.2 No. 56. 
 FMC (flexible metallic conduit, "Greenfield") : across building expansion joints, with no less than 600 mm of extra curve to absorb movement. Not used inside detention. Not used on supervised loops (failure is undetectable). 
 Rigid PVC (Schedule 40 or 80) : underground branch, in-slab branch in poured concrete, underground exterior beneath paving. CSA-approved, FT4. Separate ground conductor required (PVC is not a ground). 
 ENT (electrical non-metallic tubing) : embedded in concrete floor slabs only, with written engineer consent. CSA C22.2 No. 227.1 and No. 85. Not used in plenum or riser spaces, not used for security signal outside specific in-slab branch circuits. 
 

 Study Note 

 For interior EMT and exterior RGS, the conduit itself is brand-agnostic as long as the CSA listing matches the application. Where the brand matters is the supports and the connectors, not the pipe. Iberville for the boxes and the fittings. Cobra for the clamps. Eaton B-Line or Unistrut for the strut. Thomas & Betts for sealing fittings and EYS conduit fittings. That combination has held up across institutional projects for years and the AHJ rarely questions it. 
 For PVC, IPEX is the Canadian-made default. Schedule 40 for general underground, Schedule 80 under roads or high-traffic surfaces. IPEX Cor-Line ENT for the rare in-slab application where the engineer approves it. 

 Minimum conduit size 

 When the rule applies 

 Every conduit feeding a security signal, structured cabling, or low-voltage device drop. The CEC permits 16 mm (1/2") for general branch circuits; security and structured cabling work uses 21 mm (3/4") as the minimum because every device drop sees at least one cable replacement during the building's life and 1/2" does not give you the working room. 

 The spec 

 
 16 mm (1/2") absolute CEC minimum for general electrical work; not used for security signal or structured cabling 
 21 mm (3/4") minimum for any structured cabling, security signal, or low-voltage signal run 
 27 mm (1") minimum from a workstation outlet (double-gang box) to the nearest raceway or pull point 
 53 mm (2") and larger. factory-made elbows; no site-made bends 
 Conduit sizes in this chapter are CEC metric designators, not soft conversions: 16, 21, 27, 35, 41, and 53 for 1/2" through 2". Physical dimensions elsewhere in the chapter are real measurements and read as such. 
 Drawing sizes are minimum sizes; do not decrease without engineer review and AHJ acceptance 
 

 Study Note 

 A 16 mm (1/2") EMT holds exactly one Cat 6A at code-day fill. One cable at 53% of a 196 mm² interior is 104 mm² allowed against 44 mm² used, which passes. Add a second and the limit drops to 31%, so 61 mm² allowed against 88 mm² used, which fails. A 1/2" conduit with two Cat 6A in it is already over before anyone touches it. 
 A 21 mm (3/4") EMT takes three at code and two inside the 30% design target. That is the smallest size that survives a cable refresh. The cost difference per metre is pennies. The conduit is a 30-year decision; spend the pennies once and save the re-pull later. 

 Conduit support spacing 

 When the rule applies 

 Every conduit run on the project, suspended or surface-mounted, indoor or outdoor. The CEC sets maximum spacing at 1.5 m (5 ft) for EMT and 0.9 m (3 ft) for RGS in most positions. Within 0.9 m of every junction box, conduit body, and termination the spacing is tighter, regardless of conduit type. This is the most common spacing rule that AHJ inspectors fail integrators on. 

 The spec 

 
 EMT : 1.5 m (5 ft) maximum between supports on suspended and surface-mounted runs 
 RGS : 0.9 m (3 ft) maximum between supports on suspended and surface-mounted runs 
 Within 0.9 m (3 ft) of every box, conduit body, and termination , regardless of conduit type 
 Within 0.3 m (1 ft) of every change in direction , in addition to the run-spacing rule 
 Support every conduit independently from building structure (slab, wall, structural steel) Not from ceiling grid wires, ductwork, piping, cable tray, or formed steel decking. 
 12-gauge galvanized steel strut (1-5/8" / 41 mm width) for runs of two or more parallel conduits, supported on minimum 6 mm (1/4") threaded rod from structure on 1.5 m (5 ft) maximum centres 
 

 5 for EMT, 3 for RGS, 3 at every box. Memorize that and the spacing inspection passes on the first walkthrough. 

 Study Note 

 Cobra one-hole HDG malleable iron straps for single conduits in 1/2" through 4" trade sizes. Cobra two-hole for vibration-prone runs. Eaton B-Line or Unistrut strut for any run of two or more parallel conduits with matching channel nuts and end caps. Galvanized all-thread rod, 1/4" minimum for two-conduit channel and lighter, 3/8" for three-conduit and heavier. Cobra galvanized iron beam clamps for attachment to exposed structural steel. Hilti HKD or Red Head Multi-Set drop-in anchors for slab attachment under load. 

 What the AHJ fails you for 

 
 Conduit supported from ceiling-grid wires (against CEC) 
 Conduit hung from ductwork or piping (against CEC) 
 Spacing exceeds 1.5 m on EMT or 0.9 m on RGS 
 No support within 0.9 m of a box 
 No expansion fitting at a building expansion joint 
 Conduit run within 150 mm (6") of hot piping or hot equipment 
 
 The fix is the 5-3-3 rule applied without exception. 

 Hanger types by application 

 When the rule applies 

 Every conduit run that does not surface-mount directly to a wall. The clamp on the conduit is one decision; the hanger between the clamp and the structure is another. Match the hanger to what is above the conduit. 

 The spec 

<DefList>
 <dt>Beam clamps on exposed structural steel</dt>
 <dd>Galvanized iron beam clamp sized for the flange width and the rod size. Drop a piece of all-thread from the clamp and land on a single strap or on a length of strut for multi-conduit runs.</dd>

 <dt>All-thread rod from concrete inserts or drop-in anchors</dt>
 <dd>For slab-mounted hangers in interior spaces. Concrete inserts are cleaner if the slab is poured around them; drop-in anchors work after the fact. Verify pull-out rating against the loaded weight.</dd>

 <dt>Trapeze hangers</dt>
 <dd>Two threaded rods supporting a horizontal piece of strut. Used for runs of three or more conduits, or for a single large RGS run that needs lateral stability. Size rod and strut against the loaded weight per the manufacturer's table.</dd>

 <dt>Side-beam clamps and angle brackets</dt>
 <dd>For attaching conduit to wall studs, columns, and the sides of structural beams. Angle brackets give the standoff needed for a smooth bend at a corner.</dd>

 <dt>J-hooks and bridle rings</dt>
 <dd>For non-conduit cable support. Covered in the J-hook section below.</dd>
</DefList>

 Study Note 

 Cobra beam clamps for structural steel attachment. Eaton B-Line or Unistrut strut for trapezes and multi-conduit hangers. Hilti HKD drop-in anchors when the slab is already poured. Red Head Multi-Set as the equivalent on Red Head-standardized projects. Cobra side-beam clamps for column attachment. Verify the manufacturer's torque spec at every anchor. 

 Conduit fittings, terminations, and bushings 

 When the rule applies 

 Every fitting between two pieces of conduit, every fitting between conduit and box, every termination. Fittings get the same care as the conduit they connect, because the fitting is where conductors are most likely to get damaged during pulling and most likely to suffer from moisture intrusion during service. 

 The spec 

 
 EMT fittings: insulated-throat steel set-screw or compression couplers and connectors 
 EMT in damp, semi-exterior, or condensation-prone locations: rain-tight fittings on every 50 mm and smaller 
 EMT compression connectors required for all conduit penetrating exterior walls, floor slabs, and any vapour-barrier penetration 
 RGS fittings: threaded couplings, elbows, unions. Running threads not permitted (use a coupling and a length of nipple) Galvanized to match conduit. 
 Conduit bodies (LB, T, C, X) for direction changes that are not full-radius elbows. Covers gasketted in damp and exterior locations. 
 Plastic insulating bushings on every conduit termination at every box, no exceptions 
 Bonding bushings on RGS runs over 600 V or where the panel schedule calls for it 
 Conduit waterfalls on all 4" trade-size conduit terminating in cabinets, racks, or pull boxes (cable bend protection at exit) 
 Sealing fittings at every classified hazardous location boundary, every interior-to-exterior wall penetration on conditioned-to-unconditioned space, and every vapour-barrier penetration. Poured with the listed sealing compound. 
 

 LBs are prohibited on communications pathways 

 The standard institutional communications spec prohibits LB conduit bodies and pull elbows on any communications conduit run. Use sweep elbows or full-radius 90° factory bends instead. The reason is the bend radius: an LB has a tight internal radius that exceeds the bend-radius spec of every Cat 6A and fiber cable. Pulling cable through an LB damages the jacket and the pair geometry. Sweep elbows cost more and take longer to install; they are non-negotiable on any structured-cabling or security pathway. 

 Study Note 

 Thomas & Betts for EMT compression connectors, sealing fittings, and EYS. Iberville for conduit bodies and threaded hubs. Plastic insulating bushings on every termination. they cost almost nothing and they keep the AHJ inspector moving. Bonding bushings where the panel schedule says so; do not substitute. 

 Bend radius and bend count per run 

 When the rule applies 

 Every conduit run between pull points. Every bend is a friction point during cable pulling and a long-term stress point on the cable inside. The rules below come from the institutional communications specification and hold for every security pathway. 

 The spec 

 
 Maximum two 90° bends, or 180° total, per conduit run between pull points 
 Pull box at every 30 m (100 ft) of conduit length, regardless of bend count 
 Pull boxes are not used as bends; conduit enters and exits the box on the same axis where geometry permits 
 Bend radius for conduit 53 mm (2") and smaller: minimum 6× the conduit diameter 
 Bend radius for conduit larger than 53 mm (2"): minimum 10× the conduit diameter 
 Site-made bends in EMT: hydraulic or hand bender only. No kinking, no flattening, no jacket flake. 
 Site-made bends in RGS up to 50 mm: hydraulic or mechanical bender. RGS larger than 50 mm: factory-made elbows only. 
 PVC bends to 50 mm: heat-gun made bends acceptable. Above 50 mm: factory elbows only. 
 

 The two-90 rule in practice 

 Run conduit in straight lines wherever you can. The two-90° budget is for unavoidable jogs around structural elements, the rise from slab to ceiling space, and entry to the device backbox. A run that needs three bends gets a pull box; a run that needs four bends gets two pull boxes. Cable pulled through three bends without a pull box exceeds the manufacturer's pull tension specification and the cable does not certify even when it tests clean on day one. 

 Pull box sizing 

 When the rule applies 

 Every pull box on every conduit run. Pull boxes that are too small are the second most-common cable-pull defect after exceeded bend count. The box size is dictated by the largest conduit entering it and by the geometry of the cable making the turn. 

 The spec 

 
 Straight pull-through: minimum length equal to 8× the inside diameter of the largest entering conduit 
 Angle and U pulls: minimum distance from conduit entry to opposite wall equal to 6× the inside diameter of the largest entering conduit, plus the sum of the diameters of every other conduit entering on the same wall 
 4" trade-size conduit pull boxes: minimum 30" × 24" × 6" (762 × 610 × 152 mm) regardless of the 8× calculation result 
 Vertical conduits: pull boxes provide straight pass-through for vertical cables (no off-axis turn at the box) 
 Pull box covers: screw-type, not hinged 
 24" × 24" minimum access panel where pull boxes are installed in inaccessible ceiling spaces 
 Pull boxes provided at every 30 m (100 ft) of run, at not less than 30 m intervals 
 Cover labelled with the system designation (security signal, communications, power) and circuit identification per chapter 06 
 

 Study Note 

 Hammond galvanized or prime-coated steel boxes, screw-cover, sized from the Hammond catalogue against the calculated minimum dimension. Hammond 1414 series for general-purpose interior. Hammond 1418 series for larger pulls. Hammond N1J series (NEMA 1) for clean indoor wall mount. Hammond N4 and N4X series (NEMA 4 / 4X) for damp, washdown, and exterior. For surface-mount transitions on raceway, Legrand / Wiremold boxes matching the raceway series. For PVC runs, CSA-certified PVC boxes solvent-welded with PVC adapters. 

 Backboxes for security devices 

 When the rule applies 

 Every device on a security install lands in a backbox. The backbox dimension is the difference between a clean termination with service slack and a cable jammed against the device that fails three years in. 

 The spec 

 
 Communications and security signal general : 4-11/16" × 4-11/16" × 2-1/2" (119 × 119 × 64 mm) minimum 
 Workstation outlets, double-gang locations : double-gang box with 27 mm (1") conduit minimum to nearest raceway or pull point 
 Card reader at door : single-gang or double-gang to match reader cutout, 2-1/2" minimum depth, 21 mm (3/4") conduit to the door junction or panel 
 Camera at finished ceiling : 4" octagon or 4-11/16" square box, supported independently from ceiling grid, attached to structural ceiling 
 Camera on exterior wall : 4-11/16" weatherproof cast box (FS or FD series), gasketted cover, conduit entry from below or rear 
 Door position switch : 4" square box at door header, strike side, 50 mm (2") in from frame edge 
 Request-to-exit (REX) sensor : above door frame, centred over clear opening 
 Intercom station : depth and dimension per manufacturer mounting cutout, 27 mm (1") conduit minimum to riser 
 Through-wall, exterior, vapour-barrier : cast Feraloy (FS, FD) with sealed entries 
 Plaster ring / raised cover : 3/8" deep minimum on every stud-wall backbox to bring device flush with finished surface 
 Stagger backboxes in walls and partitions; no back-to-back. Seal against sound transmission per architectural acoustic spec. 
 Through-wall boxes : prohibited for any application 
 

 Study Note 

 Iberville stamped galvanized steel boxes for stud-wall outlets, with 3/8" raised cover or matching plaster ring. For CMU walls, an Iberville masonry-rated box submitted on shop drawing so the box geometry matches the block course and clears the rebar. Iberville cast Feraloy FS or FD series for exterior weather boxes; threaded plugs in every unused conduit entry. Cameras land in Iberville 4-11/16" square boxes supported from structure with all-thread to the slab. 

 Conduit fill 

 When the rule applies 

 Every conduit on the project, sized at design and verified at pull. The CEC's fill table is the inspection-day rule. The design-day rule is tighter, because a conduit at code maximum on day one has no room for additions or substitutions. 

 The spec 

 
 Design-day maximum : 30% of conduit cross-sectional area 
 Code-day maximum (CEC Table 8) : 40% for three or more conductors, 31% for two conductors, 53% for one conductor 
 Conduit areas come from CEC Table 9I for EMT (NEC Chapter 9, Table 4 in the US). Do not work from the trade size, work from the published interior area. 
 Cat 6A in 21 mm (3/4") EMT: 3 cables at code, 2 with design margin 
 Cat 6A in 27 mm (1") EMT: 5 cables at code, 3 with design margin 
 Cat 6A in 35 mm (1-1/4") EMT: 8 cables at code, 6 with design margin 
 Cat 6A in 41 mm (1-1/2") EMT: 11 cables at code, 8 with design margin 
 Cat 6A in 53 mm (2") EMT: 19 cables at code, 14 with design margin 
 Different cable types in same conduit: only where code permits (no power and signal mixing) and worst-case bend radius and pull tension are met for all types 
 Coax and Cat 6A: never in the same conduit. Separate conduits or metallic divider in cable tray. 
 20% spare conduit capacity in every underground duct bank and every backbone riser, minimum one fully-empty spare conduit per route 
 Use manufacturer's actual jacket diameter from the data sheet, not the nominal value, when fill is within 5% of the limit 
 

 Worked example 

 Start with the cable. A typical Cat 6A jacket is 7.5 mm in diameter, so its cross-sectional area is 44 mm² (0.069 in²). Use the jacket diameter off the manufacturer's data sheet, not this figure, when the count is close to the limit. Cat 6A ranges from roughly 7.0 mm to 8.5 mm across manufacturers and that spread moves the answer. 
 Then the conduit. A 21 mm (3/4") EMT has an interior cross-sectional area of 344 mm² (0.533 in²) per CEC Table 9I. The percentage depends on how many cables are in the run: 53% for one, 31% for two, 40% for three or more. 
 Two Cat 6A in 3/4" EMT : the limit is 31% of 344, so 107 mm². Two cables are 88 mm². Passes, with margin. 
 Three Cat 6A in 3/4" EMT : the limit moves to 40%, so 137 mm². Three cables are 132 mm². Passes at code, but with 5 mm² of headroom it fails the 30% design target of 103 mm². Three cables at code is a conduit nobody can ever add to. 
 Four Cat 6A : 4 × 44 = 176 mm², over the 137 mm² limit. Move to 27 mm (1") EMT, which is 557 mm² interior and 223 mm² at 40%. That takes five at code and three inside the design target. 
 The trap in this calculation is reading a 40% fill allowance as though it were the conduit's interior area. They differ by a factor of two and a half, and the error is invisible because the arithmetic that follows it still works. Pull both numbers from the table every time. 
 Run the math at design, not at pull. 

 Expansion and seismic fittings 

 When the rule applies 

 Every metallic conduit run that crosses a building expansion joint, plus PVC conduit on long runs that see significant temperature swings. Buildings move. Conduit that crosses an expansion joint without an expansion fitting transfers the movement to the conduit and either the conduit cracks at the fitting or the cable inside fatigues until it opens. 

 The spec 

 
 Manufactured expansion fitting at every building expansion joint crossed by metallic conduit 
 Movement allowance: minimum 100 mm (4") axial travel for typical building joints, or as specified by the structural engineer for the project's specific joint movement 
 FMC (galvanized steel flexible) acceptable at expansion joints with no less than 600 mm (24") extra curve 
 PVC conduit: manufactured expansion fittings at the spacing recommended by the conduit manufacturer (typically every 30 m indoor, every 9 m outdoor, against calculated thermal movement) 
 Seismic restraints on conduit runs above 53 mm (2") trade size in seismic Category C and higher zones; restraint design from the structural engineer 
 Bonding jumper around every expansion fitting on RGS to maintain ground continuity (jumper sized per CEC Table 16) 
 

 Thermal expansion math for PVC runs 

 The coefficient of linear thermal expansion for rigid PVC is roughly 5.2 × 10⁻⁵ in/in/°F, against 6.5 × 10⁻⁶ in/in/°F for steel. A 30 m (100 ft) outdoor PVC run that sees a 50°C (90°F) summer-to-winter swing expands and contracts roughly 140 mm (5.5"). One expansion fitting absorbs that movement; a PVC run without one cracks at the first cold snap. 
 The expansion-fitting data sheet gives the per-fitting movement allowance. Divide the calculated total movement by that figure to get the number of fittings required. 

 Study Note 

 Thomas & Betts XJ-series for metallic expansion fittings, sized to the calculated movement. For PVC, the IPEX expansion coupling matched to the conduit schedule. Always include a bonding jumper across the metallic fitting; the AHJ will check. 

 Sealing fittings and vapour-barrier penetrations 

 When the rule applies 

 Every conduit penetrating from a conditioned interior space to an unconditioned exterior space. Every conduit crossing a vapour barrier on a conditioned-space wall. Every classified hazardous location boundary. 

 The spec 

 
 Sealing fitting at every interior-to-exterior wall penetration on conduit between conditioned and unconditioned space 
 Sealing fitting at every classified hazardous location boundary per CEC Section 18 and the area classification drawing 
 Sealing fitting at every vapour-barrier penetration, on the warm side of the vapour barrier 
 Fitting installed with the cover on the accessible side of the wall, vertical orientation that allows poured compound to fill the chamber without trapping air 
 Sealing compound: manufacturer-approved (Chico A or equivalent), poured to the level of the fitting's pouring slope, cured per the manufacturer spec before energizing or pulling cable 
 Conductor count limited per fitting size table (the fitting's heat dissipation defines a maximum conductor cross-section) 
 Fitting installed before cable pulling. Sealing compound poured after termination is complete on both sides. 
 

 The exterior camera condensation trap 

 Exterior camera installs are the most common place to find a missing sealing fitting. Conduit runs from the indoor IDF through the wall, drops down to the camera junction box on the exterior, and the technician seals only the box-to-camera entry against weather. The conduit run itself fills with condensate over the next winter. The moisture pools at the lowest point, freezes, and either corrodes the cable termination or cracks the conduit body. 
 Fix: a sealing fitting on the warm side of the building envelope, every time, not negotiable. 

 Study Note 

 Thomas & Betts EYS sealing fittings sized to the conduit trade size. Chico A sealing compound, poured per the fitting's pouring slope, cured for the manufacturer's full window before pulling cable. Verify cure time against the SDS; cold weather slows it down significantly. 

 Mounting heights for security devices 

 When the rule applies 

 Every device on the install. The heights below are field defaults; project drawings and AHJ override where the application is specific. ADA-compliant heights apply to any device a member of the public is expected to operate, including readers at public entries, intercoms at vestibules, and panic-button devices in public-access areas. 

 The spec 

 
 Card reader, general : 1100 mm (44") to centre of reader, ADA-compliant; 1200 mm (48") where ADA does not apply 
 Card reader, door-operator paired : 1000 mm (40") to centre, coordinated with the operator push plate height 
 Door position switch : top of door frame, strike side, 50 mm (2") in from frame edge 
 Request-to-exit (REX) sensor : above door frame, centred over clear opening 
 Intercom station, general : 1200 mm (48") to centre of speaker grille 
 Intercom station, ADA vestibule : 1100 mm (44") to centre, call button reachable per ADA 
 Camera, interior general : 2700 mm (108", 9 ft) AFF minimum, structural ceiling or wall 
 Camera, exterior perimeter : 4000 mm (157", 13 ft) AFF minimum, on building exterior or pole, vandal-resistance considered for public elevations 
 Camera, detention holding cell : 3700 mm (12 ft) AFF minimum, anti-ligature hardware, fed from secure side (chapter 16) 
 Glassbreak detector : 4500 mm (15 ft) maximum distance from protected glass, opposite or adjacent wall at ceiling level 
 Motion detector (PIR, dual-tech) : 2200 to 2700 mm (88-108") AFF, aimed across the room rather than down 
 Panic button under desk : no specific AFF, mounted at natural seated reach 
 Wall-mounted control panel and keypad : 1200 mm (48") to centre, general staff; 1100 mm (44") for ADA-required locations 
 Surface-mounted backbox depth : 19 mm (3/4") protrusion minimum from finished wall 
 Through-wall conduit protrusion into rooms : 75 mm (3") minimum 
 Floor sleeves : 50 mm (2") minimum above finished floor 
 

 Surface raceway 

 When the rule applies 

 Retrofit work where the wall cannot be opened. Exposed runs in finished public spaces where architecture prefers a clean rectangular profile over visible round conduit. New-build situations where in-wall conduit was not specified at design and adding it after framing is impractical. 

 The spec 

 
 Steel surface raceway, two-piece (base and cover), powder-coated finish matching architectural specification 
 Raceway sized so calculated cable cross-section is no more than 40% of raceway internal area at install 
 Profile by application:: 700 series. short runs of one or two communications cables 2000 series. typical multi-cable run 4000 series. high-density risers and patch panel feeds 6000 series. backbone feeds where multiple raceways converge 
 Boxes, fittings, accessories from the same series and same manufacturer as the raceway 
 Internal fittings factory-formed; no field-formed transitions except at custom junction boxes designed for the application 
 Fastener spacing: 1.0 m (3 ft) maximum on raceway base, fastener within 150 mm (6") of every box, fitting, and termination 
 Bonding: each section grounded to the equipment ground in the served device or to the building TGB per chapter 04 
 

 Study Note 

 Legrand / Wiremold is the institutional default. V2000 series two-piece steel raceway for general-purpose work, with matching V2010 / V2011 / V2400 fittings. 4000 series for high-density runs. 6000 series for backbone feeds. OFR or 880 series for floor and base raceway at desk drops. Plugmold 20- or 24-amp series for plug-in receptacle distribution. Use the manufacturer's matching surface-mount transition boxes; do not improvise. 

 Cable tray 

 When the rule applies 

 High-density runs in equipment rooms, riser shafts, and any space where the cable count exceeds what conduit can practically support. Wire-mesh tray is the institutional standard for communications work. Ladder and solid-bottom trays serve other applications and are out of scope here. 

 The spec 

 
 Wire-mesh, 5 mm (0.196") wire diameter minimum, welded intersections forming 50.8 × 101.6 mm (2" × 4") grid 
 Sections 3048 mm (10 ft) or 1524 mm (5 ft) 
 Widths 100 mm (4") through 610 mm (24") sized to calculated cable count plus 25% spare 
 Sidewall heights 50, 102, or 152 mm sized so cable fill never exceeds side rail height 
 Tray ends formed downward at 90° for drop-in installation onto manufacturer supports 
 Hot-dipped galvanized after fabrication. UL Classified for grounding purposes. 
 All system components from a single manufacturer 
 Cable fill: cable cross-sectional area no more than 50% of interior tray area. Cable depth never exceeds the side-rail height. 
 Tray support spacing: 1.5 m (5 ft) maximum per ANSI/EIA/TIA-569-E; supports within 0.6 m (2 ft) of every splice or intersection if not directly under the splice 
 Support on both sides of every elevation change 
 Clearance: 305 mm (12") above and below tray, 305 mm between stacked trays, 76 mm (3") above drop-ceiling tiles, 25 mm (1") between top of tray and bottom of raised-floor tile 
 Different media types in same tray: full-length metallic divider, each media calculated independently against 50% of its divided area 
 Bonded to TGB with #6 AWG bonding conductor, bonds verified at every splice and intersection (chapter 04) 
 

 Study Note 

 Cablofil (Legrand) and Panduit FastTrac wire-mesh tray are the two field defaults. Pick one and stay in that manufacturer's accessory line for splices, brackets, drops, and waterfalls. Side-action bolt cutters with offset head for cutting sections. Panduit CMW-KIT cable waterfalls at tray exits. Bond to the TGB with #6 AWG and verify continuity at every joint at commissioning. 

 J-hooks for non-conduit cable support 

 When the rule applies 

 Low-density horizontal cable runs in accessible ceiling spaces above finished rooms, where conduit is overkill and tray would be wasteful. J-hook support is acceptable only where the engineer of record has signed off on the application. 

 The spec 

 
 NRTL-listed J-hook for plenum installation where the ceiling is a plenum return 
 Telecommunications-specific J-hook with bearing surface wide enough to honour the bend radius of Cat 6A and high-performance fiber 
 Flared edges to prevent damage during cable installation 
 Top latch or removable retainer strap to hold the bundle; retainer removable and reusable in plenum applications 
 Spacing: 1.5 m (60") maximum on horizontal runs not in conduit or tray 
 Fill: 25% maximum of hook's stated capacity at install, leaving 75% for future cable additions 
 Cable slack between hooks: 150 mm (6") minimum above ceiling, measured from lowest point of cable to top of ceiling tile or structure 
 J-hook at every change in direction (in addition to the run-spacing rule) 
 Supported from structural ceiling (deck above), not from suspended ceiling grid wires 
 Cables not supported by ductwork, piping, or ceiling-grid wires 
 

 Study Note 

 Panduit J-Pro J-MOD series with the bend-radius bearing surface and the removable retainer strap, sized JP131 (3/4"), JP2 (1-5/16"), or JP4 (2-1/16") to the cable bundle diameter plus the 75% spare. CommScope cable hooks are the field-equivalent on CommScope projects. Cobra galvanized iron beam clamps for attachment to structural steel with all-thread to the J-hook. 12-gauge steel support wire from structure where there is no beam; ceiling-grid attachment is sway control only, not load-bearing. 

 Riser slots, sleeves, and floor penetrations 

 When the rule applies 

 Vertical conduit and cable runs between floors. These penetrations are firestopped at every floor per chapter 05, but the slot or sleeve geometry is decided at the pathway-design stage and the firestop comes after. 

 The spec 

 
 Slot or sleeve protrudes minimum 50 mm (2") above finished floor at the upper level (curb to keep water from entering the riser) 
 Sleeve material matches riser conduit material: galvanized steel for steel conduit, Schedule 40 PVC for PVC conduit 
 Sleeves sized 25% larger than the conduit OD to accept the firestop product without compromising the conduit fit 
 Slots in floor slabs sized for as-built cable count plus 25% spare, with firestop product compatible with slot geometry 
 Conduit terminates with plastic bushing on both sides of the floor penetration. Bushing independent of firestop, stays in place after firestop is applied. 
 Multi-cable slot fed by tray or J-hook: tray or hook continues into and through the slot, supported on both sides of the floor 
 Slots and sleeves identified on as-built drawings with type, fire rating, and firestop product reference per chapter 05 
 Floor and wall slots and sleeves firestopped after cable installation per chapter 05. The slot or sleeve itself is not a firestop. 
 

 Separation from power and other systems 

 When the rule applies 

 Every communications and security signal pathway. The numbers below apply to open cable, J-hook, conduit, and cable tray pathways. The CEC and the institutional communications spec both reference these distances. 

 The spec 

 
 Unshielded power lines or electrical equipment, open or non-metallic pathway : <2 kVA: 127 mm (5") 2 to 5 kVA: 305 mm (12") >5 kVA: 610 mm (24") 
 Unshielded power, grounded metal conduit pathway : <2 kVA: 64 mm (2.5") 2 to 5 kVA: 152 mm (6") >5 kVA: 305 mm (12") 
 Power lines in grounded metal conduit, grounded metal conduit pathway : 2 to 5 kVA: 76 mm (3") >5 kVA: 152 mm (6") 
 Motors and transformers : 1.2 m (4 ft) minimum on every side 
 Power conduit and cables <1 kV : 0.3 m (1 ft) minimum 
 Power conduit and cables >1 kV : 1.0 m (3 ft) minimum 
 Fluorescent and similar luminaires : 300 mm (12") minimum 
 Pipes (gas, oil, water, hydronic) : 120 mm (5") minimum 
 HVAC equipment, ducts, and fittings : 150 mm (6") minimum 
 Coax (CCTV/CATV) and Cat 6A : never in the same pathway. Separate conduits or metallic divider in cable tray. 
 

 Why 150 mm from hot pipes 

 The CEC and institutional spec both call out 150 mm (6") minimum from hot piping or hot equipment. The rule is about cable jacket temperature, not about EMI. Cable jackets are rated to a specific operating temperature (60°C general-purpose, 75°C plenum) A conduit run within 150 mm of a hot-water riser or steam line sees the jacket temperature climb above the rated maximum. The jacket softens, the cable inside settles into the jacket, and the geometry of the pair separation degrades. The cable still tests fine on commissioning day, but it ages out years early and the next certification finds NEXT failures that were not there at install. 

 Identification and labelling on conduit 

 When the rule applies 

 Every conduit on every project. Identification at both ends with destination, system designation, and project-standard colour band. Detail in chapter 06. 

 The spec 

 
 Permanent label at every conduit termination identifying destination, system, and cable count 
 Colour band painted around conduit at every termination and every transition point: green for communications, blue for security, red for fire alarm, orange for emergency power, no band for normal power. Full convention in chapter 06. 
 Pull-cord label at every empty conduit reserved for future use, identifying intended system and project spec reference 
 Run conduits parallel or perpendicular to building grid lines for visual identification at distance 
 

 Underground and direct-burial pathway 

 When the rule applies 

 Conduit between buildings, between equipment yards, between the building and the perimeter. The institutional default is a concrete-encased duct bank for any campus run. 

 The spec 

 
 Concrete-encased duct bank: PVC conduit (Schedule 40 minimum, Schedule 80 in high-load areas) embedded in red-dyed concrete 
 20% spare conduits in every duct bank, minimum one fully-empty spare. A 4-conduit bank is built with 5 conduits. 
 Slope: 1% minimum toward a drainage point (handhole, manhole, or building entry pit) 
 Drainage point: handhole or manhole at the low point with a sump sized to absorb expected groundwater inflow 
 Direct-burial flexible polyethylene only where duct bank is not permitted; depth and warning tape per CEC and provincial dig-safety 
 Conduit bed: well-tamped flat earth, free from rocks. Sand backfill around the conduit to project-spec depth. 
 Pull cord: 3 mm minimum polypropylene fish line in every conduit, occupied and spare 
 Underground-to-building entry: PVC or RGS sweep elbow to a conduit body, then to interior pathway. Sealing fitting on the interior side of the building wall. 
 Manhole or handhole: pre-cast concrete, lid sized to conduit count, ground rod inside connected to building TGB through the duct-bank bonding conductor 
 OSP-to-indoor transition splice: inside a manhole, handhole, or interior pull box within 15 m of the boundary (chapter 07) 
 

 Study Note 

 IPEX Schedule 40 PVC for standard duty, IPEX Schedule 80 under roads or high-traffic surfaces. Concrete encasement at 75 mm (3") minimum cover all sides, red-dyed mix, mechanically vibrated to fill voids. Pre-cast concrete manholes with the ground bus and pulling iron specified on the manhole drawing. For direct burial where duct bank is not permitted, medium-density CSA-certified continuous-coil polyethylene conduit. 

 The detention envelope: where the pathway changes 

 When the rule applies 

 Inside detention areas, holding cells, sallyports, and the prisoner-side of any custody door. The pathway rules tighten substantially. Detail in chapter 16; this section captures the pathway-side rules so the detention chapter does not repeat them. 

 The spec 

 
 RGS only. EMT, IMC, FMC, LFMC, and PVC are not used inside the detention envelope. 
 Conduit feeds device boxes from above through the slab where structure permits, with the device box at 3.7 m (12 ft) AFF or higher 
 Tamper-resistant fastener heads on every conduit support, every box cover, every device cover (Torx with security pin, Tri-wing, or one-way as the project specification calls for) 
 Conduit body covers (LB, T, C, X) prohibited inside the protected space. Junction and pull boxes only with screw-cover and screws inaccessible from the protected side. 
 Caulk and sealant at every conduit penetration: pick-resistant detention-grade sealant per chapter 16. Standard fire-rated caulk is not pick-resistant. 
 Cable serviced from the secure side of the wall. Every device on the prisoner-facing wall fed by conduit running through the secure-side mechanical chase. Box opening and service access on the secure side only. 
 No ceiling-cable or J-hook runs inside the protected space. All cable in conduit, all conduit terminations on the secure side. 
 Anti-ligature considerations: no grab points, no exposed conduit below 3.7 m, double-strap every support, and pick-proof every visible fastener 
 

 Study Note 

 RGS with threaded couplings throughout, Iberville Krydon cast junction boxes on the secure side with stainless cover screws and tamper-resistant Torx heads. Pick-proof sealant per the project's detention specification (the standard fire caulk is not pick-proof; the manufacturer publishes which products meet the detention-grade rating) Service every device from the secure side; the prisoner-facing wall is smooth, anti-ligature, and unbroken. 

 The pathway outlives every other layer. Pick conduit by environment, hold to the 5-3-3 support rule, two 90° bends max with a pull box every 30 m, 30% design fill, expansion fittings at every joint, sealing fittings at every interior-to-exterior boundary. The brands in the field notes are what I have used and what holds up; substitute equivalents if your distributor stocks something different, but stay inside the spec on dimensions, ratings, and CSA listings. Do all of that and the cable plant carries the building through four hardware refreshes without a re-pull.

================================================================

## Power, UPS, and redundancy

URL: https://hans.study/standards-guidance/cssir-03-power-redundancy/
Type: kb
Date: 2026-05-10
Description: Power and UPS design for security systems in Canadian institutional installs. Branch circuits, dual-cord PDUs, surge protection, UPS sizing, runtime calculation, voltage drop tables, PoE budgets, generator coordination, breaker locks, identification.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Power is the layer everyone takes for granted until it fails. The security system has the same dependence on clean, conditioned, redundant power that the rest of the IT infrastructure has, plus an additional set of requirements driven by the security mission: doors that hold during a power outage, cameras that record through the generator transfer, intrusion panels that report through a 24-hour battery hold. Get the power layer right at design and the system holds through every foreseeable failure. Get it wrong and the first storm pulls the institution offline at exactly the moment the security record matters most. 

 Branch circuit sizing and dedicated security circuits 

 When the rule applies 

 Every power circuit feeding a security panel, security UPS, or security network device. Security loads are dedicated circuits; they do not share with general-purpose receptacles, with HVAC, or with any load that has an unpredictable duty cycle. 

 The spec 

 
 Every security panel, UPS, and IDF gets a dedicated 120 V or 240 V branch circuit (no shared neutrals, no shared phases beyond what the panel itself draws) 
 Circuit breaker sized at 125% of the calculated continuous load per CEC 8-104 
 Minimum 20 A branch circuit for any IDF with PoE switches 
 Dual-cord equipment (servers, redundant switches) fed from two separate branch circuits on two separate panels where the institutional design supports it 
 Receptacles dedicated to security: hospital-grade NEMA 5-20R or equivalent, marked with the system designation per chapter 06 
 Isolated-ground receptacles where the equipment manufacturer requires them (sensitive analytics, broadcast-grade video, some lab instruments) 
 Receptacle marked with circuit number and panel designation on the faceplate 
 Panel directory entry identifies the receptacle's served device, not just "security" 
 

 Study Note 

 Eaton hospital-grade isolated-ground receptacles (IG5362H series) for any equipment where the manufacturer calls for isolated ground. Standard hospital-grade Eaton 20 A receptacles for the general dedicated circuit. The hospital-grade marking is a green dot on the receptacle face. The isolated-ground designation is an orange triangle. 

 Breaker locks on security circuits 

 When the rule applies 

 Every breaker feeding a security load. The breaker can be tripped intentionally or accidentally during maintenance on adjacent loads; a breaker lock prevents the wrong breaker getting flipped and brings the system down at an unscheduled moment. 

 The spec 

 
 Lockable breaker handle on every security circuit at the source panel 
 Lock keyed to the security install's key system (separate from the building's general electrical key system) 
 Padlock-style lock with hasp accepting the project standard padlock (matched to the institution's key control) 
 Lock kit listed by the breaker manufacturer for the specific breaker type; field-fabricated locks not acceptable 
 Lock removed only by the security integrator or by maintenance staff acting on a documented work order 
 Breaker number, served load, and lock identifier recorded on the panel directory 
 

 Study Note 

 Eaton BLPK series breaker locks for Eaton panels, sized to the breaker frame. For non-Eaton panels, the breaker manufacturer's own lock kit; do not field-fabricate. Padlocks keyed to the institution's key control programme; do not use a vendor master key. 

 Surge and transient protection 

 When the rule applies 

 Every security panel and every outdoor camera or device fed by copper conductor. Lightning strikes, utility transients, and load-switching surges all enter the system through the power feed, through outdoor copper conductors, and through any conductive cable crossing the building envelope. 

 The spec 

 
 Type 1 SPD at the service entrance (typically installed by the electrical contractor as part of the main electrical infrastructure) 
 Type 2 SPD at every security distribution panel, with audible alarm and dry-contact reporting to the security management system 
 Type 3 SPD at the point-of-use for any sensitive equipment (head-end servers, recording servers, central UPS): combined PDU and surge protection in a single rack-mount unit simplifies the installation 
 Coax surge protection on every outdoor IP camera line at the transition between exterior and interior (chapter 07) 
 Cat 6A surge protection on every copper pair entering the building from outdoor (chapter 07) 
 Consumer surge strips not used on production installs; joule rating decreases with every transient absorbed and there is no indication when protection is exhausted 
 

 Study Note 

 Eaton SPD Series Type 2 SPDs at the security distribution panel with audible alarm and dry-contact reporting. Eaton ePDU G3 with integrated surge protection at the rack point-of-use (combines PDU and SPD in a single 1U or 2U unit). For outdoor coax and Cat 6A, a CSA-listed in-line surge protector sized to the line; verify the protector's response time and clamping voltage match the cable's signal characteristics. 

 UPS sizing and runtime calculation 

 When the rule applies 

 Every security install with a head-end server, with IDF switches, with a central recording platform, or with any access control panel where the institutional spec calls for battery hold-over. The UPS sizing math is straightforward; the failure mode is most often that nobody did the math at all. 

 The spec 

 
 Calculate the worst-case continuous load: sum the nameplate VA of every device on the UPS, including the inrush worst-case for any device that cycles (PoE switches in particular cycle PoE ports during reboot) 
 UPS rated VA = continuous load × 1.25 (sizing factor) × 1.10 (future expansion margin) 
 UPS rated wattage = UPS rated VA × power factor (typically 0.9 for institutional-grade online UPS) 
 Runtime at full load calculated against the manufacturer's runtime curve at the actual measured load, not the nameplate load; validate the calculation against the manufacturer's published runtime table at the actual percentage load 
 Minimum runtime targets:: 30 minutes for general security loads (cameras, access panels, IDF switches) 4 hours for life-safety-related access (egress controllers, sallyport interlocks, detention) 24 hours for intrusion detection panels per ULC-S304 Until generator transfer for any load on the building emergency bus (typically 15 minutes minimum) 
 Online double-conversion (Class VFI) UPS for security loads; line-interactive (Class VI) acceptable only for non-critical loads 
 UPS monitoring: network card with SNMPv3 and email alerts to the institution's NOC or facility management system 
 Battery test scheduled monthly via the UPS's self-test feature, full battery discharge test annually 
 

 Worked example 

 An IDF with one Cat 9300-48UXM PoE++ switch drawing 1400 W maximum, one access control panel drawing 75 W, and one camera midspan injector drawing 60 W has a continuous load of 1535 W. Applying the sizing math: 1535 × 1.25 × 1.10 = 2110 W. At a 0.9 power factor, the UPS needs to be rated for 2110 / 0.9 = 2345 VA, so a 3000 VA online UPS is the appropriate size. At 70 percent load, a typical 3000 VA online UPS gives 12 to 15 minutes of runtime; for 30-minute runtime, add an external battery pack matched to the UPS series. 

 Study Note 

 Eaton 9PX series online double-conversion UPS for IDF and head-end work, 1000 VA through 11 kVA in rack-mount and tower form factors. Lithium-ion option available on 9PX Li-Ion variants for extended service life (10-year battery vs. 3 to 5 years for VRLA). Eaton 5PX series for smaller IDFs or non-critical loads. Eaton's Intelligent Power Manager software gives the SNMP and email alerting that institutional NOCs need. For larger head-end installations, Eaton 93PM modular UPS scales from 30 kW to 200 kW with hot-swappable power modules. 

 Voltage drop on door power circuits 

 When the rule applies 

 Every door power circuit from the supply to the lock. Voltage drop math is easier with a table than a calculator on every door; the values below are computed for copper at 25°C ambient, two-wire round trip, 5% maximum drop at the load. 

 The spec 

 
 12 VDC, 0.5 A load :: 30 m one-way: 18 AWG minimum 60 m one-way: 16 AWG minimum 
 12 VDC, 1.0 A load :: 30 m one-way: 16 AWG minimum 60 m one-way: 14 AWG minimum 
 12 VDC, 2.0 A load :: 30 m one-way: 14 AWG minimum 60 m one-way: 12 AWG minimum 
 24 VDC, 0.5 A load :: 60 m one-way: 18 AWG minimum 
 24 VDC, 1.0 A load :: 60 m one-way: 16 AWG minimum 
 24 VDC, 2.0 A load :: 60 m one-way: 14 AWG minimum 120 m one-way: 12 AWG minimum 
 Round up conductor size where the run exceeds 60 m at 12 VDC or 120 m at 24 VDC 
 Consider 24 VDC supply for any door more than 30 m from the panel; the conductor savings often justify the supply cost 
 

 The inrush calculation 

 Steady-state current is the published holding draw. Inrush current at energising is two to four times the holding value for the first 50 to 200 ms. Size the conductor and the supply for the inrush, not the steady state, on any project where multiple locks energise simultaneously (panic release, fire alarm interface, mass unlock). A bank of eight 700 mA maglocks on a single supply pulls 5.6 A steady-state and as much as 22 A on simultaneous release. Verify the supply can handle the inrush peak without folding into current-limit, or the doors release at different times during the cascade. 

 PoE budget for IP security devices 

 When the rule applies 

 Every PoE-powered device on the install. Switches publish a total PoE budget that is the sum of every port's draw across the switch. Run over budget and the switch starts cutting power to lower-priority ports in port order until the budget balances. 

 The spec 

 
 Class 0 / Type 1 / 802.3af : 0.44 to 12.95 W at the device, 15.4 W reserved at the port 
 Class 4 / Type 2 / 802.3at (PoE+) : up to 25.5 W at the device, 30 W reserved at the port 
 Class 6 / Type 3 / 802.3bt : up to 51 W at the device, 60 W reserved at the port 
 Class 8 / Type 4 / 802.3bt : up to 71.3 W at the device, 90 W reserved at the port 
 Typical fixed IP camera, indoor: Class 3 or 4 (12 to 25 W) 
 PTZ outdoor with heater: Class 6 or 8 (50 to 90 W) 
 Switch budget design at 75% maximum aggregate across all ports 
 Per-port priority assigned by VLAN: cameras and access readers high priority, building wireless and general-purpose lower 
 Worst-case PoE budget summed at design (chapter 11) and verified at commissioning (chapter 22) 
 

 Study Note 

 Cisco Catalyst 9300-48UXM for 48-port PoE++ at 1.4 kW budget. Aruba CX 6300M 48-port PoE Class 6 at 1.4 kW budget. Both deliver Class 6 (60 W) on every port simultaneously up to the switch budget. For IDF closets with mixed PoE and non-PoE devices, native PoE on every port is the field default; mid-span injectors are not used at scale because they complicate the documentation and the spare-port budget. 

 Dual-cord PDUs and rack power distribution 

 When the rule applies 

 Every rack in every IDF and the head-end equipment room. Rack power is the layer below the equipment power supply; the rack's PDU is what every device plugs into. 

 The spec 

 
 Two separately-fed PDUs in every rack, each fed from a separate branch circuit on a separate panel where the institutional design supports it 
 PDU outlet count sized to support the maximum equipped rack PDU plus 25% spare outlets 
 PDU outlet type matched to equipment plug types: NEMA 5-15R and 5-20R for general 120 V equipment, C13 / C19 for IEC-cord equipment, C13 / C19 for high-current servers 
 Vertical (0U) PDUs preferred for new installs to save rack U-space for active equipment 
 Per-outlet metering and remote switching where the institutional NOC manages power remotely 
 Per-PDU current monitoring with alarm threshold at 80% of the PDU rating 
 Each PDU labelled with the source circuit and the served equipment (chapter 06) 
 

 Study Note 

 Eaton ePDU G3 metered or switched, depending on the institutional requirement. Metered for monitoring without remote switching. Switched for remote outlet-by-outlet control from the institutional NOC. Vertical 0U form factor in 42U racks. Eaton ePDU Basic for non-monitored applications where the institution does not require per-outlet visibility. 

 Generator and emergency-power coordination 

 When the rule applies 

 Buildings with emergency or standby power. The institution's emergency power design dictates which loads transfer; the security install confirms the right loads land on the right bus and tests the transfer at commissioning. 

 The spec 

 
 Security loads on the emergency or standby bus identified in writing in the design narrative 
 Head-end servers, central UPS, IDF switches, and door power supplies on the emergency bus where the project includes one 
 Cameras on the emergency bus only where institutional policy requires it; otherwise on the building UPS 
 Transfer time: ATS transfer to generator typically 8 to 12 seconds; head-end UPS sized to ride through with margin 
 Generator-side breaker coordination: security panel breakers sized so generator overcurrent protection does not trip the security panel during normal transfer 
 Generator-fed circuits identified on the panel directory with an orange "GEN" sticker per chapter 06 
 Transfer test at commissioning: simulate utility loss, observe ATS transfer, verify every security device rides through, verify UPS does not exhaust, verify return transfer when utility restores 
 

 The load-shed mismatch 

 Security UPS sized for the building outage but not for the transfer time, plus one of the IDFs accidentally fed from a non-emergency panel. The generator transfer happens, the building lights come back, but the IDF in the basement was never on the emergency panel and stays dark for the full duration. Cameras in that pathway go offline and the recording for the incident has a 30-minute gap. Verify every IDF, every camera midspan, every door supply against the emergency-power schedule at the design review. 

 Power identification at the receptacle and panel 

 When the rule applies 

 Every receptacle, every panel, every breaker that serves a security load. Identification is the difference between fast restoration and an hour of finding the right breaker during an outage response. 

 The spec 

 
 Every security-dedicated receptacle labelled at the faceplate with panel designation and circuit number 
 Every breaker entry in the panel directory identifies the served device (not just "security") 
 UPS-fed circuits identified with a green sticker or coloured nameplate on the receptacle and in the panel directory 
 Generator-fed circuits identified with an orange sticker 
 Surge-protected circuits identified with an SPD note in the panel directory 
 Lockable breakers identified in the panel directory with the lock identifier 
 Receptacle colour convention (one-time choice per institution, then consistent across all projects):: Standard 5-20R: ivory or white (general) Hospital-grade: green dot on face Isolated ground: orange triangle on face UPS-fed: red receptacle body (some institutions) Generator-fed: orange receptacle body (some institutions) 
 

 Power is the foundation. Dedicated circuits, breaker locks, point-of-use surge protection, sized UPS with documented runtime, dual-cord PDUs from separately-fed circuits, generator coordination verified at commissioning, and every receptacle and breaker labelled. Eaton is the field default across most of the categories, UPS, receptacles, ePDU, breaker locks, surge protection, and the parts integrate cleanly because they come from one manufacturer. Get this layer right and the security system rides through every foreseeable failure. Get it wrong and the first storm pulls the institution offline at exactly the moment the security record matters most.

================================================================

## Grounding and bonding

URL: https://hans.study/standards-guidance/cssir-04-grounding-bonding/
Type: kb
Date: 2026-05-10
Description: Grounding and bonding for Canadian institutional security installs. CEC Section 10, CSA T607 / ANSI-J-STD-607-A, TMGB and TGB sizing, telecommunications bonding backbone (TBB), rack bonding, cable tray bonding, equipment bonding, ground resistance measurement.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Grounding and bonding is the invisible layer that makes every other layer work. Surge protection assumes the ground path exists. Power supplies assume the chassis is bonded. Network equipment assumes the rack is grounded. Cable tray assumes the bond is continuous. Skip any of these and the install passes commissioning, then fails after the first thunderstorm or the first significant power transient. Get the ground path right and the rest of the install survives the next 20 years of building electrical events. 

 The two governing documents 

 When each applies 

 Two sets of rules govern security install grounding. The CEC covers the building's grounding electrode system, the equipment grounding conductors, and the bonding of metal raceways. CSA T607 (and its ANSI parallel J-STD-607-A) covers the telecommunications-specific grounding infrastructure: the TMGB, the TGB, the TBB, and the equipment bonding required for sensitive telecom and security electronics. The work follows both, simultaneously, on every project. 

 The standards in detail 

 
 CEC Section 10 : Grounding and bonding (applies to every install in Canada) 
 CSA T607 : Commercial Building Grounding and Bonding Requirements for Telecommunications 
 ANSI/TIA-607-D : Generic Telecommunications Bonding and Grounding (the US parallel, also referenced in Canadian institutional specifications) 
 ANSI/J-STD-607-A : Joint Standard for Commercial Building Grounding and Bonding Requirements for Telecommunications 
 

 Study Note 

 The electrical contractor installs the building's grounding electrode system (the rods or the plate, the bonding conductors to the service equipment, and the equipment grounding conductors in every branch circuit). The security integrator works downstream of that: bonding the TGB to the building ground, bonding the security rack to the TGB, and bonding every device chassis to the equipment ground. Where the electrical contractor's work ends and the security integrator's work begins is in the project specification. Read it carefully at design. 

 Telecommunications Main Grounding Busbar (TMGB) 

 When the rule applies 

 Every commercial building's telecommunications space (typically the main equipment room at the service entrance) gets one TMGB. The TMGB is the single point where the building's telecommunications grounding system connects to the building's electrical grounding system. 

 The spec 

 
 Material: solid copper, tinned for corrosion resistance 
 Dimensions: 6.3 mm × 100 mm minimum (1/4" × 4"), 305 mm to 610 mm (12" to 24") long 
 Pre-drilled with NEMA-pattern holes for two-hole compression lugs 
 Mounted on insulating standoffs, 50 mm (2") minimum standoff from the wall 
 Mounted on a non-conductive backboard (typically fire-rated plywood per chapter 05) 
 Located in the building's main equipment room, accessible without ladders or tools 
 Bonded to the building's electrical grounding electrode system with a conductor sized at minimum #2/0 AWG (or larger where the conductor distance exceeds 6 m) 
 Bonded to the building structural steel where exposed steel is present near the TMGB 
 Permanently labelled "TMGB" with the equipment room designation 
 

 Study Note 

 Panduit GB4 series tinned copper busbar (4" × 1/4" × 12" to 20", pre-drilled NEMA pattern) for the TMGB. Two-hole copper compression lugs (Panduit LCC-W series) sized to the conductor. Insulated standoffs from the same manufacturer's accessory line. Green-jacketed insulated stranded copper bonding conductor sized per the TMGB-to-electrical-ground table. 

 Telecommunications Grounding Busbar (TGB) 

 When the rule applies 

 Every telecommunications space in the building other than the TMGB's location. IDF closets, equipment rooms, dedicated security rooms, every floor's telecom closet. One TGB per telecom space. 

 The spec 

 
 Material: solid copper, tinned for corrosion resistance 
 Dimensions: 6.3 mm × 50 mm minimum (1/4" × 2"), 305 mm (12") long 
 Pre-drilled with NEMA-pattern holes for two-hole compression lugs 
 Mounted on insulating standoffs, 50 mm (2") minimum standoff from the wall 
 Located in the telecom space, accessible without ladders or tools 
 Bonded to the TMGB via the Telecommunications Bonding Backbone (TBB; sized per the section below) 
 Bonded to building structural steel where exposed steel is present in the telecom space 
 Permanently labelled "TGB" with the room designation 
 

 Study Note 

 Panduit GB2 series tinned copper busbar (2" × 1/4" × 12", pre-drilled NEMA pattern) at every TGB location. Same accessory line as the TMGB to maintain compatible lug hardware and standoff dimensions across the building. 

 Telecommunications Bonding Backbone (TBB) sizing 

 When the rule applies 

 Every TGB in every telecom space is connected to the TMGB by the TBB. ANSI/J-STD-607-A and CSA T607 size the TBB by the longest one-way distance from any TGB back to the TMGB. Bigger conductor, shorter equivalent impedance, faster transient discharge. 

 The spec 

 
 TBB length up to 4 m (13 ft): minimum #6 AWG 
 TBB length 5 to 6 m (14 to 20 ft): minimum #4 AWG 
 TBB length 7 to 8 m (21 to 26 ft): minimum #3 AWG 
 TBB length 9 to 10 m (27 to 33 ft): minimum #2 AWG 
 TBB length 11 to 13 m (34 to 41 ft): minimum #1 AWG 
 TBB length 14 to 16 m (42 to 52 ft): minimum #1/0 AWG 
 TBB length 17 to 20 m (53 to 66 ft): minimum #2/0 AWG 
 TBB length over 20 m (66 ft): minimum #3/0 AWG 
 TBB installed as a continuous conductor without splices; where a splice is unavoidable, use a copper compression splice with a manufactured insulating cover 
 TBB not run inside metal conduit (the conduit creates a magnetic-coupling impedance loop) 
 Where multiple TBBs run in a building, interconnect them at the top floor and every third floor with a Grounding Equalizer (GE) conductor sized per the TBB table 
 TBB jacket colour: green or green-with-yellow-stripe per CEC convention 
 

 Worked example 

 A four-floor building has TGBs on floors 1, 2, 3, and 4. The TMGB is on floor 1, in the main equipment room. The longest one-way distance from any TGB to the TMGB is from the floor-4 TGB, which is roughly 18 m of cable run measured (not vertical distance, but the actual cable path through the riser and across the floor). The TBB conductor size for 18 m is #2/0 AWG. 
 The TBB runs as a single conductor from the TMGB up the riser to floor 4, with intermediate connections (tapped, not cut) at the floor-2 and floor-3 TGBs. Multiple-TBB interconnect (GE conductor) at the top floor connects the conductor back to the building grounding system in case of a multi-path lightning event. 

 Study Note 

 Green-jacketed insulated stranded copper bonding conductor sized per the table. Tap kits (Panduit HTAP HTWC series) for splicing the TBB into the TGB drops without cutting the backbone. Two-hole copper compression lugs (Panduit LCC-W series) at every busbar termination. The TBB is run inside an open cable tray or J-hook pathway, not in metal conduit; metal conduit defeats the purpose by creating an impedance loop. 

 Rack and cabinet equipment bonding 

 When the rule applies 

 Every rack in every telecom space. The rack itself, the equipment in the rack, and the cable tray feeding the rack all bond to the rack ground busbar. The busbar bonds to the TGB. 

 The spec 

 
 Full-length rack ground strip on the rear side rail of every rack, bonded to the rack frame with thread-forming screws for metal-to-metal contact 
 Paint-piercing grounding washers under the head of every bolt where rack sections fasten together, on both sides, to ensure electrical continuity through painted surfaces 
 Rack ground busbar at the top of every rack, with #6 AWG bonding jumper to the TGB 
 Every chassis-mounted equipment ground (minimum #6 AWG) bonded to the rack ground busbar at the rear of the rack 
 ESD protection ports on both the front and rear vertical rails at 1220 mm (48") AFF, with ESD identification stickers above 
 Cable tray entering the rack bonded to the rack ground busbar with a #6 AWG jumper at the tray-to-rack transition 
 Bonding measurements recorded at commissioning:: Less than 1 ohm from any rack chassis to the TGB Less than 5 ohm from the TGB to the building ground reference 
 

 The paint-piercing requirement 

 Powder-coated and painted rack frames are not electrically continuous out of the box. The paint is an insulator. Paint-piercing washers bite through the coating at the bolt and create the metal-to-metal contact that the bonding system needs. Skip them and the rack passes visual inspection but fails the bonding measurement at commissioning. Every rack section bolts together with paint-piercing washers under the bolt head and between the nut and rack, on both sides. 

 Study Note 

 Panduit RGS134 full-length rack ground strip on the rear side rail. Panduit RGW series paint-piercing washers at every rack-section bolt. Panduit RGRB rack ground busbar at the top of every rack, with a #6 AWG green-jacketed jumper to the TGB. Panduit RGEJ696 equipment bonding jumpers (#6 AWG, terminated with two-hole lugs) for chassis-to-busbar connections. Panduit RGESD-1 ESD jacks on front and rear rails at 1220 mm AFF. The Panduit grounding system parts catalogue is built around exactly this set of connections; pick the kit at order and verify all parts are present at receiving. 

 Cable tray bonding 

 When the rule applies 

 Every cable tray on the install. Cable tray is electrically continuous only if every joint is bonded; the manufacturer's hardware does some of this, but the bond has to be verified, not assumed. 

 The spec 

 
 Cable tray bonded to the TGB with a minimum #6 AWG bonding conductor at the nearest TGB 
 Tray sections bonded across every splice with a manufacturer's listed bonding clamp or jumper 
 Tray-to-rack transitions bonded with a #6 AWG jumper at the transition 
 Tray-to-conduit transitions: the conduit is bonded to the tray via the conduit's own equipment grounding conductor, with the tray functioning as an extension of the conduit's ground path 
 Bonding measurements at commissioning: less than 1 ohm from any tray section to the TGB 
 Tray bonding documented on the as-built grounding drawing 
 

 Study Note 

 Manufacturer's listed bonding clamps or jumpers at every tray splice (Cablofil and Panduit both publish a bonding kit for their wire-mesh tray product lines; use the matching kit). Where the tray manufacturer does not publish a bonding part, a #6 AWG green-jacketed jumper with two-hole lugs terminated at both sides of the splice. Test continuity at every splice with a low-impedance ohmmeter before sign-off. 

 Equipment bonding to the chassis 

 When the rule applies 

 Every piece of network and security equipment in the rack. The equipment manufacturer publishes the chassis bonding point on the equipment data sheet; this is the lug location on the chassis where the rack bonding conductor terminates. 

 The spec 

 
 Minimum #6 AWG bonding conductor from the equipment chassis ground lug to the rack ground busbar 
 Conductor terminated with a two-hole compression lug at the equipment end, sized to the manufacturer's ground stud 
 Conductor terminated with a two-hole compression lug at the busbar end, with NEMA-standard hole spacing 
 Conductor routed on the rear of the rack, not running through the equipment 
 Conductor jacket green or green-with-yellow-stripe per CEC convention 
 Conductor length kept as short as practical; minimize bends and avoid coils that increase impedance 
 Chassis bonding does not substitute for the equipment's safety ground conductor in the power cord; both are required 
 

 Study Note 

 Pre-fabricated bonding jumpers (Panduit RGEJ696 or equivalent), #6 AWG with two-hole lugs at both ends, in standard lengths (300 mm, 450 mm, 600 mm). Custom-cut jumpers terminated on site with Panduit LCC-W series two-hole lugs and a hydraulic crimper sized to the lug. Verify the chassis ground stud on every device before ordering, most are M6 or 1/4-20, but some manufacturers use M5 or M8. 

 Equipotential bonding in high-EMI environments 

 When the rule applies 

 Equipment rooms near elevators, near large motors, near medical imaging equipment, near radio transmitters, near electrical service equipment. Standard rack bonding may not be sufficient in these environments; equipotential bonding ties every metal surface in the room to a common reference plane. 

 The spec 

 
 Continuous bonding plane (signal reference grid) under or behind the equipment racks where the project specification requires 
 Bonding plane bonded to the TGB at multiple points (a grid, not a single connection) 
 Every rack, every cable tray, every metal pathway in the room bonded to the bonding plane 
 Every metal building feature in the room (HVAC ducting, structural beams, sprinkler piping) bonded to the bonding plane 
 The bonding plane is not a substitute for the equipment grounding conductor in branch circuits; the safety ground is still required 
 

 Study Note 

 Standard rack bonding handles most institutional environments. Equipotential bonding adds cost and is worth it in three specific cases: data centers with sensitive analytics, medical imaging suites where EMI sensitivity is unusually high, and broadcasting or research facilities with RF-sensitive equipment. Outside those, the standard TGB-and-rack approach is sufficient and the equipotential plane is over-engineering. 

 Ground resistance measurement 

 When the rule applies 

 At commissioning, and at the institution's periodic verification interval (typically annual on critical-infrastructure facilities, every five years on general institutional). Ground resistance measurement validates that the grounding electrode system meets the design intent. 

 The spec 

 
 Building grounding electrode resistance: 25 ohms maximum per CEC 10-700 (single rod), 5 ohms or less recommended for institutional work 
 TMGB to building grounding electrode: less than 5 ohms 
 TGB to TMGB (via the TBB): less than 1 ohm 
 Rack chassis to TGB: less than 1 ohm 
 Cable tray to TGB: less than 1 ohm 
 Equipment chassis to rack busbar: less than 0.5 ohm 
 Measurement using a 3-pole or 4-pole earth resistance tester (fall-of-potential method) for building grounding electrode; low-impedance ohmmeter for bonding measurements 
 Measurements documented in the commissioning report (chapter 22) with the test instrument's calibration date and the technician's identification 
 

 Study Note 

 Fluke 1625-2 Earth Ground Tester for building grounding electrode resistance and 3-pole / 4-pole fall-of-potential measurements. Fluke 1587 FC Insulation Multimeter for bonding measurements (low-impedance ohms). The institution typically has a preferred test instrument family that integrates with their preventive maintenance system; verify and align at the design phase. 

 Grounding and bonding is the layer below every other layer. Bond every rack to a TGB, bond every TGB to the TMGB via a sized TBB, bond every cable tray and every device chassis, use paint-piercing washers at every painted rack joint, verify continuity at less-than-1-ohm at commissioning. Panduit's grounding system parts integrate cleanly across busbars, strips, washers, jumpers, and ESD ports; pick the matching kit at order. Do this work right and the surge protection actually surges, the network actually grounds, and the system rides through every electrical event the building sees over the next twenty years.

================================================================

## Firestopping

URL: https://hans.study/standards-guidance/cssir-05-firestopping/
Type: kb
Date: 2026-05-10
Description: Firestopping for Canadian institutional security installs. ULC-S115 systems, fire-rated wall and floor penetrations, smoke barriers, 3M and Hilti firestop products, putty pads, intumescent sealants, foam, identification labels.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Firestopping is the layer the inspector reads off the wall. Every cable and every conduit that crosses a fire-rated wall, fire-rated floor, or smoke barrier needs a listed firestop system that matches the assembly's hour rating. The system is the combination of the penetrating item, the surrounding construction, and the listed firestop assembly. Skip the system, mismatch the rating, or fail to identify the install and the AHJ fails the inspection regardless of how much sealant went into the hole. 

 The governing standards 

 When the standards apply 

 Every penetration through a fire-rated assembly. The standards below define what counts as a listed firestop system and how to identify it in the field. 

 The standards in detail 

 
 CAN/ULC-S115 : Standard Method of Fire Tests of Firestop Systems. The Canadian test method. Every ULC-listed firestop system carries a system number that references S115. 
 ASTM E814 / UL 1479 : US-equivalent test methods. Often referenced on cross-border projects. 
 CAN/ULC-S101 : Standard Methods of Fire Endurance Tests of Building Construction and Materials. The fire-rating test method that determines the assembly's hour rating. 
 NBC and provincial building codes : define which assemblies are fire-rated and at what hour rating 
 ASTM E2174 : Standard Practice for On-Site Inspection of Installed Firestops. The inspector's checklist; useful to the integrator as the install reference. 
 

 Selecting the right firestop system 

 When the rule applies 

 Every fire-rated penetration on the project. The system is the combination of penetrating item, surrounding construction, and listed assembly. The ULC system number on the listing has to match the as-installed condition exactly. A 2-hour wall has to use a 2-hour-rated system. A metallic conduit has to use a system listed for metallic conduit. A cable bundle has to use a system listed for cable bundles, not for conduit. 

 The spec for common security work penetrations 

 
 Single conduit through fire-rated wall : ULC system W-L-1003 family (intumescent sealant in annular space) or equivalent. Metallic conduit. Opening sized 25 mm larger than conduit OD. 
 Cable bundle through fire-rated wall : ULC system W-L-3163 family (intumescent sealant with mineral wool backing) or equivalent. Cable fill not exceeding 30% of opening. 
 Cable tray through fire-rated wall : ULC system W-L-7019 family (intumescent spray with mineral wool damming) or equivalent. Tray bonded across the penetration (chapter 04). 
 Single conduit through fire-rated floor : ULC system F-A-1031 family (intumescent sealant with mineral wool) or equivalent. 
 Riser slot through fire-rated floor : ULC system F-A-3015 family (composite sheet with mineral wool damming, intumescent caulk seal on top) or equivalent. 
 Outlet box back-to-back through fire-rated wall : moldable putty pad wrapped around the outside of the box before drywall installation. 
 Annular space at sleeve : minimum 12 mm (1/2") all around, sealed with the listed intumescent product. 
 System number, hour rating, and inspector-readable label affixed to the wall or floor within 150 mm of every penetration 
 

 Study Note 

 3M Fire Barrier products are the field default across most institutional projects. 3M Fire Barrier Sealant CP 25WB+ (red, intumescent, up to 4-hour rating, ULC-S115 listed) for general through-penetrations. 3M Fire Barrier Sealant IC 15WB+ (yellow, intumescent, up to 3-hour, latex-based, sound-rated to STC-54) where acoustic performance matters. 3M Fire Barrier Moldable Putty Pad MP+ for back-to-back outlet box protection, sized for the box dimension (4" and 5" variants). 3M FireDam Spray 200 for large penetrations and joint applications. 3M Fire Barrier Composite Sheet CS-195+ for riser slots and large cable openings. 3M Fire Barrier Rated Foam FIP 1-Step for annular space fill where caulk is not appropriate. 
 Hilti's product line is the alternative on Hilti-standardised projects: Hilti FS-ONE MAX intumescent sealant, Hilti CP 606 flexible firestop sealant, Hilti CP 658 firestop block. Pick one manufacturer per project and stay inside their system listings; do not mix sealants between manufacturers within a single penetration. 

 Penetration sizing and annular space 

 When the rule applies 

 Every firestop install. The annular space (the gap between the penetrating item and the wall opening) is part of the listed system. Wrong gap and the system listing does not apply. 

 The spec 

 
 Minimum 12 mm (1/2") clear annular space all around the penetrating item, unless the system listing specifies otherwise 
 Maximum annular space per the system listing (typically 50 mm or 2", varies by system) 
 Opening shape: round openings preferred for round penetrations; square or rectangular openings for cable trays and large multi-cable bundles 
 Opening size: 25 mm larger than the conduit OD for single-conduit penetrations 
 Mineral wool or other listed damming material installed to the depth specified in the system listing before the firestop product is applied 
 Penetrating item rigidly supported on both sides of the assembly before firestop installation; firestop is not a structural support 
 

 Fire-rated walls versus smoke barriers 

 When the rule applies 

 The building code distinguishes between fire-rated assemblies (rated for fire spread) and smoke barriers (rated for smoke spread). Some assemblies are both. The firestop system has to address whichever rating the assembly carries. 

 The two ratings and how they differ 

<DefList>
 <dt>Fire rating</dt>
 <dd>The assembly's resistance to fire spread for a specified time (1 hour, 2 hour, 3 hour, 4 hour). Tested under CAN/ULC-S101. Defines which firestop systems are eligible for the penetration.</dd>

 <dt>Smoke rating</dt>
 <dd>The assembly's resistance to smoke spread. Some assemblies are smoke-rated without being fire-rated (some corridor walls, some elevator-shaft partitions). Smoke-rated firestop systems use products that maintain a smoke seal even before intumescent expansion.</dd>

 <dt>Combined fire and smoke barrier</dt>
 <dd>Most institutional building's fire-rated walls are also smoke barriers. The firestop system has to be listed for both. Many 3M and Hilti systems carry dual listings for this case.</dd>
</DefList>

 Study Note 

 The architectural drawings carry the fire and smoke rating for every wall. Read them at design and confirm at rough-in. Smoke-rated assemblies often catch integrators by surprise because they look identical to non-rated drywall partitions. The corridor wall in an institutional building is almost always a smoke barrier; assume rated unless the architect confirms otherwise in writing. 

 Outlet box penetrations and back-to-back boxes 

 When the rule applies 

 Every outlet box in a fire-rated wall. The box itself disrupts the wall's fire resistance unless it is wrapped or pad-protected. 

 The spec 

 
 Moldable firestop putty pad applied to the outside of every metal outlet box installed in a fire-rated wall, before the drywall is hung 
 Putty pad sized to fully cover the box exterior (4" pad for 4" boxes, 5" pad for 4-11/16" boxes) 
 Box-to-box separation: minimum 600 mm (24") horizontally for boxes on opposite sides of the same wall (no back-to-back boxes) 
 Where 600 mm separation cannot be achieved, both boxes wrapped with putty pad, with the assembly listing verified for the box-to-box configuration 
 Through-wall boxes prohibited in fire-rated assemblies 
 Cover plates installed before paint or wall finish to protect the firestop assembly during construction 
 

 Study Note 

 3M Fire Barrier Moldable Putty Pad MP+ in the 4" or 5" size to match the box. The pad presses onto the back of the box and stays in place during drywall installation. Verify pad coverage of all six box faces (back, two sides, two ends, front) before the drywall goes up; the wrapped box gets buried and inspection becomes destructive afterwards. 

 Through-floor penetrations and riser slots 

 When the rule applies 

 Vertical conduit and cable runs between floors. Every floor penetration is a fire-rated penetration unless the floor is non-rated (rare in institutional buildings; check the architectural drawings). 

 The spec 

 
 Single conduit through fire-rated floor: ULC F-series system matching the floor rating, with mineral wool damming and intumescent sealant 
 Riser slot for multiple cables: composite sheet system (steel-clad sheet with intumescent backing) sized to the slot dimension, with mineral wool damming below and intumescent caulk seal on top 
 Cable tray through fire-rated floor: cable-tray-specific firestop system, with cable tray ground bonding maintained across the penetration (chapter 04) 
 Curb above the floor: 50 mm (2") minimum sleeve protrusion above finished floor at the upper level, to keep water from entering the riser 
 Firestop applied after all cable is installed; the slot or sleeve itself is not a firestop 
 Inspection access maintained: the firestopped penetration is reachable for visual inspection by the AHJ inspector and by future maintenance 
 

 Study Note 

 3M Fire Barrier Composite Sheet CS-195+ for riser slots: steel-clad sheet, intumescent core, available in 24" × 24" and larger sizes. Mineral wool batt damming below the sheet, intumescent caulk (3M CP 25WB+) sealing the top edge. For single-conduit through-floor penetrations, ULC F-A-1031 system using 3M CP 25WB+ in the annular space with mineral wool backing. 

 Identification and inspector-readable labelling 

 When the rule applies 

 Every firestopped penetration on the project. The AHJ reads the ULC system number off the label, reads the hour rating off the label, and verifies the as-built condition matches the listing. Without inspector-readable identification, the firestop fails inspection regardless of how well it was installed. 

 The spec 

 
 Permanent firestop identification label affixed to the wall or floor within 150 mm (6") of every firestopped penetration 
 Label content: ULC system number, hour rating, manufacturer name, installer name and date, contractor licence number 
 Label material: thermal-transfer or laser-printed adhesive vinyl, minimum 50 mm × 100 mm (2" × 4"), readable at 1.5 m distance 
 Label colour: red text on white background, with the hour rating in bold 
 Labels affixed before final paint or wall covering; where wall covering hides labels, additional labels affixed adjacent to the covering with a directional arrow to the penetration 
 As-built drawing: every firestopped penetration identified on a coordinated firestop drawing with system number, installer, and date 
 Firestop drawing reviewed by the AHJ and the consulting engineer at commissioning 
 

 Study Note 

 Thermal-transfer printed adhesive vinyl labels from a DYMO Rhino or Epson LabelWorks PX printer. The 3M firestop products carry a recommended label template; pull the template from 3M's documentation, fill in the project-specific fields (system number, installer name, date), and print to vinyl. Affix within 150 mm of the penetration and verify legibility from across the room. 

 Repair and modification of existing firestops 

 When the rule applies 

 Any retrofit or renovation that disturbs an existing firestopped penetration. The integrator who pulls cable through the existing seal owns the resealing. 

 The spec 

 
 Remove the damaged seal completely; do not patch over existing material 
 Inspect the penetration for any cable or conduit damage that may have occurred during the breach 
 Reseal from scratch using a current ULC-S115 listed system matching the assembly's rating 
 The replacement system may be a different listing from the original (manufacturers update systems and listings); use a current listing, not an obsolete one 
 Document the repair on the firestop drawing with the new system number and date 
 Re-label the penetration with the new system number 
 

 Study Note 

 If you pulled the cable through that hole, you own the seal. There is no "the other trade will come back and fix it" on a fire-rated penetration; the AHJ inspects the penetration as a single item and holds whoever opened it last responsible for closing it. Build the resealing into your scope at design and charge for it appropriately. 

 Firestopping is the inspector's checklist. Pick the ULC-S115 listed system that matches the assembly's fire and smoke rating. Install per the system listing exactly. Identify with a permanent inspector-readable label within 150 mm of every penetration. Document every penetration on the firestop drawing. 3M Fire Barrier products are the field default for most institutional work, with Hilti as the alternative on Hilti-standardised projects. Pick one manufacturer per project and stay inside their system listings. Skip the system, mismatch the rating, or fail to identify the install and the AHJ fails the inspection regardless of how much sealant went into the hole.

================================================================

## Identification and labelling

URL: https://hans.study/standards-guidance/cssir-06-identification-labelling/
Type: kb
Date: 2026-05-10
Description: Identification and labelling for Canadian institutional security installs. ANSI/TIA-606-D, cable label format, patch panel labelling, conduit colour banding, rack and equipment lamacoid plates, panel directories, asset tagging.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Identification is the difference between an install the next technician can maintain and an install the next technician has to reverse-engineer with a continuity tester. Every cable, every device, every conduit, every panel circuit, and every rack gets identified at install. The format is consistent across the project, the identifier matches the as-built drawings, and the label material lasts as long as the install. Skip the labelling and the building's first major service event takes ten times longer than it should. 

 The governing standard 

 When the standard applies 

 Every structured cabling install in Canada. ANSI/TIA-606-D is the administration standard for telecommunications labelling; CSA T528 is the Canadian parallel. The institutional spec almost always references one or the other; both produce the same field result. 

 The four classes of administration 

<DefList>
 <dt>Class 1 administration</dt>
 <dd>Single-room single-equipment installs (small offices, retail). Cable identifier, patch panel port, outlet location. Minimum administration.</dd>

 <dt>Class 2 administration</dt>
 <dd>Single-building multi-room installs. Adds room identifier and floor identifier. The institutional security project minimum.</dd>

 <dt>Class 3 administration</dt>
 <dd>Multi-building campus. Adds building identifier. Used on campus security installs.</dd>

 <dt>Class 4 administration</dt>
 <dd>Multi-site, multi-organisation. Adds site identifier. Used on multi-facility institutional security programmes (transit, healthcare networks, government regions).</dd>
</DefList>

 Cable label format 

 When the rule applies 

 Every cable on every install. Label at both ends, within 150 mm (6") of the termination, matching the as-built cable schedule. 

 The spec 

 
 Cable identifier composed of: building code (2-character alpha), floor (2-digit numeric), TR/IDF designator (alphanumeric), patch panel number, port number 
 Example: AB-02-IDF1-PP01-024 (Building AB, Floor 02, IDF 1, Patch Panel 01, Port 024) 
 Label at both ends of every cable, within 150 mm (6") of the termination 
 Label format consistent across all cables on the project; project administrative document defines the identifier scheme 
 Identifier matches the as-built drawing and the cable schedule exactly 
 No abbreviations beyond the project's defined scheme 
 

 Study Note 

 The project administrative document is the contract piece that defines the identifier scheme. Lock it down at design before any cable is pulled. Changing the scheme mid-project is expensive: every label gets re-printed, every drawing gets updated, every patch panel gets re-labelled. Get the scheme right at design and the install proceeds without rework. 

 Cable label material 

 When the rule applies 

 Every cable label on every install. The label has to survive the install (pulling, pulling tension, abrasion against conduit), survive the building's operational life (temperature, UV in some pathways, chemical exposure in mechanical rooms), and stay readable to the next technician. 

 The spec 

 
 Thermal-transfer printed vinyl with self-laminating overlap: the printed area wraps once around the cable and the overlap covers the print 
 Label colour: white background with black thermal-transfer printing (highest contrast, longest read life) 
 Heat-shrink sleeves in lieu of self-laminating wraps on cables that need higher abrasion or chemical resistance (conduit transitions, outdoor cables, plenum returns above kitchens) 
 Label diameter: sized to the cable; 1/4" or 1/2" for Cat 6A and similar; 1" for trunk cables 
 Label print durability: thermal-transfer or laser; standard inkjet not used (fades, smears under heat) 
 Pre-printed paper labels covered with clear tape: not used on institutional installs 
 Hand-written labels with permanent marker: not used on institutional installs 
 

 Study Note 

 DYMO Rhino 6000XL or 5200 industrial label printer with self-laminating vinyl label cartridges (1/2" and 3/4" widths) for cable wraps. DYMO Rhino heat-shrink tube cartridges (3:1 ratio) for outdoor and chemical-exposure cables. Epson LabelWorks PX LW-PX900 as the equivalent on Epson-standardised projects. Panduit MP100 or MP300 printers with Panduit-branded label media for high-volume datacenter and IDF work. Pick one printer family per project and stay in their consumable line; cartridges from different manufacturers do not interchange. 

 Patch panel and rack-side labelling 

 When the rule applies 

 Every patch panel and every rack on the install. The patch panel face is where the technician is going to spend most of their service time; the labelling is the first thing they read. 

 The spec 

 
 Every port labelled at the panel face with the port number and the far-end destination summary 
 Port label format consistent across all panels on the project 
 Panel-side label below or above the port window, depending on the panel manufacturer's label area 
 Panel itself labelled with the panel designation (PP01, PP02, etc.) at the top edge 
 Patch cord labels at both ends, matching the patch panel port and the device port to which they connect 
 Outlet face labels: faceplate-mounted printed label or engraved icon with the outlet identifier matching the cable label 
 Rack and equipment labels: lamacoid (engraved phenolic) plate mounted on the rack frame and the equipment chassis with the asset identifier 
 

 Conduit and pathway colour banding 

 When the rule applies 

 Every conduit on the install, plus every cable tray and surface raceway run. The colour band lets the AHJ inspector, the next integrator, and the facility staff see at a glance which system the pathway serves. 

 The spec 

 
 Green : communications and structured cabling 
 Blue : security signal (access control, video, intrusion) 
 Red : fire alarm 
 Orange : emergency power 
 No colour band : normal power (default) 
 Band width: minimum 50 mm (2") at every termination, every transition point, and every 6 m (20 ft) of exposed run 
 Band paint: industrial-grade enamel or vinyl tape rated for the conduit environment (indoor enamel or outdoor vinyl) 
 Colour band supplemented with a printed label at every termination identifying the conduit's destination, the system it serves, and the cable count it carries 
 

 Study Note 

 Vinyl tape is faster to apply and easier to remove if the system designation changes. Paint is more permanent and resists wear better in mechanical rooms. I use vinyl tape on most institutional installs (3M Scotch 35 colour-coding tape, 1" or 2" width depending on conduit size). Paint on conduit in unfinished mechanical spaces where vinyl will not hold up to the environment. 

 Rack and equipment lamacoid plates 

 When the rule applies 

 Every rack, every major piece of equipment (switch, server, UPS, access control panel, recorder). The lamacoid plate is the permanent identifier that survives the install's life and lets the asset tag track equipment in the institutional CMMS. 

 The spec 

 
 Material: engraved phenolic plate (lamacoid), two-ply, white face on black core (or per institutional standard) 
 Dimensions: 75 mm × 25 mm (3" × 1") for equipment; 100 mm × 50 mm (4" × 2") for rack frame identification 
 Engraving: laser or rotary engraver with the institutional template 
 Content: asset identifier, equipment description, panel/circuit reference, install date 
 Mounting: mechanical fasteners (screws, rivets, or stainless adhesive backing); pressure-sensitive adhesive only where mechanical fastening is not possible 
 Equipment lamacoid: mounted on the equipment front faceplate where visible without opening the rack 
 Rack lamacoid: mounted on the top rail of the rack frame, readable from the front 
 

 Study Note 

 White-on-black engraved lamacoid (2-ply phenolic) is the institutional default; some institutions use black-on-yellow for emergency equipment or red-on-white for fire-alarm-related equipment. The institution's lamacoid template gets locked at design. Engraving is outsourced to a local trophy shop on most projects; budget 1 to 2 weeks lead time for the engraving plus the mounting hardware. 

 Panel directories and breaker identification 

 When the rule applies 

 Every electrical panel that feeds a security load. The panel directory is what the next person reads during a service call; an accurate, current directory turns a 20-minute breaker hunt into a 30-second one. 

 The spec 

 
 Panel directory updated at every change (every new circuit, every retired circuit, every load reassignment) 
 Directory entry identifies the served device, not just the system: "Camera 03-2 / Lobby PTZ" not "Security" 
 Circuit type icons or annotations:: Green sticker on UPS-fed circuits Orange sticker on generator-fed circuits SPD annotation on circuits with surge protection Lock identifier on lockable breakers 
 Directory printed on durable paper or vinyl, mounted inside the panel cover or in a clear sleeve on the panel face 
 Electronic directory in the institution's CMMS, updated in parallel with the physical directory 
 Annual verification at preventive maintenance: physical directory matches actual circuit assignments 
 

 Asset tagging for the institutional CMMS 

 When the rule applies 

 Every major security install component on a project where the institution operates a CMMS (computerized maintenance management system). The asset tag links the physical equipment to its service record, its replacement schedule, and its lifecycle plan. 

 The spec 

 
 Asset tag format defined by the institution's CMMS template (varies; typical institutional formats are 8 to 16 alphanumeric characters) 
 Asset tag affixed to the equipment lamacoid plate or to a dedicated asset-tag location on the equipment chassis 
 Equipment registered in the CMMS at commissioning with: asset identifier, serial number, manufacturer, model, install date, warranty expiry, scheduled service interval, responsible party 
 QR code or barcode label adjacent to the human-readable identifier where the CMMS supports scan-in 
 Asset tag retained through the equipment's life; not removed at replacement (the tag retires with the equipment record) 
 

 Study Note 

 The institution's facility management team owns the CMMS. Coordinate with them at design to confirm the asset-tag format, the registration workflow, and the data fields the CMMS expects at commissioning. Most institutional CMMSs accept a CSV import of new assets at project closeout; build the CSV during commissioning and import it as a single batch. 

 The administrative document 

 When the document applies 

 Every project. The administrative document defines the identifier schemes, the colour conventions, the label formats, and the records-management process for the project's identification. Without it, every technician makes up their own scheme. 

 The spec 

 
 Cable identifier scheme (Class 1 / 2 / 3 / 4 administration) 
 Patch panel and rack identifier scheme 
 Outlet identifier scheme 
 Conduit colour convention 
 Equipment lamacoid format and content 
 Asset tag format and CMMS workflow 
 Records: as-built drawings, cable schedules, panel directories, firestop drawings (chapter 05) 
 Update procedure: who updates the documents, on what trigger, with what approval 
 Handover: digital and physical copies delivered at commissioning, with the institution's facility management as the receiver 
 

 Identification is the install the next technician can actually maintain. Lock the identifier scheme at design in the administrative document. Use a thermal-transfer label printer (DYMO Rhino, Epson LabelWorks PX, or Panduit) and stay in one consumable line per project. Engraved lamacoid plates on every rack and every major piece of equipment. Conduit colour banding by system. Panel directories updated at every change. Asset tags registered in the CMMS at commissioning. Do this and the building's first major service event takes minutes instead of hours.

================================================================

## Cable selection by environment

URL: https://hans.study/standards-guidance/cssir-07-cable-selection-environment/
Type: kb
Date: 2026-05-10
Description: Cable selection by environment for Canadian institutional security installs. Cat 6A, Cat 6, plenum (CMP), riser (CMR), general purpose (CM), outside plant (OSP), shielded vs unshielded, alien crosstalk, indoor-to-outdoor transition splice, 15 m rule.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Cable selection is the layer the install never gets to redo. The pull happens once, the cable is in the wall for the building's operational life, and the next opportunity to change cable type is the next major renovation. Pick the right category and the right jacket rating for the environment at design, document the choice in the spec, and pull what the spec calls for. Pull the wrong cable and the install fails certification, fails AHJ inspection, or fails on the first service event ten years later. 

 Cable category for new institutional work 

 When the rule applies 

 Every horizontal cable run on a new institutional security project. Cat 6A is the field default for new work; Cat 6 is acceptable only on retrofits where the existing pathway cannot accept Cat 6A. 

 The spec 

 
 Cat 6A U/UTP (unshielded twisted pair) for general institutional horizontal cabling 
 Cat 6A F/UTP (foil-screened, screen over the entire bundle) where EMI is a documented concern (industrial environments, near medical imaging, near elevator motors, near electrical service equipment) 
 Cat 6A S/FTP (foil per pair plus overall braid) in extreme EMI environments; verify the bonding path (chapter 04) supports the shield 
 Cat 6 acceptable on retrofit only, where the existing pathway cannot accept Cat 6A; document the deviation in the project specification 
 Cat 5e not used on new institutional security work; existing Cat 5e in retrofits handled per the institution's lifecycle plan 
 CCA (copper-clad aluminium) prohibited on every project, regardless of cost or schedule 
 Jacket colour: blue for data, with the project-specific assignment for security signal documented in the administrative document (chapter 06) 
 Conductor: 23 AWG bare copper for Cat 6A and Cat 6 
 

 Why Cat 6A, not Cat 6 

 Cat 6A supports 10GBASE-T over the full 100 m channel; Cat 6 supports it only over 37 m to 55 m and only with bundle-specific testing. The institutional install has to assume the building gets re-cabled into 10 Gbps over the next 15 years. Cat 6A handles that without re-pull; Cat 6 forces a re-pull. The cost differential is small at install (a few cents per metre); the cost differential at the re-pull is enormous. 

 Why CCA never 

 Copper-clad aluminium cable looks like Cat 6A on the outside and tests adequately on day one if pulled gently. It is also: not CSA-listed, not UL-listed for the cable category it claims, prone to oxidation at the termination over time, and known to fail PoE applications because the conductor resistance is too high. Pulling CCA on a project creates a defect that follows the install through warranty disputes, insurance claims, and any post-incident investigation for the operational life of the building. The cost saving on the cable is roughly 30 percent. The cost of remediation when discovered is 100 percent of a re-pull plus the legal exposure. 

 Study Note 

 Belden 10GX13 Cat 6A U/UTP CMP, blue jacket, 23 AWG bare copper, is the field default for institutional plenum work. CommScope SYSTIMAX GigaSPEED X10D 1091B Cat 6A U/UTP CMP is the field-equivalent on SYSTIMAX-warranted projects. Panduit TX6A-SD 10G Cat 6A U/UTP CMP is the equivalent on Panduit Verified Cabling Solutions projects. 
 For F/UTP (shielded) variants where EMI is a concern: Belden 10GXS13, CommScope SYSTIMAX GigaSPEED X10D 1091F, or Panduit TX6A-SD-Shielded. Pick one manufacturer per project and stay inside their warranty programme (chapter 10). 
 For Cat 6 retrofit work: Belden 7965A or Panduit TX6000, 23 AWG, CMP, blue jacket. 

 Jacket rating by pathway environment 

 When the rule applies 

 Every cable on the project. The jacket determines whether the cable is permitted in plenum spaces, in risers, in general indoor areas, or outdoors. Wrong jacket and the install fails AHJ fire-code inspection. 

 The spec 

 
 CMP (plenum) : required in any air-handling plenum space, including most drop-ceiling return-air plenums in commercial buildings. CEC FT6 equivalent. 
 CMR (riser) : required in vertical riser shafts between floors. CEC FT4 equivalent. 
 CM (general purpose) : acceptable in general indoor horizontal pathways that are not plenum or riser. Most institutional projects spec CMP for horizontal anyway to avoid the routing-restriction problem (see below). 
 CMX (limited use) : dwelling-unit applications only. Not used on institutional work. 
 OSP (outside plant) : required for outdoor cable. UV-stable jacket, often gel-filled or dry-block water-blocking. Not permitted in indoor pathways beyond the 15 m transition rule (see below). 
 LSZH (low smoke zero halogen) : required in transit (subway, rail) and some healthcare and detention applications where the institutional spec calls for low-smoke cable. Verify against the project specification. 
 

 Why CMP horizontal everywhere 

 The drop-ceiling space in most commercial buildings is an air-handling plenum return. Cable run above the tile in that space has to be CMP. Run CM (general-purpose) horizontal cable above a tile-and-grid ceiling that turns out to be plenum return and you have a code violation discovered at AHJ inspection. The fix is to re-pull the entire run in CMP, which costs more than spec'ing CMP at design would have. 
 The institutional default is to spec CMP horizontal everywhere. The cost differential per metre is small. The cost of discovering at inspection that a space is plenum return is significant. 

 Study Note 

 The mechanical drawings (M-series sheets) identify which ceiling spaces are air-handling plenums. Read them at design. Where the drawings are unclear, default to plenum-rated cable. The cost differential is outweighed by the certainty of compliance, and the spec covers both conditions. 

 Shielded versus unshielded 

 When the rule applies 

 Every Cat 6A run. The decision between U/UTP (unshielded) and F/UTP or S/FTP (shielded) depends on the EMI environment, not on category alone. Most institutional buildings do not need shielded cable; the few that do, need it badly. 

 When shielded is the right choice 

<DefList>
 <dt>Unshielded (U/UTP)</dt>
 <dd>The institutional default. Office, healthcare general areas, education general areas, transit station common areas, government offices. The cable's pair geometry handles typical commercial EMI without shielding.</dd>

 <dt>Foil-screened (F/UTP)</dt>
 <dd>Use where EMI is documented: industrial environments, near medical imaging suites, near elevator motors, near electrical service equipment, in detention areas with high RF transmitter density (radios, jammers). One foil over the bundle.</dd>

 <dt>Shielded twisted pair (S/FTP)</dt>
 <dd>Use only in extreme EMI environments: oil and gas yards near transmission lines, electric utility substations, broadcast facilities, military and research installs with documented EMI testing. Foil per pair plus overall braid.</dd>
</DefList>

 The bonding path 

 A shielded cable with no bonded shield is worse than unshielded cable; the floating shield becomes an antenna. The shield bonding path (cable shield → jack shield → patch panel shield → rack ground busbar → TGB → TMGB → building ground) has to be continuous and verified at commissioning. Read chapter 04 before specifying shielded cable. 

 Study Note 

 F/UTP Cat 6A from Belden (10GXS13), CommScope (1091F), or Panduit is the EMI default. Specify it where the design narrative documents an EMI concern; otherwise unshielded. S/FTP only on extreme installs and only with documented shield bonding verified at commissioning. 

 Outdoor cable and outside plant (OSP) 

 When the rule applies 

 Every cable that runs outdoors, in buried conduit, in aerial pathway, or in any pathway exposed to weather, UV, freeze-thaw, or water immersion in pull boxes. 

 The spec 

 
 Direct burial : gel-filled OSP cable with water-blocking compound throughout. Armored where rodent or mechanical damage is foreseeable. 
 Conduit-in-conduit underground : dry OSP (non-gel) acceptable where the conduit is sealed and waterproof. Gel-filled where flooding is foreseeable. 
 Aerial : messenger-supported cable with messenger sized for the span and ice loading (NBC Appendix C for the region) 
 Building entry : OSP cable transitions to indoor-rated cable within 15 m (50 ft) of the entry point per NEC and CEC, with the transition splice in an accessible enclosure (handhole, manhole, or first interior pull box) 
 Outdoor cable jacket : UV-stable HDPE or LSZH where required, FT4 or FT6 flame rating 
 Outdoor patch and pigtail cables : outdoor-rated assemblies with weatherproof connector boots 
 

 The 15 m indoor entry rule 

 OSP cable jackets are typically not flame-rated to indoor standards. NEC and CEC limit OSP cable to 15 m (50 ft) inside a building, after which it has to transition to indoor-rated cable. The transition splice can be in a handhole at the building's exterior, a manhole at the property line, or the first interior pull box; the rule is the 15 m distance from the building entry point. 
 Plan the transition splice at design. The splice enclosure has to accommodate the fibre splice trays or the copper splice terminations, and has to be accessible for future service. 

 Surge protection at the transition 

 
 Surge protection on every copper conductor entering the building from outdoor (every camera, every reader, every intrusion sensor with an exterior loop) 
 CSA-listed in-line Cat 6A or low-voltage surge protector at the transition, between the OSP termination and the indoor cable termination 
 Surge protector grounded to the TGB or to the building ground per chapter 04 
 Fibre is naturally immune to surge and does not require SPD at the transition 
 Coax (CCTV analog or RF) on outdoor runs: in-line coax surge protector at the transition 
 

 Study Note 

 For direct-burial OSP fibre: Corning ALTOS Lite or equivalent loose-tube gel-filled cable, with the strand count plus 50 percent spare per chapter 08. For direct-burial copper (rare on modern installs, mostly retrofit): Belden OSP-rated cable in armored variants. For aerial fibre: Corning ALTOS aerial messenger-supported cable. For the transition splice: indoor splice enclosure with manufacturer's splice trays (Corning or CommScope), in the handhole, manhole, or first interior pull box per the design. 

 Bundling and alien crosstalk 

 When the rule applies 

 Every Cat 6A install. Alien crosstalk is the coupling between adjacent Cat 6A cables in a bundle. ANSI/TIA-568.2-E defines the PSANEXT and PSAACRF parameters that distinguish Cat 6A from Cat 6. 

 The spec 

 
 Bundle Cat 6A cables with other Cat 6A cables of the same manufacturer and same part number 
 Do not bundle Cat 6A with Cat 6 or Cat 5e; alien crosstalk is uncharacterised in mixed bundles. Route on separate trays or with metallic divider. 
 Conduit fill design at 30 percent maximum to leave working room and avoid pull damage at bundle compression 
 Cable tray fill at 50 percent maximum cross-sectional area for Cat 6A (chapter 02) 
 Bundle integrity maintained from termination to termination; do not break and re-bundle mid-run 
 Velcro hook-and-loop wraps at maximum 1.5 m intervals along the bundle, hand-tight; do not deform the cable 
 No zip ties on Cat 6A bundles (zip ties compress the cable and degrade pair geometry) 
 

 Study Note 

 The Cat 6A jacket and the internal pair separation are sized for a specific compression load. Zip ties exceed that load by a wide margin when cinched tight. Velcro hook-and-loop wraps (the reusable kind) hand-tightened by feel keep the bundle organised without deforming the cable. Spend a few extra dollars on Velcro; do not zip-tie Cat 6A. 

 Cable installation: pulling tension and bend radius 

 When the rule applies 

 Every cable pull. The cable manufacturer publishes maximum pulling tension and minimum bend radius for installation and for the dressed cable in service. Exceeding either at install creates a defect that the next certification will find. 

 The spec 

 
 Maximum pulling tension: 25 lbs (110 N) for Cat 6A 23 AWG U/UTP at the cable end, measured at the pull point; higher tension damages the pair geometry 
 Use cable lubricant on long pulls (over 30 m) and pulls with more than one 90° bend 
 Pull cable through conduit with a properly-sized fish tape or pulling line; do not pull cable on cable 
 Minimum bend radius during installation: 4× the cable OD for U/UTP, 8× the cable OD for S/FTP 
 Minimum bend radius for dressed cable in service (rack, in tray, at termination): 4× the cable OD for U/UTP, 6× the cable OD for shielded 
 Service slack at every termination: minimum 300 mm (12") inside racks, 200 mm (8") in workstation backboxes 
 

 Cable selection is a one-time decision the install lives with for decades. Cat 6A on every new pull, Cat 6 only on retrofits where the pathway cannot accept Cat 6A, CCA never. CMP plenum-rated horizontal cable everywhere to avoid the plenum-return routing trap. Shielded cable only where EMI is documented and only with verified shield bonding. OSP outdoors with a transition splice within 15 m of the building entry, surge protected at the transition. Belden, CommScope, and Panduit are the institutional defaults; pick one manufacturer per project and stay inside their warranty programme. Velcro the bundles, not zip ties. Run the cable plant once, build it right, and it carries the building through every hardware refresh over the next twenty years.

================================================================

## Fiber optic cabling

URL: https://hans.study/standards-guidance/cssir-08-fiber-optic-cabling/
Type: kb
Date: 2026-05-10
Description: Fiber optic cabling for Canadian institutional security installs. OS2 single-mode, OM4/OM5 multimode, fiber count planning, loose-tube vs tight-buffered, LC/SC connectors, UPC vs APC, splice trays, splice enclosures, pigtail-and-splice termination, Sumitomo splicers, Corning and CommScope cable.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Fiber is the backbone that lives for decades. Single-mode fiber installed in 2026 will carry the same building's data through four generations of network hardware. The cable itself is durable, the connector standards are stable, and the splice work is permanent. The decisions that matter are made at design: fiber type, strand count, jacket, indoor versus outdoor, connector type. Get those right and the install carries the building through every hardware refresh. Get them wrong and the next refresh hands the institution a re-pull bid. 

 Fiber type by application 

 When the rule applies 

 Every fiber link on the project. The decision between single-mode and multimode, and the choice of multimode grade, depends on link length, transmission speed expectations, and the institution's hardware standardisation. 

 The spec 

 
 OS2 single-mode (G.652.D) : every backbone over 300 m, every inter-building link, every campus link. Carries any Ethernet speed through 400G with the right optics. Yellow jacket. 
 OM4 multimode (50/125, laser-optimised) : short-reach under 300 m where the hardware footprint uses multimode optics. 10G over 400 m, 40G over 150 m, 100G over 150 m. Erika violet jacket. 
 OM5 multimode (50/125, wide-band) : short-reach under 300 m for projects anticipating 100G or higher within the operational life. Supports SWDM (shortwave wavelength division multiplexing) for 100G/200G/400G over multimode. Lime green jacket. 
 OM3 multimode : acceptable on retrofit. Not specified for new institutional work; OM4 or OM5 cost differential is small and the bandwidth headroom is significant. Aqua jacket. 
 OM1 / OM2 legacy multimode : end-of-life. Replace at every opportunity, do not extend. Orange jacket. 
 

 Why OS2 for backbone 

 Single-mode fiber's bandwidth is bounded by the optics, not by the cable. The same OS2 strand that runs 10G today carries 400G with newer optics tomorrow. Multimode bandwidth is bounded by the cable's modal dispersion characteristic; OM4 at 400 m is roughly 10G, but the same 400 m at 100G requires OM4 with parallel optics or single-mode. For any backbone link over 300 m, OS2 single-mode is the only choice that future-proofs the install. 

 Study Note 

 Corning ALTOS series OS2 single-mode loose-tube outdoor cable for direct-burial and underground duct-bank installs. Corning FREEDM series tight-buffered single-mode for indoor backbone. CommScope SYSTIMAX LazrSPEED 550 OM4 or LazrSPEED 600 OM5 for short-reach multimode where the hardware uses multimode optics. Pick one manufacturer per project and stay inside their warranty programme. 

 Fiber count planning 

 When the rule applies 

 Every backbone fiber pull. The cable is in the wall for the building's life; the strand count is locked in at install. Adding strands is a re-pull, not a re-splice. 

 The spec 

 
 Backbone fiber count: 2× the calculated lit count, minimum 12 strands per backbone link 
 Each backbone link includes single-mode (OS2) and multimode (OM4 or OM5) strand pairs where the hardware footprint requires both 
 Spare strands: minimum 50 percent of the cable's strand count reserved as documented spares 
 Distribution to IDF: 12-strand or 24-strand cables to most IDFs, 24-strand or 48-strand on backbone trunks 
 Strand assignments documented on the fibre patch schedule at commissioning 
 

 The double-the-count rule 

 The cost differential between a 12-strand cable and a 24-strand cable at install is small (the cable itself is roughly 20 to 30 percent more; the labour to pull is identical). The cost of re-pulling because the institution adopted a new application that needs more strands is huge. Double the calculated count at design and the install absorbs the next two generations of hardware without re-pull. 

 Loose-tube versus tight-buffered cable 

 When the rule applies 

 Every fibre cable selection. Loose-tube and tight-buffered are two different cable constructions, suited to different pathway environments. 

 The two constructions 

<DefList>
 <dt>Loose-tube cable</dt>
 <dd>The fibre strands sit inside gel-filled or dry-block buffer tubes. The buffer tube isolates the fibre from temperature-induced cable expansion and contraction. Used outdoors, in long runs, in environments with significant temperature swing. Gel-filled and dry-block versions both work; gel-filled is messier at splice, dry-block is faster to terminate.</dd>

 <dt>Tight-buffered cable</dt>
 <dd>The fibre strands have a 900 μm tight buffer applied directly to the 250 μm coated fibre. The cable is more flexible than loose-tube and easier to terminate. Used indoors, in shorter runs, in patch panel and pigtail applications.</dd>

 <dt>Indoor/outdoor transition cable</dt>
 <dd>Loose-tube cable rated for indoor entry, with dry-block water blocking. Can be run inside a building up to the 15 m indoor entry rule (chapter 07) without splicing to indoor cable. Used where the transition splice would be inconvenient (small handhole at building exterior).</dd>
</DefList>

 Study Note 

 Corning ALTOS Lite loose-tube dry-block for direct-burial and underground duct bank. Corning ALTOS aerial for messenger-supported outdoor runs. Corning FREEDM tight-buffered for indoor backbone in risers and equipment rooms. The dry-block construction is the field default outdoors because the splice work is faster and cleaner; gel-filled cable is acceptable on flooded or below-water-table pulls where the dry-block water blocking is insufficient. 

 Connector types and polish 

 When the rule applies 

 Every fibre termination. The institutional default is LC duplex for high-density, with SC where the hardware port requires it. 

 The spec 

 
 LC duplex : institutional default. Small form factor, high port density on patch panels and switches. 
 SC : legacy, still common on older hardware. Square form factor, larger than LC. 
 ST, FC, MTP/MPO : specialised; used where the hardware specifically requires them. MTP/MPO for high-count parallel optic terminations (12-fibre, 24-fibre, 48-fibre). 
 Polish :: UPC (Ultra Physical Contact) : general data network use. Reflectance better than -50 dB. APC (Angled Physical Contact) : used for analog video, RF, and any application requiring lower reflectance. 8° endface angle. Reflectance better than -60 dB. Green connector boot. 
 UPC and APC are not interchangeable. Mating UPC to APC damages both connectors and creates an unusable link. 
 Pick one polish per link; document on the fibre patch schedule 
 

 Why pigtail-and-splice over field connectorisation 

 Field-installable connectors (no splice, mechanical or epoxy termination on site) are acceptable for emergency restoration or for retrofit work where pulling a full fibre is impractical. They are not the institutional new-build default because the loss budget is wider than a factory-polished pigtail-and-splice. A fusion-spliced factory pigtail produces a typical insertion loss of 0.10 to 0.20 dB; a field-installable connector produces 0.30 to 0.75 dB. On a 20-link backbone, that difference adds up to a margin loss that limits the optics' reach. 
 For new institutional work: factory-polished pigtails, fusion-spliced to the cable strands. Field-installable connectors only for emergency restoration. 

 Study Note 

 Corning UniCam pigtails for fusion-spliced terminations: factory-polished LC, SC, or ST in the matching polish (UPC or APC), with the manufacturer's loss specification. CommScope SYSTIMAX pigtails on SYSTIMAX-warranted projects. Verify the polish matches the link at order; UPC and APC pigtails look similar but the angled endface is visible under the inspection scope. 

 Splice trays and enclosures 

 When the rule applies 

 Every fibre splice on the project. The splice tray holds the splice protector and the fibre slack; the enclosure holds the trays and protects them from the environment. 

 The spec 

 
 Standard splice tray: 12 fusion splices per tray (single-fibre splice protector at 60 mm each) 
 High-density splice tray: 24 to 48 fusion splices per tray (smaller-format protectors and tighter routing) 
 Mass-fusion ribbon splice tray: 12 or 24 ribbon splices per tray (12-fibre or 24-fibre ribbon cable) 
 Splice enclosure: sized to accept 50 percent more trays than calculated at install, for future strand expansion 
 Enclosure environmental rating:: Indoor: NEMA 1 (general indoor) Outdoor or below-grade: NEMA 4X (weatherproof) or NEMA 6P (submersible) Handhole or manhole: NEMA 6P submersible 
 Fibre slack at each splice: minimum 1 m of buffer-coated fibre and minimum 3 m of cable sheath inside the enclosure 
 Cable strain relief at every enclosure entry, with the cable sheath secured before the buffer enters the tray 
 

 Study Note 

 Corning OSP-rated splice enclosures (UCAO series) for outdoor and underground use, with matching Corning splice trays. CommScope SYSTIMAX 360G2 series fibre shelves (2U and 4U) for indoor rack-mount splice-and-patch terminations. Verify tray-to-enclosure compatibility at order; trays from different manufacturers do not always fit other enclosures. 

 Fusion splicing 

 When the rule applies 

 Every backbone fibre termination on a new institutional install. Fusion splicing produces the lowest-loss, highest-reliability joint. The splicer maintenance, the cleaver maintenance, and the operator skill all determine the splice quality. 

 The spec 

 
 Core-alignment fusion splicer (not clad-alignment); core-alignment compensates for fibre core eccentricity and produces lower loss 
 Splicer calibrated to the fibre type (single-mode or multimode) at the start of each shift 
 Cleaver blade rotated or replaced per the manufacturer's interval; a worn cleaver produces high-loss splices 
 Strip length per the splicer's recommendation (typically 35 to 40 mm) 
 Cleaved fibre length per the splicer's recommendation (typically 10 to 16 mm) 
 Splice loss target: less than 0.10 dB average per splice for single-mode, less than 0.15 dB for multimode 
 Splice protector applied immediately after splice, with the protector heat-shrunk per the manufacturer's spec 
 Splice loss measured by the splicer's built-in estimator at splice time; verified by OTDR or OLTS at commissioning (chapter 10) 
 

 Study Note 

 Sumitomo T-Type core-alignment fusion splicers (T-72C+ or current model) are the field default for institutional fibre work. Sumitomo cleavers paired with the splicer. Sumitomo 60 mm heat-shrink splice protectors. The Sumitomo splicer's loss estimator is reliable to within 0.05 dB of the actual measured loss; trust it for go/no-go on each splice, then verify at commissioning. 

 Connector inspection 

 When the rule applies 

 Every fibre connector, every time it is mated. Connector end-face contamination is the single largest source of insertion loss on fibre links; inspecting and cleaning before mating is a non-negotiable step. 

 The spec 

 
 Inspect every connector end-face before mating, using a fibre inspection scope 
 Automated pass/fail evaluation per IEC 61300-3-35 (the connector end-face acceptance standard) 
 Clean the end-face before re-inspection if the first inspection fails; re-inspect after cleaning 
 Do not mate a failed connector; clean again or replace 
 End-face cleaner: cassette-style dry cleaner (one-click style) for routine cleaning; lint-free wipe with isopropyl alcohol for contamination 
 Connector dust caps installed on every unmated connector at all times 
 

 Study Note 

 Fluke FI-7000 FiberInspector Pro with automated IEC 61300-3-35 pass/fail. Sumitomo OneClick cassette-style dry cleaner (one cleaner per connector form factor: LC, SC, MPO). Lint-free wipes and 99% isopropyl alcohol for contamination cleaning. The end-face inspection scope is the single most-skipped step in fibre work; build it into the install procedure and verify it at every termination. 

 Bend radius and pulling tension for fibre 

 When the rule applies 

 Every fibre pull and every dressed fibre run in the rack and patch panel. Fibre is more sensitive to bend radius than copper; exceeding the minimum bend radius increases macrobend loss and may cause permanent fibre damage. 

 The spec 

 
 Minimum bend radius during installation: 20× the cable OD for single-mode, 10× for multimode 
 Minimum bend radius for dressed cable in service: 10× the cable OD for single-mode, 5× for multimode 
 Maximum pulling tension per the cable manufacturer's data sheet (typically 600 to 2700 N depending on cable construction) 
 Use cable lubricant on long pulls and pulls with bends; reduces friction and pulling tension 
 Pull cable with the manufacturer's recommended pulling grip (basket-weave or pulling eye); do not pull on the cable jacket directly 
 Service slack at every splice and every patch panel: minimum 3 m of cable sheath in the enclosure 
 

 Fibre is the backbone that lives for decades. OS2 single-mode for every backbone over 300 m and every campus link. OM4 or OM5 multimode for short-reach where the hardware uses multimode optics. Loose-tube outdoor, tight-buffered indoor. LC duplex as the default connector. UPC for general data, APC for analog and RF (never mix). Pigtail-and-splice for every backbone termination, fusion-spliced with a Sumitomo core-alignment splicer. Inspect every connector before mating. Respect the bend radius. Build the install once and the fibre carries the building through the next three decades of network hardware.

================================================================

## Termination procedures

URL: https://hans.study/standards-guidance/cssir-09-termination-procedures/
Type: kb
Date: 2026-05-10
Description: Termination procedures for Canadian institutional security installs. Cat 6A keystone and patch panel terminations, T568A/B wiring, wire-to-wire junction connections, DIN-rail terminal blocks at panels, fiber pigtail-and-splice, service slack and strain relief, dressing and labelling at termination.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Terminations are what nobody sees until they fail. Every keystone jack, every patch panel punch, every junction box wire connection, every fiber splice is a potential point of failure that the cable plant's certification depends on. The work itself is small detail repeated hundreds or thousands of times across the project; the discipline is the difference between a cable plant that certifies on the first walkthrough and one that comes back for retermination three times before sign-off. 

 Cat 6A keystone jack termination 

 When the rule applies 

 Every Cat 6A horizontal cable termination at the outlet end. The keystone jack is what makes the difference between a cable that certifies and one that does not; the same cable terminated by two different technicians will produce two different test results if the procedure is inconsistent. 

 The spec 

 
 Strip jacket length: 32 to 40 mm (1-1/4" to 1-5/8") to expose the pairs 
 Strip with a cable jacket stripper sized for the cable OD; do not nick the conductor insulation 
 Separator (the cable's internal pair-isolation spine) cut flush at the jacket edge 
 Pair untwist length: maximum 13 mm (1/2") at each conductor 
 Wiring scheme: T568A or T568B per project specification; consistent across all terminations on the project 
 Punch each conductor into the jack's IDC with a manufacturer-recommended impact tool (110-style or proprietary depending on jack) 
 One punch per conductor; do not repunch 
 Trim excess conductor flush with the jack body after punch 
 Test the termination on the link tester before closing the box; clear the punch on any failed pair before moving on 
 Service slack at the termination: minimum 200 mm (8") inside the workstation backbox, minimum 300 mm (12") inside racks 
 

 T568A versus T568B 

 T568A and T568B are functionally identical Ethernet wiring patterns. The pairs are arranged differently in the connector but the electrical performance is the same. The two patterns are not interchangeable on a single link; a cable terminated T568A on one end and T568B on the other is a crossover cable and does not work on a straight-through Ethernet link. Pick one pattern at design, document it in the project administrative document, and verify every termination matches. 
 Some institutional specs require T568A (the US Federal Government default historically); others require T568B (the commercial default in much of North America). When the spec is silent, T568B is the more common field choice in Canadian institutional work. 

 Study Note 

 Panduit Mini-Com TX6A 10G shielded or unshielded keystone jacks (CJ688TG series) with the matching Mini-Com punch tool. Belden REVConnect terminations on Belden-warranted projects (the REVConnect system uses a proprietary single-step tool instead of 110 punches; faster at scale but vendor-specific). CommScope SYSTIMAX GigaSPEED keystone jacks with the SYSTIMAX punch tool on SYSTIMAX-warranted projects. 
 The choice of jack is constrained by the warranty programme. Pick the manufacturer at design (cable, jack, panel all from one vendor), order the matching punch tool, and the field work is predictable. 

 Cat 6A patch panel termination 

 When the rule applies 

 Every Cat 6A horizontal cable termination at the IDF end. The patch panel is where the cable lands in the rack and where every test and service event happens for the cable plant's life. 

 The spec 

 
 Modular keystone patch panel: 24-port or 48-port 19" rack-mount frame, 1U or 2U, with strain relief bar on the rear for cable management 
 Keystone jacks loaded into the panel from the rear; panel face presents the RJ45 port to the rack 
 Cable strain relief: bar-and-tie-wrap on the rear of every panel, with cables dressed to the bar before entering the jack 
 Service slack inside the rack: minimum 300 mm (12") coiled neatly behind the panel 
 Jack colour coding: blue for data, red for security signal, white for voice (legacy), per project administrative document 
 Panel labelling: every port labelled at the panel face with port number and destination outlet identifier (chapter 06) 
 Panel mounted at the top of the IDF rack working downward; equipment switches mounted below the panels 
 

 Modular versus direct-punch panels 

<DefList>
 <dt>Modular keystone panel</dt>
 <dd>The panel is a frame that accepts individual keystone jacks. The cable terminates on the jack, the jack snaps into the panel from the rear. Mix categories and vendors in one frame. Replace a damaged jack without re-terminating adjacent cables. Build to the as-needed port count.</dd>

 <dt>Direct-punch patch panel</dt>
 <dd>The panel rear has 110-style IDC pins integrated into the frame. The cable terminates directly on the panel. Fewer parts, faster installation at scale. Damaged port requires panel replacement; vendor lock-in to the panel manufacturer's connection programme.</dd>
</DefList>

 Modular is the institutional default because it allows mixed-vendor or mixed-category jacks in the same panel and supports field replacement of damaged jacks without re-terminating adjacent cables. 

 Study Note 

 Panduit DP24588TGY 24-port or DP48688TGY 48-port modular keystone panels loaded with Panduit Mini-Com TX6A jacks. CommScope SYSTIMAX 360 modular keystone panels with SYSTIMAX GigaSPEED jacks. Belden modular patch panel frames with REVConnect jacks. Pick one manufacturer per project and match the cable, jack, and panel from the same warranty programme. 

 Wire-to-wire junction connections 

 When the rule applies 

 Every wire connection inside a junction box, every door wiring junction, every motor-control connection. The point where two or more conductors join, mechanically and electrically, in an enclosure other than at a device terminal. 

 The spec 

 
 Lever-action push-in connectors for every wire-to-wire connection inside junction boxes on security signal and low-voltage power cabling 
 Connector sized for the conductor count and the AWG range 
 Conductor strip length per the connector's gauge marking (typically 9 to 11 mm) 
 Lever closed firmly after conductor insertion; verify with a gentle pull on each conductor 
 Push-in (no-lever) connectors acceptable for solid conductors only, where the lever connector is not appropriate 
 Twist-on connectors (Marrette, Marr, Ideal, and similar) not used on security signal cabling, regardless of CEC permission 
 Crimp connectors used only where the application is specifically engineered for them (motor connections, large-gauge splices) 
 Splices in walls (between studs, behind drywall) or in ceiling cavities (above tile, in plenum) not acceptable regardless of how the splice is made 
 

 Why not twist-on 

 Twist-on connectors (Marrette and similar) work by mechanically twisting the conductors together inside a tapered plastic shell. They are CEC-permitted for general electrical work and are the field default for power circuits. They are not the right choice for security signal cabling for three reasons: they are not consistent in connection quality (different technicians produce different connections), they degrade under vibration and thermal cycling, and they cannot be re-opened for service without damaging the conductor. Lever-action push-in connectors give consistent, serviceable, reliable connections in the same physical space. 

 Study Note 

 WAGO 221 series lever-action connectors for the bulk of wire-to-wire junction work. 2-, 3-, and 5-conductor variants in the kit; 3-conductor is the field workhorse. WAGO 2273 push-in (no-lever) connectors for solid-conductor connections where the lever is not appropriate. Phoenix Contact or Weidmuller equivalents on projects standardised on those manufacturers' lines. 
 The lever-action connector adds maybe 2 seconds per connection over a twist-on. The serviceability and the reliability are worth that 2 seconds many times over the install's life. 

 DIN-rail terminal blocks at panels 

 When the rule applies 

 Every cabinet, every access control panel, every intrusion panel, every device that terminates multiple field cables to a central control point. DIN-rail terminal blocks provide the orderly, serviceable, labelled landing for every field conductor. 

 The spec 

 
 Spring-clamp DIN-rail terminal blocks for every field conductor entering a cabinet 
 Block sized to the conductor AWG; do not over-stuff small blocks with large conductors 
 One conductor per terminal position; do not double up 
 Terminal block labelled with the conductor identifier (chapter 06) 
 Conductor strip length per the block manufacturer (typically 8 to 10 mm) 
 Ferrule on stranded conductor terminations: crimped wire ferrule with insulated collar, sized to the conductor and the terminal 
 End barrier and partition plate at the end of each terminal block group 
 DIN rail securely mounted to the cabinet back panel; rail length sized for the as-installed terminal count plus 50 percent spare 
 Block manufacturer and series consistent across the cabinet; mixing block series creates jumper compatibility issues 
 

 Study Note 

 WAGO TOPJOB S 2002 series spring-clamp DIN-rail blocks for general security signal terminations. Phoenix Contact CLIPLINE complete series on Phoenix-standardised projects. Weidmuller WDU series on Weidmuller-standardised projects. The three manufacturers' product lines are functionally equivalent; pick one per project for jumper, end-barrier, and accessory compatibility. 
 Ferrule the stranded conductor terminations every time. The cost is pennies per conductor and the connection quality is significantly better than a bare stranded conductor in a spring clamp. 

 Fiber pigtail-and-splice termination 

 When the rule applies 

 Every backbone fibre termination on a new institutional install. The factory-polished pigtail fusion-spliced to the field cable produces the lowest-loss, most reliable termination available. 

 The spec 

 
 Factory-polished pigtail with the connector type and polish matching the link (UPC or APC; chapter 08) 
 Pigtail fibre type matching the cable: OS2 single-mode to OS2 cable, OM4 to OM4, OM5 to OM5 
 Strip pigtail and cable strand to splicer-recommended length (35 to 40 mm typical) 
 Clean stripped fibre with lint-free wipe and 99% isopropyl alcohol before cleaving 
 Cleave with a maintained cleaver (cleaver blade rotated or replaced per manufacturer interval) 
 Fusion splice with a core-alignment splicer; verify splice loss estimator reads less than 0.10 dB single-mode, less than 0.15 dB multimode 
 Heat-shrink splice protector applied immediately, fully cured before moving the spliced fibre 
 Place spliced fibre and 1 m minimum buffer-coated slack in the splice tray 
 Pigtail's connector end terminated into the patch panel; cable end secured to the splice tray strain relief 
 Patch panel labelled with the strand identifier (chapter 06) 
 

 Study Note 

 Corning UniCam factory-polished pigtails for fusion-spliced terminations: LC, SC, or ST in UPC or APC polish. CommScope SYSTIMAX pigtails on SYSTIMAX-warranted projects. Sumitomo T-Type core-alignment fusion splicer. Sumitomo cleaver (matched to the splicer). Sumitomo 60 mm heat-shrink splice protectors. The full Sumitomo splicer kit is roughly $20,000 in 2026, but it pays back on the first 100-link backbone install through speed and splice quality. 

 Mechanical splice for emergency restoration 

 When the rule applies 

 Field restoration where a fusion splicer is not available and the link has to come back up before a splicer can be brought to site. Not the institutional new-build default; emergency use only. 

 The spec 

 
 Mechanical splice (e.g., 3M Fibrlok or equivalent) used only for emergency restoration 
 Strip and cleave fibre per the mechanical splice manufacturer's procedure 
 Insert cleaved fibres into the splice from both sides until they meet at the index-matching gel 
 Close the splice cap; verify mechanical retention 
 Insertion loss target: less than 0.50 dB at install (higher than fusion splice) 
 Replace with fusion splice at the next scheduled maintenance window 
 Document the mechanical splice in the as-built drawing with the install date and the planned replacement date 
 

 Strain relief and dressing at termination 

 When the rule applies 

 Every termination on the project. Strain relief and dressing at the termination determine how the connection survives the next twenty years of service events: vibration, temperature cycling, the next technician's accidental pull on the patch cord. 

 The spec 

 
 Cable strain-relieved at every termination: at the patch panel rear, at the keystone jack body, at the cabinet entry, at the workstation backbox 
 Strain relief by Velcro tie-wrap on a strain relief bar (no zip ties on Cat 6A) 
 Service slack at every termination: 300 mm (12") inside racks, 200 mm (8") in workstation backboxes 
 Cable dressed parallel and perpendicular at the rack; no diagonal runs across the rack rear 
 Cable bundle separation: data cables on one side of the rack rear, power cables on the other 
 Patch cord dressing: routed through cable management arms or trays, with service slack at both ends 
 Bend radius respected at every dressing change: minimum 4× cable OD for U/UTP, 6× for shielded, 10× for fibre 
 

 Study Note 

 The 300 mm of service slack inside the rack is what lets the next technician re-terminate the cable when the jack fails in year 12. Without the slack, re-termination means pulling the cable back through the conduit and re-cutting it shorter. With 300 mm of slack, the re-termination is a 15-minute job. Build the slack in at install; do not trim cables flush to the rear of the patch panel. 

 Patch cord selection 

 When the rule applies 

 Every patch cord on the project. The patch cord is the part of the install that gets handled the most and replaced the most; the wrong patch cord becomes the limiting performance factor on the link. 

 The spec 

 
 Patch cord category matches the cable category: Cat 6A patch cord on Cat 6A links 
 Manufacturer's listed factory-terminated patch cord; field-terminated patch cords not used (the assembly is unrepeatable in the field) 
 Patch cord length: shortest practical length that allows clean dressing, with the manufacturer's standard increments (0.5 m, 1 m, 1.5 m, 2 m, 3 m, 5 m, 7 m) 
 Patch cord jacket colour matches the project administrative document scheme (chapter 06) 
 Patch cord labels at both ends matching the connected ports (chapter 06) 
 Patch cord rated for the warranty programme: Belden patch cords on Belden links, Panduit on Panduit, CommScope on CommScope 
 

 Study Note 

 Field-terminated patch cords introduce two more terminations into a channel that already has four (cable-to-jack at each end, jack-to-patch cord at each end). The patch cord termination at each end adds insertion loss, NEXT, and return loss contributions that the certifier picks up at testing. Factory-terminated patch cords come with manufacturer-tested performance; field-terminated cords do not. Buy patch cords by the case in the lengths you need, and field-terminate only in emergency. 

 Terminations are what nobody sees until they fail. Cat 6A keystones at 32 to 40 mm strip, 13 mm maximum untwist, T568A or T568B picked once and used everywhere, one punch per conductor, test before close. WAGO 221 lever-nuts at every wire-to-wire join; Marrette stays in the truck. Spring-clamp DIN-rail terminal blocks for every field-cable conductor at every cabinet. No splicing in walls or ceilings, ever. Pigtail-and-splice on every fibre backbone termination, fusion-spliced with a maintained core-alignment splicer. Strain relief and service slack at every termination. Build the terminations right and they outlast the building's first two hardware refreshes.

================================================================

## Cable testing and certification

URL: https://hans.study/standards-guidance/cssir-10-cable-testing-certification/
Type: kb
Date: 2026-05-10
Description: Cable testing and certification for Canadian institutional security installs. ANSI/TIA-568.2-E parameters, permanent link vs channel test, autotest, Tier 1 OLTS fiber test, Tier 2 OTDR, manufacturer warranty programs, Fluke DSX-8000 series, certification report format.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Cable certification is the cable plant's birth certificate. Without it, the cable plant has no provenance, the manufacturer warranty does not register, and the institution has no record of what the plant performed at when new. With certification, every link has a documented baseline against which future degradation can be measured, the warranty programme triggers the manufacturer's 20- or 25-year coverage, and the install closes out with a deliverable the institution can audit. The work is straightforward; the discipline is doing it on every link, with calibrated instruments, against the right standard. 

 The governing standards 

 When the standards apply 

 Every certified cable link in Canada. Two parallel standards define the acceptance parameters; both produce the same test result on the same link. 

 The standards 

 
 ANSI/TIA-568.2-E : Balanced Twisted-Pair Telecommunications Cabling and Components Standard. Defines the test parameters for Cat 5e through Cat 8: insertion loss, NEXT, PSNEXT, ACR-N, PSACR-N, ACR-F, PSACR-F, return loss, propagation delay, delay skew. 
 CSA T568 : Canadian parallel of ANSI/TIA-568. Same parameters, same limits. 
 ISO/IEC 11801 : International standard, often referenced on cross-border or multinational institutional projects. 
 ANSI/TIA-568.3-E : Optical Fiber Cabling Components Standard. Defines Tier 1 (OLTS insertion loss) and Tier 2 (OTDR) test methods. 
 

 Permanent link versus channel test 

 When the rule applies 

 Every Cat 6A and Cat 6 certification. The institutional default is permanent link testing; channel testing is used for project-specific applications. 

 The two test models 

<DefList>
 <dt>Permanent link</dt>
 <dd>The installed cable plus the two connectors at each end of the horizontal cable (jack at the outlet, jack at the patch panel). Does not include patch cords. This is the cabling that stays in the wall for the building's life and is the institutional certification default.</dd>

 <dt>Channel</dt>
 <dd>The permanent link plus the patch cords at each end. Includes everything from the device to the device, end to end. Used when the certification has to validate the full end-to-end path including the patch cords; less common on institutional new-build.</dd>
</DefList>

 The spec 

 
 Permanent link adapter on each end of the certifier, with the manufacturer-supplied reference cord (not a project patch cord) 
 Reference cord length: per the certifier manufacturer's spec (typically 2 m maximum) 
 Certifier set to the cable category (Cat 6A) and the permanent link model 
 Test parameters per ANSI/TIA-568.2-E autotest 
 Both directions tested for parameters that are direction-dependent (NEXT is tested at both ends) 
 Test result recorded to certifier internal storage and exported to certification reports at end of project 
 

 Cat 6A test parameters 

 When the rule applies 

 Every Cat 6A link certification. The certifier runs a full autotest measuring all parameters against the ANSI/TIA-568.2-E Cat 6A limits. 

 The parameters 

 
 Wire map : continuity, polarity, pin-to-pin correctness on all 8 conductors 
 Insertion loss : attenuation across the frequency range (1 MHz to 500 MHz for Cat 6A) 
 NEXT (Near-End Crosstalk) : pair-to-pair crosstalk measured at the near end 
 PSNEXT (Power Sum NEXT) : sum of NEXT contributions from all other pairs 
 ACR-N (Attenuation to Crosstalk Ratio, Near) : derived from insertion loss and NEXT 
 PSACR-N (Power Sum ACR, Near) : derived from insertion loss and PSNEXT 
 ACR-F (Attenuation to Crosstalk Ratio, Far) : far-end crosstalk-to-attenuation ratio 
 PSACR-F (Power Sum ACR, Far) : derived from PSACR-F at both ends 
 Return loss : signal reflected back due to impedance mismatch 
 Propagation delay : signal travel time end to end 
 Delay skew : difference in propagation delay between pairs 
 Length : cable length measured by TDR 
 Resistance : DC resistance and resistance unbalance on each pair 
 

 The PASS-with-asterisk problem 

 The certifier reports each parameter as PASS, FAIL, or PASS* (PASS with asterisk). PASS* means the parameter is within 0.1 to 0.5 dB of the limit at one or more frequencies, within the certifier's measurement uncertainty. On the institutional install, PASS* is treated as a failure: the link is re-terminated, re-tested, and resubmitted. The PASS* result indicates a marginal termination that will degrade with temperature, with cable age, or with the next service event. 
 Only PASS-without-asterisk results are accepted on certification submission. 

 Study Note 

 Fluke Networks DSX-8000 or DSX2-8000 with Cat 6A permanent link adapters. The DSX-8000 runs the full ANSI/TIA-568.2-E autotest in under 10 seconds per link and produces the certification report directly. Calibrate the certifier annually with the manufacturer-recommended calibration kit; run a self-test at the start of each shift to confirm the calibration is current. Keep the firmware current; new firmware releases update the limits when standards change. 

 Fiber Tier 1 testing (OLTS) 

 When the rule applies 

 Every fibre link on the institutional install. Tier 1 testing measures end-to-end insertion loss with an Optical Loss Test Set (OLTS) at the wavelengths the link will operate at. 

 The spec 

 
 OLTS test on every fibre link, both directions 
 Wavelengths: 1310 nm and 1550 nm on single-mode; 850 nm and 1300 nm on multimode 
 Reference method: 1-jumper, 2-jumper, or 3-jumper per ANSI/TIA-526-14 (multimode) or ANSI/TIA-526-7 (single-mode); the 1-jumper method is the institutional default for single-mode, 3-jumper for multimode 
 Reference cord: manufactured launch-grade single-mode or multimode reference cord, calibrated annually 
 Reference set at the start of each test session and verified before testing each link 
 Loss budget: calculated per ANSI/TIA-568.3-E limits for the cable, connector count, and splice count on the link 
 Connector end-face inspection (chapter 08) before every OLTS test; failed inspection means clean and re-inspect before testing 
 Result PASS if measured loss is below the calculated loss budget 
 

 Loss budget calculation 

 The loss budget for a fibre link sums the loss contributions of every element on the link. 
 
 Cable attenuation: 0.40 dB/km at 1310 nm and 0.30 dB/km at 1550 nm for single-mode; 3.5 dB/km at 850 nm and 1.5 dB/km at 1300 nm for OM4 multimode 
 Connector loss: 0.75 dB per mated pair (worst case per ANSI/TIA-568.3-E) 
 Splice loss: 0.30 dB per fusion splice (worst case) 
 
 A 500 m single-mode link with 4 connectors and 2 splices has a calculated budget of (0.500 × 0.40) + (4 × 0.75) + (2 × 0.30) = 0.20 + 3.00 + 0.60 = 3.80 dB at 1310 nm. Measured loss below 3.80 dB passes. 

 Study Note 

 Fluke Networks CertiFiber Pro with single-mode and multimode modules for Tier 1 OLTS testing. The CertiFiber Pro runs the dual-wavelength test in under 5 seconds per link and produces the certification report directly. Reference cords from Fluke matched to the certifier; do not use project patch cords as reference cords. End-face inspection with the Fluke FI-7000 FiberInspector Pro between every connection. 

 Fiber Tier 2 testing (OTDR) 

 When the rule applies 

 Tier 2 is required where the project specification calls for it, where the manufacturer warranty programme requires it, or where the AHJ specifies OTDR documentation. Tier 2 is supplementary to Tier 1, not a replacement. 

 The spec 

 
 Pulse width selected for the link length: 5 ns for under 500 m, 30 ns for 500 to 2000 m, 100 ns for 2 to 10 km 
 Wavelength: 1310 nm and 1550 nm on single-mode; 850 nm and 1300 nm on multimode 
 Launch fibre (lead): minimum 100 m, manufactured launch cable, same fibre type as link under test 
 Receive fibre (tail): minimum 100 m, manufactured receive cable at the far end 
 Index of refraction (IOR) set to the cable manufacturer's published value for the fibre type 
 Event table threshold: 0.10 dB loss event, 0.20 dB reflectance event 
 OTDR trace saved bidirectionally (both ends) and averaged where the manufacturer warranty requires 
 Test report: OTDR trace file, summary table of events, overall link loss in dB, link length in m, technician name, calibration date 
 

 Study Note 

 Fluke Networks OptiFiber Pro CFP with single-mode (1310/1550 nm) and multimode (850/1300 nm) modules for Tier 2 OTDR testing. The OptiFiber Pro auto-analyses the trace and identifies events (connectors, splices, breaks) without manual cursor placement, but verify the auto-analysis manually before sign-off; the auto-analysis occasionally misses small events that the technician should review. 

 Manufacturer warranty registration 

 When the rule applies 

 Every institutional project that specifies a manufacturer warranty programme (Belden, CommScope, Panduit, or similar). The warranty programme triggers the manufacturer's 20- or 25-year coverage on the cable plant. 

 The spec 

 
 Manufacturer warranty programme identified at design and named in the project specification 
 Installer holds current manufacturer certification for the programme (Belden Certified Cabling Installer, CommScope BusinessPartner, Panduit One Partner, etc.) 
 Cable, jack, panel, and patch cord all from the named manufacturer's product line (mixed-vendor installs do not qualify for warranty) 
 Termination procedures follow the manufacturer's installation guide 
 Certification report (PDF and native certifier format) submitted to the manufacturer through their warranty portal within 30 days of cable plant completion 
 Warranty certificate issued by the manufacturer and delivered to the institution as part of project closeout 
 Warranty term: 20 years for Cat 6 programmes, 25 years for Cat 6A programmes, lifetime for some programmes on specific product lines 
 

 Study Note 

 The 30-day window after cable plant completion is the registration window for most manufacturers. Miss it and the warranty does not register; the cable still works, the certification is still valid, but the manufacturer's 20- or 25-year coverage is forfeit. Build warranty registration into the project closeout checklist and assign it to a named individual (typically the project manager) with a deadline date. 

 Certification report content 

 When the rule applies 

 Every certification submission. The report has to satisfy the manufacturer warranty programme, the institution's records retention, and the AHJ where AHJ review is required. 

 The spec 

 
 Cover page: project identifier, institution, integrator, dates, technician names, certifier model and serial number, calibration date 
 Per-link summary: link identifier, cable category, test standard, PASS/FAIL result, headroom margin, test date, technician initials 
 Per-link detail: full autotest parameters with measured value, limit, and pass/fail at each frequency 
 Graphical plots for insertion loss, NEXT, return loss across frequency 
 Wire map diagram for each link 
 Fibre links: per-link OLTS loss at each wavelength, calculated loss budget, headroom margin 
 Tier 2 fibre: OTDR trace with event table and overall loss 
 Native certifier format file: included for re-analysis or warranty audit 
 PDF format file: included for institutional archival 
 Calibration certificate for the certifier: included or referenced 
 

 Study Note 

 Fluke Networks LinkWare Live is the cloud-based certification report platform that integrates with the DSX-8000 and CertiFiber Pro. The certifier uploads to LinkWare Live at the end of each test session; the project manager generates the report from LinkWare Live with the institution's branding. The native LinkWare files are retained on LinkWare Live for the project's life and serve as the warranty audit record. 

 Re-testing after re-termination 

 When the rule applies 

 Any link that failed initial testing and was re-terminated. The re-tested link has to demonstrate full PASS-without-asterisk on all parameters before it is included in the certification submission. 

 The spec 

 
 Re-terminate the failed end (or both ends if the failure cannot be localised to one end) 
 Inspect the new termination visually for proper conductor pair geometry 
 Re-test the link with the same certifier configuration as the initial test 
 Submit only the PASS-without-asterisk result in the certification report 
 Document the re-termination in the project's quality record (technician, date, root cause) 
 Where the same link fails twice, escalate to the project lead: the cable itself may be damaged and may need to be replaced 
 

 Cable testing is the cable plant's birth certificate. Fluke DSX-8000 for copper, CertiFiber Pro for fibre Tier 1, OptiFiber Pro for Tier 2 where required. Permanent link test, full ANSI/TIA-568.2-E parameter set, PASS without asterisk on every link. Identify the manufacturer warranty programme at design, hold the installer certification, and register within 30 days of cable plant completion. Submit the certification report in both native certifier format and PDF, archived for the project's life. Without the certification, the cable plant has no provenance; with it, the cable plant has a documented baseline against which the next 25 years of operation can be measured.

================================================================

## Network devices for security

URL: https://hans.study/standards-guidance/cssir-11-network-devices-for-security/
Type: kb
Date: 2026-05-10
Description: Network device selection and configuration for Canadian institutional security installs. Managed switches, PoE budget management, VLAN segmentation, configuration baseline, Cisco Catalyst, Aruba CX, industrial DIN-rail switches, distribution and core layers.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 The network switch is the system as far as the traffic is concerned. Every camera frame, every reader event, every intrusion signal goes through it. The wrong switch becomes the limiting factor on the install's reliability; the right switch with a managed configuration becomes invisible infrastructure that does its job for ten years. Pick managed switches at every layer, size the PoE budget against the actual load, segregate traffic with VLANs, harden the configuration at commissioning, and the network layer holds up for the institution's planning horizon. 

 Switch class by role 

 When the rule applies 

 Every switch on the project. The role determines the class: access-layer switches in IDFs serve devices, distribution switches aggregate traffic between IDFs, core switches anchor the network. The institutional default is enterprise-grade managed switches at every layer; consumer or SOHO switches do not appear on production installs. 

 The spec 

 
 Access layer (IDF, equipment closet) : managed Layer 2 or Layer 3 switch with PoE++, 24 to 48 ports, 1 Gbps copper access ports, 10 Gbps fibre uplinks, full configuration baseline (below) 
 Distribution layer : managed Layer 3 switch with 10 Gbps or 25 Gbps interfaces, aggregating multiple access switches, providing inter-VLAN routing 
 Core layer : high-throughput Layer 3 switch with 40 Gbps or 100 Gbps interfaces, redundant power supplies, redundant supervisor modules where the design calls for them 
 Industrial / environmental : DIN-rail managed switch rated for the environmental conditions (temperature range, vibration, dust ingress); used in outdoor IDFs, transit stations, industrial buildings 
 Unmanaged switches not used on institutional installs, regardless of port count or budget pressure 
 Consumer-grade switches (SOHO equipment) not used on institutional installs 
 

 Study Note 

 Cisco Catalyst 9300 series at the access layer for institutional projects on a Cisco network (48-port PoE++ at 1.4 kW budget). Aruba CX 6300M series at the access layer for institutional projects on an HPE Aruba network (48-port PoE Class 6 at 1.4 kW budget). Both deliver Class 6 (60 W) on every port simultaneously up to the switch budget. 
 For distribution and core, the institution's network team owns the platform choice; the security install aligns with whatever the institutional network standardises on. The security network team specifies the access layer; the institution's network team specifies the distribution and core. 
 For industrial / environmental: Cisco IE3300 or Aruba CX 4100i DIN-rail switches, depending on the platform choice. Both rated for temperature range and vibration in outdoor IDFs and industrial cabinets. 

 PoE budget sizing 

 When the rule applies 

 Every PoE-capable switch on the install. The PoE budget is the sum of every port's draw across the switch; exceed it and the switch cuts power to lower-priority ports in port order until the budget balances. Design at 75 percent of the published budget and the system has headroom for inrush, for incidental loads, and for the next device the institution adds. 

 The spec 

 
 Worst-case device power summed at design (chapter 03 has the PoE class table) 
 Switch PoE budget at 75 percent maximum aggregate across all ports 
 Inrush margin: 25 percent above the steady-state worst-case for simultaneous power-on events 
 Per-port PoE priority assigned by VLAN: cameras and access readers high priority, building wireless and general-purpose lower 
 Redundant PSU sized to handle the full PoE budget on a single supply (not load-shared) 
 PoE budget verified at commissioning (chapter 22) under the actual installed load 
 Mid-span injectors not used at scale; native PoE on every port simplifies documentation and the spare-port budget 
 

 Worked example 

 An IDF serves 24 indoor IP cameras at Class 4 (25 W max) and 8 outdoor PTZ cameras at Class 6 (60 W max). Total PoE load worst-case: (24 × 25) + (8 × 60) = 600 + 480 = 1080 W. At the 75 percent design target, the switch needs at least 1080 / 0.75 = 1440 W of PoE budget. A 48-port Cisco Catalyst 9300-48UXM at 1400 W is marginal; a 48-port Cisco Catalyst 9300X-48HXN at 1880 W with PoE++ leaves comfortable margin. 

 VLAN segmentation 

 When the rule applies 

 Every managed switch on the install. VLAN segmentation isolates traffic types onto separate broadcast domains, providing both security and performance benefits. 

 The spec 

 
 Minimum five VLANs on the security network:: VLAN: Cameras (IP cameras and recording servers) VLAN: Access Control (controllers, readers, head-end server) VLAN: Intrusion (alarm panels, sensors) VLAN: Security Servers (head-end systems, management workstations) VLAN: Management (switches, UPS, monitoring devices) 
 Inter-VLAN routing controlled at the distribution layer with ACLs (access control lists) restricting traffic to documented flows 
 Per-VLAN IP addressing: institutional subnet plan with sufficient address space for current load plus 100 percent growth 
 VLAN trunk ports between switches: 802.1Q tagged with the institution's standard native VLAN (typically the management VLAN or VLAN 1 disabled) 
 Voice VLAN, building automation VLAN, guest wireless VLAN: not on the security network; isolated at the institutional network boundary 
 VLAN identifiers (1-4094) per the institutional network standard; coordinated at design 
 

 Study Note 

 The VLAN identifiers and the subnet plan come from the institution's network team, not the security integrator. Coordinate at the design phase: the security install's VLANs are typically issued by the network team as part of the project network design. Document the assignments in the project administrative document so commissioning testing can verify against the design intent. 

 Configuration baseline 

 When the rule applies 

 Every switch starts from a documented configuration baseline at commissioning. The baseline is the hardening standard the institution expects on every device on its network. 

 The spec 

 
 Default credentials changed from factory defaults; new credentials managed in the institutional password vault 
 SSHv2 enabled for management; Telnet disabled 
 SNMPv3 enabled with authentication and encryption; SNMPv1 and v2c disabled 
 HTTP web management disabled; HTTPS enabled with the institutional certificate authority 
 NTP configured to the institutional time source; clock verified before any other configuration 
 Syslog forwarding configured to the institutional SIEM or NMS 
 TACACS+ or RADIUS authentication for administrative access, with local accounts as backup only 
 Spanning Tree Protocol enabled (RSTP or MSTP), with PortFast on access ports and BPDU Guard enabled 
 Port security configured per VLAN: maximum MAC addresses per port, violation action (shutdown or protect) per institutional policy 
 Unused ports administratively shut down 
 Banner message configured with the institutional access policy 
 Configuration backed up to the institutional configuration management system before commissioning sign-off 
 

 Study Note 

 The institution's network team owns the hardening standard. The security install's switches comply with it; do not invent your own baseline. Request the hardening template at design and apply it consistently across every switch on the project. Verify with the institutional security team at commissioning that the baseline is current; institutional standards update on their own cycle and you do not want to commission a switch to last year's standard. 

 Redundancy and high availability 

 When the rule applies 

 Switches in head-end, recording, and critical IDF locations on projects where the institutional design calls for high availability. The two main redundancy patterns are stacking (multiple physical switches operating as one logical switch) and MC-LAG (multi-chassis link aggregation for redundant uplinks). 

 The two patterns 

<DefList>
 <dt>Stacking</dt>
 <dd>Two or more switches connected with a stacking cable, presenting as a single logical switch with one IP address, one configuration, and shared uplinks. Stack supports hot-swap of failed stack member. Used at the access layer where one failed switch should not bring down the IDF.</dd>

 <dt>MC-LAG (Multi-Chassis Link Aggregation)</dt>
 <dd>Two independent switches sharing an LACP-bonded link to a single downstream device. The downstream device sees a single LAG even though the two uplinks terminate on two different switches. Used between distribution and access where uplink redundancy matters but full stacking is not warranted.</dd>
</DefList>

 The spec 

 
 Stacking within a single rack only (the stack cable is short, the stack is a single failure domain physically) 
 MC-LAG preferred over stacking for inter-rack redundancy 
 Redundant PSUs in every switch where the platform supports them 
 Each PSU on a separately-fed branch circuit per chapter 03 
 Stack member ID numbering documented in the as-built drawings 
 Failover testing at commissioning: pull power on one stack member or one MC-LAG peer, verify traffic continues to the served devices 
 

 Industrial and outdoor switches 

 When the rule applies 

 Switches installed in environments outside the typical office or equipment-room conditions: outdoor IDFs, transit stations, industrial buildings, parking structures, environmental cabinets. 

 The spec 

 
 DIN-rail mount for industrial cabinet installation 
 Operating temperature range: minimum -40°C to +75°C for outdoor and unconditioned spaces 
 Vibration rating: per the installation environment (typically IEC 60068-2-6 for transit, IEC 60068-2-27 for industrial) 
 Dust and water ingress rating: IP30 for indoor industrial, IP67 for harsh outdoor 
 Surge protection: IEC 61000-4-5 Level 4 on all interfaces 
 Redundant power input (dual-input 24 VDC or 48 VDC typical) 
 Managed configuration baseline matching the institutional standard, same as office-grade switches 
 

 Study Note 

 Cisco IE3300 series for industrial DIN-rail with 8 to 24 ports, PoE+ on selected models, full IOS configuration. Aruba CX 4100i series for industrial DIN-rail on HPE Aruba networks. Both rated for outdoor and industrial environments with the right SKU selection. Verify the temperature range and the PoE budget against the actual install conditions before ordering. 

 Network management and monitoring 

 When the rule applies 

 Every managed switch on the install. The switches integrate with the institutional Network Management System (NMS) for monitoring, alerting, configuration backup, and capacity planning. 

 The spec 

 
 Switch added to the institutional NMS at commissioning 
 SNMPv3 polling for interface statistics, CPU utilisation, memory utilisation, PoE budget consumption 
 Trap forwarding to the NMS for link state changes, environmental alarms, configuration changes 
 Syslog forwarding for security events, authentication events, configuration changes 
 Configuration backup to the institutional configuration management system on schedule 
 Monthly review of switch alerts and trending data by the institutional NOC; corrective action where degradation is observed 
 

 Study Note 

 The institutional Network Operations Centre owns the NMS. The security install's switches integrate with the existing NMS; the security install does not specify a separate NMS. Coordinate at design: which NMS, which authentication, which alert priority levels, which escalation paths. Build the integration into the commissioning plan. 

 Managed switches on every IDF and every equipment room. Cisco Catalyst 9300 or Aruba CX 6300M as the institutional default at the access layer; the institution's network team picks the distribution and core. Industrial DIN-rail switches (Cisco IE3300 or Aruba CX 4100i) in environmental cabinets and outdoor IDFs. PoE budget at 75 percent or below on each supply, with per-port priority and monitoring. Five VLANs minimum (cameras, access, intrusion, servers, management). Configuration baseline before commissioning: changed credentials, SSHv2 only, SNMPv3, NTP, syslog, TACACS or RADIUS, spanning-tree with PortFast and BPDU Guard. Integrate with the institutional NMS at commissioning. Do this and the network layer holds up for the institution's planning horizon.

================================================================

## Access control head-end

URL: https://hans.study/standards-guidance/cssir-12-access-control-head-end/
Type: kb
Date: 2026-05-10
Description: Access control head-end design for Canadian institutional installs. Platform selection, server sizing, Mercury hardware, HID Aero, Software House C-CURE, Genetec Synergis, Hirsch Velocity for high-security, database and high-availability, integration with directory and identity systems.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 The access control head-end is the brain of the system. The platform software runs on the server, the field hardware (controllers, readers, locks) connects back to the server through the network, and the credential database lives at the server. Every reader event, every door command, every audit log passes through the head-end. Picking the right platform, sizing the server correctly, and integrating with the institution's directory and identity systems at design determines whether the access control system holds up under operational load or becomes the institution's single most-frequent service call. 

 Platform classes 

 When the rule applies 

 Every access control project. The platform choice is made at design and is the largest single decision affecting the install's character. The four classes below cover most institutional Canadian work; the institution's preference, the federal compliance requirements, and the integrator's certification all influence the choice. 

 The four platform classes 

<DefList>
 <dt>Enterprise unified (Genetec Synergis)</dt>
 <dd>Genetec Synergis runs on the same Security Center platform as Genetec Omnicast video. Unified search, unified audit, single management interface across access, video, intrusion, and ALPR. IT-friendly, virtualisation-ready, large-deployment-ready. Strong fit for institutional projects where access and video are managed together.</dd>

 <dt>Traditional institutional (Software House C-CURE 9000)</dt>
 <dd>Software House C-CURE 9000 is a long-established institutional access platform. Mercury-based field hardware, mature integrations with video and intrusion through partner products. Strong fit for institutional projects standardising on the Software House ecosystem (federal, healthcare, education with existing C-CURE deployments).</dd>

 <dt>High-security / federal (Hirsch Velocity)</dt>
 <dd>Hirsch Velocity with Mx-1, Mx-2, Mx-4, Mx-8 controllers. FICAM and HSPD-12 compliance, supervised PIV and CAC card readers, the ScramblePad randomized PIN keypad for shoulder-surfing resistance. Strong fit for federal facilities, court facilities, evidence rooms, server rooms, critical infrastructure where supervised credential reading and PIN entry are mandatory.</dd>

 <dt>Hardware-first integrator (HID Aero, HID-direct deployments)</dt>
 <dd>HID Aero controllers (Mercury-compatible, HID-branded), HID Origo Mobile credentials, HID Signo readers. Smaller institutional or commercial deployments where the integrator manages the platform directly without a third-party VMS. Cloud-managed option (HID Origo Management) for distributed deployments.</dd>
</DefList>

 Other platforms in the market 

 Other access control platforms in the Canadian institutional market include AMAG Symmetry, LenelS2 OnGuard, RS2 Access It!, and Brivo (cloud). These are real platforms with real deployments and are mentioned here for market awareness; the field defaults across the chapters reference the four platform classes above. The platform choice on any specific project is the institution's call at design. 

 Mercury hardware: the layer underneath 

 When the rule applies 

 Every Software House C-CURE, Genetec Synergis (where Mercury is selected), HID Aero, and many other access control deployments. Mercury Security manufactures the controllers and subpanels that several platforms OEM and badge as their own. Understanding Mercury is the difference between treating the platform as a black box and being able to troubleshoot the field hardware effectively. 

 The Mercury product line 

 
 MP4502 : high-performance intelligent controller, two onboard doors expandable to 64 with subpanels, 2 million cardholders, BACnet/IP and elevator dispatch. Specify this where the door count or the integration list is the driver. 
 MP1502 : standard two-door intelligent controller, expandable to 64 doors with subpanels. The volume default on new institutional work. 
 MP2500 : intelligent controller with no onboard I/O, all doors served through subpanels, scales to 64. Use where the controller lives in a head-end cabinet and every reader is remote. 
 MP1501 : single-door intelligent controller for the isolated opening that does not justify a two-door board. 
 MR50 : single-reader subpanel, RS-485 to the controller, supports one door (in/out reader or in-only) 
 MR52 : two-reader subpanel, RS-485 to the controller, two doors per subpanel 
 MR16OUT : 16-output subpanel for monitoring and control points beyond doors 
 MR16IN : 16-input subpanel for monitoring points (door contacts, REX, alarms, supervisory points) 
 Legacy EP and LP series : EP1502, EP2500, EP4502 and the LP boards that followed them are superseded by the MP series. The MP boards keep the LP/EP footprint and interface, so a retrofit is a board swap rather than a rip-out. Do not put EP part numbers on a new bill of materials. 
 HID Aero is the HID-branded version of Mercury hardware, with the same product lineage and the same field installation 
 

 Study Note 

 Mercury manufactures the controllers and subpanels. Software House, Genetec, and many other platform vendors OEM the Mercury hardware and badge it. The hardware in the field is the same; the configuration is on the platform's management interface. Troubleshooting at the field hardware level is the same regardless of which platform is on top: same LEDs, same status indicators, same diagnostic procedure. HID Aero is HID's own Mercury-compatible product line, manufactured directly by HID; the configuration is HID's, but the field hardware is functionally equivalent to other Mercury controllers. 

 Server sizing 

 When the rule applies 

 Every head-end server on the project. The server is sized at design against the door count, the cardholder count, the event volume, and the institution's database retention policy. 

 The spec 

 
 CPU: enterprise-grade server CPU sized per the platform vendor's recommended sizing chart for the door and cardholder count 
 Memory: per vendor recommendation; typical institutional deployment 32 GB to 128 GB depending on size 
 Storage:: Operating system and application: 250 GB SSD minimum (RAID 1 mirrored) Database: SSD sized for active database plus retention window plus 100 percent growth (typically 500 GB to 2 TB on institutional installs) Audit log archive: separate storage volume, sized for the institution's retention period (typically 7 years; ask the institution at design) 
 Redundancy: RAID 1 or RAID 10 on database storage; RAID 1 on OS 
 Network: dual NIC bonded for redundancy and throughput 
 Power: dual PSU on separately-fed circuits per chapter 03 
 Hardware redundancy: high-availability cluster (two servers, synchronized database, failover at 60 seconds typical) where the institutional design calls for it 
 Virtualization: where the institution standardizes on VMware or Hyper-V, the head-end runs as a VM on the institutional virtualisation platform with reservations and resource guarantees matching the physical-server sizing 
 

 Study Note 

 Door and cardholder counts grow. Audit log volume grows. Database size grows. Size the server at design for the institution's 5-year projection, not the day-one load. The vendor's sizing chart typically has a "minimum" column and a "recommended" column; pick the recommended for institutional work, and add the growth headroom on top. 

 Database and high availability 

 When the rule applies 

 Every institutional access control deployment. The database holds the cardholder records, the door schedules, the access groups, the credential assignments, and the audit log. Database integrity and availability are the access control system's primary technical risks. 

 The spec 

 
 Database platform per the vendor: typically Microsoft SQL Server (Standard or Enterprise edition) for institutional access control platforms 
 Database licensing: SQL Server license aligned with the platform vendor's licensing model (typically SQL Server runtime included in the platform license) 
 Database backup: nightly full backup, transaction log backups every 15 minutes for institutional projects with high event volume 
 Backup storage: on a separate physical system from the database server, retained per the institutional retention policy 
 Database integrity check: nightly DBCC CHECKDB or vendor-equivalent 
 High-availability cluster: SQL Server AlwaysOn or vendor-supported HA configuration where the design calls for it; synchronous replication for the institutional database 
 Database server on the same VLAN segment as the head-end application server, with firewall rules permitting only the documented database traffic 
 

 Study Note 

 Most institutional projects have a database administration team that owns the SQL Server platform across the institution. The access control deployment's database lives within that team's purview. Coordinate at design: which SQL Server version, which backup schedule, which monitoring, which DR plan. The access control vendor's recommendations have to align with the institutional DBA standards. 

 Directory and identity integration 

 When the rule applies 

 Every institutional deployment where the cardholder records have to stay synchronised with the institution's identity management system (HR system, student information system, or active directory). 

 The spec 

 
 Directory integration with the institutional identity source: Active Directory, Microsoft Entra ID, or institutional HR/SIS system 
 Cardholder records synchronised at minimum daily, real-time where the platform supports it 
 Synchronisation defines: cardholder identifier, name, status (active/inactive), access group assignments, expiry date 
 De-provisioning: when the identity source marks a person inactive, the access control system's cardholder is deactivated within the synchronisation window 
 Provisioning: when the identity source creates a new active person, the access control system creates the cardholder record with the default access group assignment 
 Manual override at the access control side documented in the audit log: institutional security team can override the synchronised state with appropriate authorisation 
 Audit trail: every synchronisation event, every override, every access group change recorded 
 

 Study Note 

 Modern institutional deployments increasingly use federated identity (SAML 2.0, OIDC) instead of direct LDAP integration. The access control platform vendor's roadmap typically includes federated authentication for the administrator interface and synchronisation feeds from cloud HR systems for the cardholder database. Verify at design what the institution's identity team supports; some institutional platforms are mid-migration and the access control platform needs to align with the target state. 

 Network communication between head-end and field 

 When the rule applies 

 Every door, every reader, every subpanel on the install. The IP backhaul from the field controllers to the head-end is the data path for credential decisions, audit logging, and command-and-control. 

 The spec 

 
 IP backhaul from every Mercury or HID Aero controller to the head-end server on the access control VLAN 
 TLS on every controller-to-head-end connection. Current MP-series boards do TLS 1.3 with secure boot and FIPS 140-3 validation, so specify 1.3 and enable it. Legacy EP and LP hardware tops out at TLS 1.2, which is the floor to accept on a retrofit and a reason to plan the board refresh rather than live with it. 
 Controller-to-subpanel communication: RS-485 over the manufacturer's specified cable (typically 24 AWG or 22 AWG twisted-pair, 22 AWG required for longer runs) 
 RS-485 line length: 1200 m (4000 ft) maximum per the EIA-485 standard; termination resistors at both ends of the line 
 Cache mode at the controller: when the head-end is unreachable, the controller continues to make access decisions from its local cardholder cache; events buffered locally and forwarded when communication is restored 
 Heartbeat from controller to head-end at minimum 60-second interval; alert at head-end if heartbeat is missed for 3 intervals 
 

 Study Note 

 When the head-end is unreachable (network outage, server reboot, planned maintenance), the controller continues to make access decisions from its local cardholder cache. Verify the cache size matches the institution's cardholder count at design (some smaller controllers have cache limits that constrain how many cardholders they can hold). Verify the controller's offline event buffer is large enough to hold a typical outage's worth of events (typically several thousand events buffered locally). 

 System monitoring and audit logging 

 When the rule applies 

 Every deployment. The audit log is the institutional record of who accessed where and when. The monitoring is the operational visibility for the security team and the integrator. 

 The spec 

 
 Audit log retention per institutional policy (typically 7 years for institutional, longer for federal and healthcare) 
 Audit log content: every cardholder addition / modification / deletion, every access decision (granted / denied / suspect), every administrator action, every system event 
 Audit log integrity: log writes signed or otherwise tamper-evident, log retention to write-once storage where the institutional policy requires 
 Operational monitoring: real-time alarm display for door-held-open, door-forced, communication failure, tamper, low battery 
 Reporting: standard reports (daily activity, access denials, after-hours access, cardholder activity) scheduled and delivered to the institutional security team 
 SIEM integration: audit log forwarded to the institutional SIEM (Splunk, Microsoft Sentinel, or equivalent) for correlation with other security events 
 

 The head-end is the brain. Pick the platform class at design against the institution's needs: Genetec Synergis for unified access-and-video, Software House C-CURE for traditional institutional, Hirsch Velocity for federal and high-security, HID Aero for hardware-first deployments. Mercury hardware is the field layer under most of these; understand it independently of the platform. Size the server for 5-year growth, configure database backup and high availability, integrate with the institutional identity source. The IP backhaul is encrypted, the local cache handles network outages, the audit log retention meets institutional policy. Get the head-end design right at the start and the system scales with the institution; get it wrong and the redesign happens at the worst possible time.

================================================================

## Access control at the door

URL: https://hans.study/standards-guidance/cssir-13-access-control-at-the-door/
Type: kb
Date: 2026-05-10
Description: Access control hardware at the door for Canadian institutional installs. Reader selection, OSDP vs Wiegand, electric strikes, maglocks, exit devices, door operators, REX devices, door position switches, fire alarm release, wiring topology, mounting heights, ADA compliance.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 The door is the work made visible. Every other layer of the system serves the door: the cable plant carries the signal, the controller makes the decision, the head-end logs the event, but the door is where the credential meets the lock and the user decides whether the install is good or bad. Get the door layer right (the right reader, the right lock for the door type, the right wiring topology, the right egress hardware, the right fire alarm interface) and every other layer holds up. Get it wrong and every defect ends up at the door because that is where the user encounters it. 

 Reader selection 

 When the rule applies 

 Every reader on every door. The reader is the user interface to the access control system; the wrong reader is the most visible defect on the install. 

 The spec 

 
 Credential technology: 13.56 MHz secure smart card (HID iCLASS Seos, MIFARE DESFire EV3, or equivalent) for new institutional work. 125 kHz Prox and legacy 13.56 MHz iCLASS Standard / SE acceptable on retrofits where the existing credential population justifies them. 
 Communication protocol: OSDP v2.2 with Secure Channel for new work. Wiegand on retrofits only, with a defined migration to OSDP at the next refresh. 
 Mobile credential support: BLE / NFC where the institution's credential plan includes mobile (HID Origo, Apple Wallet, or institutional equivalent) 
 Reader form factor:: Wall-mount mullion reader (slim, for narrow door frames) Wall-mount single-gang reader (general institutional default) Keypad-and-card reader for high-security applications requiring two-factor (card plus PIN) Randomized PIN keypad (Hirsch ScramblePad) for very high-security applications: federal, courts, evidence rooms, server rooms, critical infrastructure 
 Reader environmental rating: IP65 minimum for outdoor; IP54 for semi-exterior; standard indoor for interior dry locations 
 Reader operating temperature range: -35°C to +66°C for Canadian outdoor; -10°C to +50°C for indoor 
 Reader vandal rating: IK10 for public-access entries, transit, education common areas 
 

 OSDP versus Wiegand 

 Wiegand is the legacy reader-to-controller protocol that dominated the industry from the 1980s through the 2010s. It is unencrypted, unauthenticated, susceptible to cloning attacks at the wire (a $20 device taped to the reader cable can capture the credential and replay it later), and limited to 50 feet of cable run without signal amplification. OSDP (Open Supervised Device Protocol) v2.2 with Secure Channel is the modern replacement: encrypted, authenticated, supervised, RS-485-based with 4000 ft of cable run. 
 Specifying Wiegand on a new institutional build is creating a defect at install. Use OSDP v2.2 with Secure Channel on every reader on new work; if the institution has a Wiegand fleet on retrofit, document the migration plan. 

 Study Note 

 HID Signo reader family for new institutional work: Signo 20, Signo 40, Signo 40K (keypad-and-card), supporting OSDP v2.2 with Secure Channel and HID iCLASS Seos credentials. HID Origo Mobile for mobile credentials where the institution's plan includes them. For high-security PIN entry: Hirsch ScramblePad (randomized keypad, the only product where the digit layout shuffles between presses, defeating shoulder-surfing and PIN capture). 

 Lock hardware selection 

 When the rule applies 

 Every door under access control. The lock has to match the door type, the door material, the fire rating, and the egress requirements for the occupancy. 

 The four common lock types 

<DefList>
 <dt>Electric strike</dt>
 <dd>Replaces the door frame's strike plate with an electrically-controlled latch keeper. The latch on the door remains mechanical and engages the strike. On energise (typically 24 VDC) the strike releases the latch. Fail-secure (default locked) or fail-safe (default unlocked) by model selection. Used on most institutional doors with mechanical latches.</dd>

 <dt>Magnetic lock (maglock)</dt>
 <dd>Electromagnet on the door frame, steel plate on the door. Continuous holding force (typical 600 to 1200 lb). Always fail-safe by physics (no power, no holding force). Used where mechanical latches are impractical, on glass doors, on aluminum-frame doors. Code-restricted in some occupancies; not used on egress-rated doors without code review.</dd>

 <dt>Electric mortise lock</dt>
 <dd>Mortise lock with electric latch retraction. The lock itself is in the door; the access control energizes the latch retraction solenoid. Provides full mortise hardware (handle, deadbolt) with electronic control. Used on high-traffic doors where mechanical handle operation is required.</dd>

 <dt>Electrified panic exit device</dt>
 <dd>Exit device (push bar) with integrated electric latch retraction. The exit device provides code-compliant egress; the electric component controls the entry side. Used on egress doors in assembly occupancies and on stairwell doors.</dd>
</DefList>

 The spec 

 
 Egress: always permit egress from the secure side, without special knowledge, without special tools, without more than one operation 
 Fire-rated door: lock must be fire-rated for the same hour rating as the door (UL10C / CAN/ULC-S104) 
 Stair door: lock must allow re-entry from the stair side per the building code (typically every fourth floor minimum, plus discharge level) 
 Voltage: 12 VDC or 24 VDC per the institutional standard; 24 VDC preferred for long runs (chapter 03) 
 Fail mode: fail-safe (default unlocked on power loss) for emergency egress paths; fail-secure (default locked) for security-critical doors. Verify against the project specification and the AHJ. 
 Monitoring: door position switch (DPS), latch monitor, and lock status monitor inputs back to the controller 
 Cycle life: minimum 1,000,000 cycles for high-traffic doors 
 Manufacturer warranty: minimum 3 years on lock hardware; some manufacturers offer 5- and 10-year warranties on heavy-duty product lines 
 

 Study Note 

 Allegion / Schlage L-series mortise locks and ND-series cylindrical locks for general institutional work. Allegion / Von Duprin 99 series electrified panic exit devices for egress doors. Allegion / Securitron M380 and M680 maglocks where maglocks are appropriate (1200 lb and 600 lb holding force). Allegion / LCN 4640 series low-energy ADA door operators for accessibility-required doors. Electric strikes from the Allegion / HES product line, sized to the door's existing strike pocket. 
 The Allegion ecosystem is the institutional default because the parts integrate cleanly: lock, strike, exit device, operator, power supply all from one manufacturer with one warranty programme and one field service contact. 

 Door power supplies 

 When the rule applies 

 Every access-controlled door needs DC power for the lock and the reader. The supply is sized for the worst-case load, fused per output, and UL294 / ULC-S319 listed for access control use. 

 The spec 

 
 UL294 / ULC-S319 listed access control power supply 
 Multi-output: each door on a separately-fused output to isolate failures 
 Voltage output: 12 VDC and 24 VDC as required by the connected hardware; some supplies provide both 
 Current capacity: sized for the worst-case load plus inrush plus 25 percent margin (chapter 03) 
 Battery backup: 4 hours minimum for life-safety-related access (egress controllers, sallyport interlocks, detention); 24 hours for intrusion-shared circuits per ULC-S304 
 Battery type: sealed lead-acid (SLA) standard; lithium-iron-phosphate where the institutional spec calls for extended life 
 Battery monitor: per-supply battery voltage and current monitoring with alarm output to the head-end 
 Fire alarm interface: dedicated dry-contact input that, on activation, drops power to all fail-safe locks and holds-open the maglocks per the institutional fire release strategy 
 Tamper switch: cabinet-tamper input back to the controller 
 

 Study Note 

 Allegion / Securitron AQL4 and AQL8 series multi-output access control power supplies, UL294 / ULC-S319 listed. AQL4 for typical institutional installations with 4 to 8 doors per supply; AQL8 for larger installations with up to 16 doors per supply. Both support per-output fusing, battery monitoring, fire alarm interface, and tamper monitoring. Battery backup sized per the institutional retention requirement: standard SLA in the matching battery cabinet, with the monitoring output back to the head-end. 

 Door position switches and REX devices 

 When the rule applies 

 Every access-controlled door. The door position switch (DPS) reports door open/closed to the controller. The Request-to-Exit (REX) device unlocks the door from the secure side for egress, shunting the door-forced alarm during egress. 

 The spec 

 
 DPS: balanced magnetic or recessed magnetic switch on the strike side at the top of the door frame, 50 mm (2") in from the frame edge 
 DPS supervision: 4-wire end-of-line resistor pair for monitored alarm input (open, closed, short, cut) 
 REX device options:: PIR sensor above the door on the secure side (most common for general institutional work) Mechanical pushbutton on the secure side at 1100 to 1200 mm (44 to 48") AFF Mechanical handle switch integrated into the lock (electric mortise locks) Push bar switch integrated into the exit device (electrified exit devices) 
 REX signal sent to the controller, which shunts the door-forced alarm and releases the lock for fail-secure doors 
 REX does not unlock fail-safe maglocks except by separate release input (most maglocks need a separate Request-to-Exit button wired to drop the power; the REX input alone does not break the magnet circuit) 
 REX adjustment: PIR-based REX adjusted at commissioning to cover the egress path without nuisance triggers from passing traffic 
 

 Study Note 

 A maglock on a building code-compliant egress door has to release on three independent signals: the REX request (PIR or button), the fire alarm interface, and a hardwired egress device on the door (typically a push-to-exit button labelled "EXIT" at the door). All three signals have to drop the power to the maglock, not just signal the controller; the maglock's failure mode is fail-safe by physics but the controller's relay may be the failure point if not wired correctly. Verify the wiring topology at design and the test at commissioning. 

 Fire alarm release 

 When the rule applies 

 Every door under access control. The building code requires that every egress door release on fire alarm; the access control system's interface to the fire alarm system is the integration point that makes this happen. 

 The spec 

 
 Dedicated dry-contact relay from the fire alarm system to the access control power supply or to a dedicated release interface 
 On fire alarm activation, the relay opens (fail-safe configuration), dropping power to fail-safe locks and maglocks 
 Release scope per the institutional release strategy:: Building-wide release: every door on the building releases (typical for office, retail, education) Zone release: doors on the affected fire zone release; doors on other zones remain controlled (typical for high-rise, healthcare, detention) Smoke compartment release: doors in the affected compartment release (typical for healthcare) 
 Release interface tested at commissioning per CAN/ULC-S1001 integrated systems testing 
 Release interface tested annually by the fire alarm contractor under CAN/ULC-S537 
 Fail-secure doors not released by fire alarm typically (controlled by the institutional release strategy; verify against the AHJ and the institutional life-safety design) 
 

 Study Note 

 The institutional release strategy varies by occupancy type, by AHJ, and by the institution's preference. Some institutions release every door on every alarm; others zone the release to the fire compartment; healthcare often does smoke-compartment release. Verify the strategy at design with the fire alarm consultant and the AHJ. Build the verification into the commissioning checklist (chapter 22) so every release is tested at acceptance. 

 Door wiring topology 

 When the rule applies 

 Every access-controlled door. The wiring topology is the cable plan from the door hardware to the controller; consistency across the install determines maintainability. 

 The spec 

 
 Reader cable: OSDP requires twisted-pair RS-485 cable, typically 4-conductor (TX+, TX-, +12 VDC, GND) or 6-conductor with shield and drain. Belden 9842 or equivalent. Maximum 4000 ft per RS-485 segment. 
 Lock power cable: stranded copper, AWG sized per chapter 03 voltage drop tables. Belden 5300UE or equivalent for typical 18 AWG / 16 AWG runs. 
 DPS cable: 2-conductor 22 AWG shielded, with end-of-line resistors at the device for supervised input 
 REX cable: same as DPS (2-conductor 22 AWG shielded) for PIR or button 
 Door junction box: single-gang or 4-square box at the door header, conduit-fed to the controller 
 WAGO 221 lever-action connectors at the door junction box for every wire-to-wire connection (chapter 09) 
 Service slack at the door junction box: 300 mm (12") minimum coiled in the box for future service 
 Cable identification at both ends per chapter 06 
 

 Pigtail-and-service-loop at the lock 

 The cable from the controller terminates at the door junction box with WAGO 221 lever-action connectors. From the junction box to the lock, the lock manufacturer's pigtail (the short factory-supplied cable on the lock body) connects to the field cable. This serviceable pigtail-and-junction-box topology lets a future technician replace the lock without re-pulling cable; the replacement lock's pigtail joins to the existing junction-box wires at the WAGO connector. Skip the junction box and the next lock replacement becomes a cable re-pull. 

 Mounting heights and ADA compliance 

 When the rule applies 

 Every reader, every operator button, every keypad, every accessible egress device. CSA B651 and the building code's accessibility section define the height ranges; the project specification may tighten them further. 

 The spec 

 
 Card reader, general: 1100 mm (44") to centre, ADA-compliant; 1200 mm (48") to centre where ADA does not apply 
 Card reader paired with door operator: 1000 mm (40") to centre, coordinated with the operator push plate height 
 Door operator push plate: 900 to 1200 mm (35 to 48") AFF, 100 mm (4") minimum diameter actuator, ADA-compliant force activation 
 Door operator push plate location: 150 to 600 mm (6 to 24") from the door swing edge (so the user is clear of the swinging door) 
 Egress button (push-to-exit on maglock): 1100 to 1200 mm (44 to 48") AFF, labelled "EXIT" with high contrast 
 Keypad: 1100 to 1300 mm (44 to 51") AFF to top row of keys, with consistent height across the project 
 Door position switch: at the top of the door frame, strike side, 50 mm (2") in from the frame edge (not user-accessible) 
 REX PIR: above the door frame on the secure side, centred over the clear opening 
 

 Study Note 

 Accessibility requirements vary by jurisdiction and by occupancy type. Verify the project specification's accessibility requirements against CSA B651 and the local building code at design. Some projects require Reach Range A (low forward reach 380-1220 mm; high forward reach 1220 mm) for all controls; others allow Reach Range B for non-public spaces. Get the height schedule signed off by the architect and the accessibility consultant at design, then the field work just follows the schedule. 

 Two-factor authentication: card-plus-PIN 

 When the rule applies 

 High-security doors where the institution's policy requires two-factor authentication. Common applications: server rooms, evidence storage, pharmacy and controlled substances, financial transaction rooms, IT command centres. 

 The spec 

 
 Reader with integrated keypad supporting card presentation followed by PIN entry 
 PIN length: 4 to 8 digits per institutional policy; 6 digits is the institutional default for balance between security and usability 
 Lockout: 3 to 5 failed PIN attempts triggers a temporary lockout (typically 15 to 30 minutes) and an event to the head-end 
 PIN entry timeout: 10 to 30 seconds between card and PIN; controller cancels the authentication if PIN entry exceeds the timeout 
 Schedule: two-factor activated by time-of-day schedule (typically after hours and on weekends; single-factor card during business hours when the area is staffed) 
 PIN reset: cardholder-self-service through the institutional credential portal, or administrator reset through the head-end 
 For high-security applications, randomized PIN keypad (Hirsch ScramblePad) instead of fixed-layout keypad 
 

 Hirsch ScramblePad for very high security 

 The Hirsch ScramblePad is a randomized PIN keypad: the digit layout shuffles between presses so an observer cannot map the user's finger movement to a specific PIN. The ScramblePad is the institutional choice for very high-security applications where shoulder-surfing and PIN-capture are documented threats: federal facilities, courts, evidence rooms, server rooms, critical infrastructure. The ScramblePad integrates with most access control platforms through OSDP or Wiegand and pairs with a smart card reader for two-factor authentication. 
 For other applications (general two-factor where shoulder-surfing is not the primary threat), a fixed-layout keypad is adequate and lower-cost. Pick the keypad type at design against the documented threat model. 

 The door is the work made visible. Every reader on new institutional work is OSDP v2.2 with Secure Channel and 13.56 MHz secure smart card credentials; Wiegand on retrofits only. Allegion / Schlage locks, Allegion / Von Duprin exit devices, Allegion / Securitron maglocks and power supplies, Allegion / LCN ADA operators integrate cleanly because they come from one ecosystem. Mount every reader and operator at ADA-compliant height. Wire every door through a junction box with WAGO 221 lever-action connectors. Fire alarm release strategy verified at design and tested at commissioning. Two-factor authentication where the institution's policy requires it; Hirsch ScramblePad for very high-security PIN entry. Every door specified, installed, and commissioned this way passes the user-experience test that everyone applies after the install is done.

================================================================

## CCTV and video

URL: https://hans.study/standards-guidance/cssir-14-cctv-and-video/
Type: kb
Date: 2026-05-10
Description: Video surveillance for Canadian institutional installs. Camera type by application, resolution and PPF/PPM, lens selection, mounting heights and angles, VMS platforms, storage sizing, retention, privacy and regulatory compliance, banned manufacturers, network design.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Video surveillance is the layer the institution measures by recording quality, not by camera count. A site with twenty cameras that can identify a face is more useful than a site with eighty cameras that capture motion but cannot resolve a feature. The discipline in CCTV design is matching the camera, the lens, the resolution, the lighting, and the mounting position to the answer the institution needs the recording to deliver. Get the design right and the recording answers the question; get it wrong and the recording is decoration. 

 Camera type by application 

 When the rule applies 

 Every camera on the install. The decision among fixed dome, fixed bullet, PTZ, multi-sensor, and specialty cameras depends on the scene and on the institutional answer the recording has to deliver. 

 The five common camera types 

<DefList>
 <dt>Fixed dome</dt>
 <dd>Single sensor, fixed lens or motorised varifocal, hemispherical or cylindrical housing. Used indoors and outdoors for general coverage of a defined scene. Aesthetically neutral, hard to determine the camera's exact pointing direction from below.</dd>

 <dt>Fixed bullet</dt>
 <dd>Single sensor, fixed lens or motorised varifocal, exterior cylindrical housing. Used outdoors where a longer focal length and dedicated IR illumination are needed and where the bullet's silhouette is acceptable. Less aesthetically neutral than a dome; more visible as a deterrent.</dd>

 <dt>PTZ (pan-tilt-zoom)</dt>
 <dd>Motorised pan and tilt, optical zoom (typical 30× to 40× on institutional models). Used on large open scenes where one camera covers what would otherwise require multiple fixed cameras. Requires an operator to drive the camera in real-time, or pre-set tour patterns for unattended coverage.</dd>

 <dt>Multi-sensor</dt>
 <dd>Multiple sensors in one housing, typically 4 or 8 sensors covering a 180° or 360° panoramic field. Used in corridors, parking lots, and open areas where the alternative is multiple cameras with overlapping coverage. Higher single-unit cost; lower install labour.</dd>

 <dt>Specialty</dt>
 <dd>Thermal cameras for perimeter detection in low-light or no-light conditions. Long-range cameras for runway, terminal, or perimeter applications. Explosion-proof cameras for classified hazardous locations. License plate recognition (LPR/ALPR) cameras for vehicle entry tracking.</dd>
</DefList>

 The spec 

 
 Resolution: minimum 1080p (2 MP) for new institutional work; 4K (8 MP) where face or licence-plate identification is the recording goal 
 Frame rate: 15 fps minimum for general coverage; 30 fps for identification and forensic applications 
 Low-light performance: starlight or near-starlight sensor for cameras in areas with night-time activity; IR illumination on bullet cameras for full darkness 
 Wide dynamic range (WDR): 120 dB minimum for cameras facing windows or doorways with mixed lighting 
 Compression: H.265 (HEVC) standard; H.264 acceptable on retrofit where the VMS does not support H.265 
 Environmental rating: IP66 minimum outdoor, IP67 for harsh environments, IK10 vandal-resistance for public-access areas 
 Operating temperature: -35°C to +60°C minimum for Canadian outdoor work; integrated heater on outdoor camera bodies 
 Cybersecurity: cameras compliant with the institutional cybersecurity baseline (chapter 11): firmware current, default credentials changed, only required protocols enabled 
 

 Study Note 

 Axis is the institutional default for IP cameras on most projects: P3225-LVE for fixed dome indoor/outdoor, P1448-LE for fixed bullet outdoor, P5655-E for PTZ, P3737-PLE for multi-sensor panoramic. Bosch FLEXIDOME IP starlight 8000i family for low-light intensive applications. Avigilon H6A series for very high resolution (up to 4K and beyond) and where the Avigilon analytics package is the institutional standard. 
 Pick one camera manufacturer per project where possible; the firmware, the management tools, and the analytics packages integrate more cleanly when the fleet is single-vendor. 

 Banned manufacturers 

 The Government of Canada and several provincial governments have issued procurement restrictions on specific video surveillance manufacturers (Hikvision, Dahua, and certain OEMs that resell Hikvision or Dahua hardware) due to documented cybersecurity and supply-chain concerns. Verify the institution's eligibility list before specifying cameras. An approved-vendor list is part of the design phase, not a discovery at commissioning. Install banned hardware and you replace it at your own cost. 

 Resolution and pixels-per-foot 

 When the rule applies 

 Every camera on the project. The pixels-per-foot (PPF) or pixels-per-metre (PPM) at the target distance is the math that determines whether the camera can identify, recognise, observe, or just detect a subject. 

 The four PPF tiers 

<DefList>
 <dt>Identification (80 PPF / 250 PPM)</dt>
 <dd>The recording resolves enough detail to identify a face or a licence plate. Required for evidentiary use. Cameras specified for this purpose are placed close to the target scene and use the focal length the math requires.</dd>

 <dt>Recognition (40 PPF / 125 PPM)</dt>
 <dd>The recording resolves enough detail to recognise a known subject (a person the operator already knows). Used for general internal investigation and known-person surveillance.</dd>

 <dt>Observation (20 PPF / 65 PPM)</dt>
 <dd>The recording resolves enough detail to observe activity (what the subject is doing). Used for general activity monitoring.</dd>

 <dt>Detection (10 PPF / 30 PPM)</dt>
 <dd>The recording resolves enough detail to detect that a subject is present. Used for area coverage where the goal is to know that something happened, not who did it.</dd>
</DefList>

 The math 

 PPF = sensor horizontal resolution (pixels) divided by scene horizontal width (feet). 
 Example: A 4 MP camera (2688 × 1520 pixels horizontal × vertical) viewing a scene that is 25 feet wide produces 2688 / 25 = 107 PPF. That meets the identification standard (80 PPF) with margin. 
 Example: A 2 MP camera (1920 × 1080) viewing a scene that is 30 feet wide produces 1920 / 30 = 64 PPF. That meets recognition (40 PPF) but not identification (80 PPF). Either move the camera closer, increase the focal length, or upgrade to a 4 MP sensor. 

 The spec 

 
 Building entries and vestibules: 80 PPF (identification) for face capture 
 Public-access corridors and lobbies: 40 PPF (recognition) for general activity monitoring 
 Open offices, classroom corridors: 20 PPF (observation) 
 Parking lots and exterior perimeters: 40 PPF (recognition) at the area of interest, 20 PPF (observation) at the perimeter 
 Loading docks: 80 PPF (identification) at the loading face for licence plate capture 
 Detention cells: 40 PPF (recognition) minimum on every viewable surface 
 Public transit platforms: 40 PPF (recognition) at boarding zones 
 

 Lens selection and focal length 

 When the rule applies 

 Every fixed camera. The lens determines the field of view (FOV) and, combined with the sensor resolution, the PPF. 

 The spec 

 
 Motorised varifocal lens for institutional work: the lens range covers the typical 2.7 to 12 mm or 9 to 22 mm depending on application, allowing field adjustment without lens change 
 Fixed lens acceptable for cameras with a stable, well-defined scene 
 Wide-angle lens (under 4 mm) for very close coverage; introduces barrel distortion at the edges 
 Telephoto lens (over 12 mm) for distant subjects; narrows the FOV, requires careful aim and stable mount 
 Sensor format match: full-frame, 1/1.8", 1/2", 1/3" sensors paired with lenses rated for the format 
 Aperture: f/1.4 to f/2.0 for low-light applications; the wider aperture pulls more light onto the sensor at night 
 IR-corrected lens for cameras with IR illumination; non-corrected lens shifts focus between visible and IR light, producing soft IR images 
 

 Mounting heights and angles 

 When the rule applies 

 Every camera. The mounting height and angle determine the scene the camera sees and the PPF achieved at the target distance. 

 The spec 

 
 Indoor general coverage: 2700 mm (9 ft) AFF minimum, mounted to the structural ceiling or to a wall 
 Indoor identification (face capture at entries): 2400 mm (8 ft) AFF, angled to capture face at the target distance 
 Outdoor perimeter: 4000 mm (13 ft) AFF minimum, on a building exterior or pole, with vandal-resistance considered for public-access elevations 
 Outdoor parking lot: 6000 to 9000 mm (20 to 30 ft) on a pole, providing a wide-area view with the lens choice determining specific PPF 
 Detention holding cell: 3700 mm (12 ft) AFF minimum, with anti-ligature hardware and tamper-resistant fasteners, fed from the secure side of the wall (chapter 16) 
 Stairwell: at the landing, angled to capture both the stairs above and the landing area 
 Elevator interior: at the upper corner opposite the door, angled down toward the door area 
 Angle below horizontal: 15° to 45° typical for general coverage; lower angles capture more area at lower PPF, higher angles capture less area at higher PPF 
 

 Study Note 

 Camera design tools (Axis Site Designer, JVSG IP Video System Design Tool, IPVM Camera Calculator) let you mock up the camera position, the lens, and the PPF before procuring hardware. Use them at design to confirm the camera meets the PPF target for the application. Iterate the design until the math works; field-adjusting an under-spec'd camera is rework that the institution sees as a defect. 

 VMS platform selection 

 When the rule applies 

 Every video install. The VMS is the platform that records the cameras, manages playback, and serves video to operators and to investigations. 

 The institutional VMS options 

<DefList>
 <dt>Genetec Omnicast</dt>
 <dd>Part of the Genetec Security Center unified platform. Manages cameras alongside access control (Synergis), ALPR (AutoVu), and intrusion. Strong fit where the institution standardises on the Genetec unified platform.</dd>

 <dt>Milestone XProtect</dt>
 <dd>Open-platform VMS with strong third-party integration ecosystem. Available in Express, Professional+, Expert, and Corporate editions for different deployment sizes. Strong fit for institutional deployments with diverse camera fleets.</dd>

 <dt>Avigilon Control Center (ACC)</dt>
 <dd>Closely integrated with Avigilon camera hardware, with advanced analytics (Avigilon Appearance Search, Unusual Motion Detection) included on the H4 and H6 camera families. Strong fit where Avigilon cameras are the institutional fleet.</dd>

 <dt>Bosch BVMS (Video Management System)</dt>
 <dd>Bosch's enterprise VMS, integrated with Bosch camera hardware. Strong fit on Bosch-standardised institutional deployments.</dd>

 <dt>Software House C-CURE with video integration</dt>
 <dd>C-CURE 9000 with American Dynamics victor unified client integrating Milestone or other VMS. Strong fit where C-CURE is the access platform and video integrates through victor.</dd>
</DefList>

 Study Note 

 The VMS choice is the institution's call at design. Most institutional deployments have a preferred VMS or a multi-site standardised VMS that the new install integrates into. Coordinate at design with the institution's security technology team to confirm: which VMS, which version, which licensing model, which storage architecture. Build the design around the institutional VMS rather than introducing a new platform on a single project. 

 Storage sizing and retention 

 When the rule applies 

 Every recording deployment. The storage is sized at design against the camera count, the resolution, the frame rate, the compression, and the retention period. 

 The spec 

 
 Retention period: per institutional policy (typically 30 days for general institutional, 90 days for healthcare, 1 to 2 years for detention and high-security) 
 Bit rate per camera: vendor-provided for the specific camera, resolution, frame rate, and compression; typical 2 MP H.265 continuous record is 2 to 4 Mbps per camera 
 Storage = (number of cameras) × (bit rate Mbps) × (retention seconds) / 8 (bits to bytes) × (1.10 overhead margin) 
 Storage architecture: direct-attached storage (DAS) for small installations, network-attached storage (NAS) for medium, storage area network (SAN) for enterprise 
 RAID protection: RAID 6 minimum for institutional video storage (tolerates two simultaneous drive failures) 
 Storage drives: enterprise NL-SAS or enterprise SATA, rated for 24/7 surveillance workload (not consumer drives) 
 Drive size: 8 TB to 16 TB enterprise surveillance drives are the typical 2026 institutional choice 
 Storage volume monitoring: drive health, RAID state, capacity utilisation reported to the institutional NOC 
 

 Worked example 

 50 cameras at 2 MP, H.265, 15 fps, continuous recording, 30-day retention: 50 × 3 Mbps × (30 days × 86400 sec/day) / 8 × 1.10 = 50 × 3 × 2,592,000 / 8 × 1.10 = 53.5 TB usable. With RAID 6 overhead on a typical 8-drive array of 12 TB drives (96 TB raw, 72 TB usable after RAID 6), the array supports the 30-day retention with headroom for growth. 
 Same 50 cameras with 90-day retention (healthcare or institutional standard): 160.5 TB usable. Two 8-drive arrays of 14 TB drives (RAID 6, 168 TB usable total) supports it. 

 Privacy and regulatory compliance 

 When the rule applies 

 Every video install in Canada. PIPEDA federally, plus provincial privacy legislation (PIPA in BC and Alberta, FIPPA and PHIPA in Ontario, similar in other provinces) govern personal information collection through video surveillance. 

 The spec 

 
 Signage: visible notification at every entry to a video-monitored area, identifying the operator and providing contact information per provincial privacy guidance 
 Audio recording: disabled by default on every camera; audio capture requires institutional privacy office review and additional signage 
 Camera coverage: cameras positioned to avoid capturing areas where privacy expectation is high (washrooms, change rooms, residence rooms, treatment areas) unless explicitly authorised by institutional policy 
 Retention: minimum required for the institutional purpose, no longer than policy permits (over-retention is a privacy violation in some jurisdictions) 
 Access to recordings: restricted to authorised users with documented business purpose; access logged in the VMS audit trail 
 Disclosure: recordings released only on legal authority (warrant, court order, or institutional disclosure process) 
 Privacy Impact Assessment (PIA): conducted for new institutional video installations; updated when significant changes are made 
 

 Study Note 

 The institutional privacy office is the authoritative voice on what cameras can be installed and where. Coordinate at design and confirm at commissioning. Cameras in patient rooms, residence rooms, treatment areas, and similar high-privacy spaces require explicit written authorisation; do not energise such cameras until the authorisation is in hand. Cable and mount the cameras during the install but leave them disabled until the privacy office signs off. 

 Camera network design 

 When the rule applies 

 Every IP video install. The camera traffic is high-bandwidth, latency-sensitive, and continuous. Network design for cameras is different from network design for data. 

 The spec 

 
 Dedicated VLAN for cameras, isolated from data and management traffic (chapter 11) 
 Bandwidth per camera summed at design; switch uplinks sized for the aggregate plus 50 percent margin 
 QoS: cameras and VMS server prioritised over general data traffic at the switch 
 Multicast vs unicast: multicast where the VMS supports it (reduces network load when multiple operators view the same camera) 
 Camera and VMS firewall: cameras restricted to talk only to the VMS server and the management workstation; no internet access except for documented firmware update sources 
 NTP from the cameras to the institutional time source for accurate timestamp on recordings 
 Camera cybersecurity baseline: default credentials changed, firmware current, only required protocols enabled (HTTPS, ONVIF, RTSP if used; Telnet and unused services disabled) 
 

 Video is recording quality, not camera count. Design every camera against a PPF target tied to the institutional purpose: identification at entries, recognition at corridors, observation at general areas. Axis is the institutional default for IP cameras, Bosch for low-light intensive applications, Avigilon where the Avigilon analytics package is required. Verify the institution's procurement restrictions before specifying any camera (Hikvision and Dahua are restricted federally and in several provinces). Pick the VMS the institution standardises on (Genetec Omnicast, Milestone XProtect, Avigilon Control Center, Bosch BVMS). Size storage for the retention period plus 10 percent margin. Coordinate privacy and signage with the institutional privacy office before commissioning. Get this right and the recording answers the question; get it wrong and the recording is decoration.

================================================================

## Intrusion detection

URL: https://hans.study/standards-guidance/cssir-15-intrusion-detection/
Type: kb
Date: 2026-05-10
Description: Intrusion detection for Canadian institutional installs. ULC-S304 / S319 compliance, panel selection, sensor types (PIR, glassbreak, contact, beam, LiDAR), zone design, supervised wiring, central station monitoring, false alarm reduction, EOL resistor supervision.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Intrusion detection is the supervised loop that tells the institution something is wrong. Where access control says who can come in, intrusion detection says when someone is in who should not be. The work is straightforward (panel, sensors, supervised zone wiring, central station reporting), and the discipline is in the zone design, the false-alarm reduction, and the ULC-listed monitoring path. Get those right and the system catches the events it should; get them wrong and the system catches every shopping cart, every cleaner, every HVAC cycle, until the central station ignores it. 

 The governing standards 

 When the standards apply 

 Every monitored intrusion install in Canada. The standards below define the equipment listing, the install practice, and the central station performance. 

 The standards 

 
 CAN/ULC-S302 : Installation, Inspection, Testing, and Maintenance of Electrical Supervised Burglar Alarm Systems 
 CAN/ULC-S303 : Local Burglar Alarm Units and Systems 
 CAN/ULC-S304 : Signal Receiving Centre and Premises Burglar Alarm Control Units (the panel must be listed) 
 CAN/ULC-S319 : Electronic Access Control Systems (where intrusion shares a panel with access control) 
 Insurer requirements: some institutional insurance policies require specific ULC listings or specific central station service levels; verify against the institution's policy at design 
 

 Panel selection 

 When the rule applies 

 Every intrusion install. The panel is the controller for the system: it monitors the zones, manages arming and disarming, and communicates to the central station. 

 The spec 

 
 ULC-S304 listed for the application 
 Zone capacity sized for the as-installed count plus 25 percent spare 
 Communication paths: dual-path standard (IP primary, cellular or POTS secondary) for institutional installs; ULC-S301-listed central station as the receiving party 
 Encryption: AES-128 minimum on the IP path to the central station 
 Keypad and user interface: institutional-grade keypad with backlit display, ADA-compliant where required 
 Battery backup: minimum 24 hours per ULC-S304 
 Tamper monitoring on the panel, every keypad, and every junction box 
 Event log: minimum 1000-event circular log retained in the panel 
 Reporting: every event (arm, disarm, alarm, fault, restoration) reported to the central station with the event code per the Contact ID or SIA-DC09 protocol 
 Programming: panel-side programming through the institution's preferred tool; cloud-managed where the institution supports it 
 

 Study Note 

 Bosch B Series (B9512G, B8512G, B6512, B5512) intrusion panels for institutional work, with the IP communicator option for primary path and cellular for secondary. The Bosch panels are ULC-S304 listed, support up to 599 points (B9512G), integrate with Bosch and third-party readers, and have a mature institutional programming language. DSC PowerSeries Neo and PowerSeries Pro for smaller institutional and commercial installs, with the PowerG wireless option for environments where wireless sensors are appropriate. Pick one panel manufacturer per project and stay inside their accessory and sensor line for compatibility. 

 Sensor types and applications 

 When the rule applies 

 Every zone on the install. The sensor type is selected against the space being protected and the threat being detected. 

 The six common sensor types 

<DefList>
 <dt>Passive infrared (PIR)</dt>
 <dd>Detects motion by sensing changes in infrared heat signature within the protected area. Used indoors for area protection. False alarms triggered by HVAC airflow, sun warming surfaces, small animals, fluorescent light cycling. Mount carefully against environmental factors.</dd>

 <dt>Dual-technology (PIR + microwave)</dt>
 <dd>Combines PIR with microwave (motion-detection radar). Both technologies must agree on a detection event before triggering an alarm. Significantly lower false alarm rate than PIR alone, at slightly higher unit cost. Used indoors in environments where PIR false alarms are documented.</dd>

 <dt>Glassbreak</dt>
 <dd>Detects the acoustic signature of glass breaking. Mounted on the wall opposite or adjacent to the protected glass, ceiling level, within 4500 mm (15 ft) of the protected glass. Used for perimeter window protection.</dd>

 <dt>Magnetic contact (door/window contact)</dt>
 <dd>Reed-switch sensor on the door or window frame, magnet on the moving leaf. Detects the open/closed state. Used on every door and window in a perimeter zone, plus secured-room interior doors.</dd>

 <dt>Photoelectric beam (active infrared)</dt>
 <dd>Transmitter-receiver pair forming an infrared beam across an opening or an outdoor perimeter. Detects beam interruption. Used outdoors for perimeter detection along fence lines and across driveway entrances.</dd>

 <dt>Perimeter LiDAR</dt>
 <dd>Laser-scanning sensor that creates a detection plane along a wall, fence, or property line. Detects intrusion across the plane with sub-metre accuracy and rejects environmental clutter (wildlife, vegetation movement). Used at high-security perimeters where false alarm rate matters and the budget supports the technology.</dd>
</DefList>

 Study Note 

 Bosch ISC-PDL1 series PIR and ISC-BDL2-WP12G dual-technology motion detectors for indoor zones; the Bosch family integrates cleanly with the Bosch B Series panels. Bosch ISC-SK1 series glassbreak detectors with accurate frequency analysis to discriminate glass from other acoustic events. Bosch ISN-C45 magnetic contacts for door and window points. Optex for outdoor and perimeter work: Optex SIP series outdoor PIR, Optex SL series long-range outdoor PIRs, Optex REDSCAN mini for perimeter LiDAR detection. 
 Optex REDSCAN is the institutional default where false-alarm rate at a perimeter matters; the technology rejects environmental clutter that defeats standard PIR and active-IR beams. Used heavily on critical infrastructure, federal facilities, transit yards, and high-security commercial. 

 Zone design 

 When the rule applies 

 Every intrusion install. The zone design defines how the panel reports the alarm: which zone caused it, what type of alarm it is, and what the operator should do about it. 

 The spec 

 
 Zone identification scheme: building, floor, room number, sensor type (e.g., "BLDG-A-FL2-RM215-PIR") 
 Zone type assignment in the panel:: Entry / exit delay : doors used as part of the arming and disarming workflow; allow time to enter and disarm or exit after arming Interior follower : sensors that should only trigger after the entry door has been opened and the entry delay has elapsed; PIR sensors in the entry path Instant : immediate alarm on detection; perimeter doors and windows, glassbreaks 24-hour : always armed, regardless of system state; smoke, panic, hold-up, tamper Day / night : armed only when the system is fully armed (not stay-armed) Bypassable : can be bypassed by the user for legitimate operational reasons Non-bypassable : cannot be bypassed; panic, tamper, smoke 
 One sensor per zone for institutional work (no zone doubling); allows precise alarm location 
 Zone wiring: 2-wire supervised loop with end-of-line resistor pair 
 Zone identifier matched on the panel, the as-built drawing, the central station's response sheet, and the institutional user training material 
 

 Supervised zone wiring 

 When the rule applies 

 Every zone on the install. Supervised wiring lets the panel detect not just alarm/normal state but also tamper conditions (cut wire, short, removed sensor). 

 The spec 

 
 Two end-of-line resistors per zone: one in series with the sensor's alarm contact, one across the contact 
 Resistor values per the panel manufacturer's specification (typically 2.2 kΩ and 4.7 kΩ, or 1 kΩ and 1 kΩ depending on the panel) 
 EOL resistors mounted at the sensor end of the loop, not at the panel end (so a cut anywhere on the loop is detected) 
 Zone states detected:: Normal (sensor closed): one resistor value (e.g., 2.2 kΩ) Alarm (sensor open): both resistors in series (e.g., 6.9 kΩ) Short circuit (line shorted): 0 Ω Open circuit (line cut): infinite Ω 
 Cable: minimum 22 AWG twisted-pair for short runs, 18 AWG for longer runs or higher-noise environments 
 Cable jacket: plenum-rated where the route is through plenum (chapter 07) 
 Conduit and pathway per chapter 02 
 

 Study Note 

 Mount the EOL resistor pair at the sensor end of the loop, inside the sensor housing where possible. Mount them at the panel end and a cut anywhere on the loop reads as a short or open at the panel but the system cannot tell if the cut was at the sensor or somewhere along the way. EOL at the sensor produces unambiguous supervision: the panel knows the cut is somewhere on the path between the panel and the sensor. 

 Central station monitoring 

 When the rule applies 

 Every monitored intrusion install. The central station (sometimes called a monitoring station, signal receiving centre, or SRC) is the third-party service that receives the panel's alarms and dispatches the appropriate response. 

 The spec 

 
 Central station ULC-S301 listed for fire alarm or ULC-S302 listed for burglar alarm 
 Verify the central station's current listing at the start of every project; listings can lapse or change scope 
 Service level: ULC Active (5-second response), ULC Standard (30-second response), or institutional preference 
 Communication path: IP primary (encrypted, supervised at minimum every 200 seconds), cellular secondary (encrypted, supervised at minimum every 200 seconds for dual-path) 
 Account: the institution holds the account; the integrator is the installer of record, not the account holder 
 Response plan: who is called, in what order, for what alarm type; updated at every personnel change at the institution 
 Test schedule: panel reports a periodic supervisory test signal (typically every 24 hours) to the central station; missing test signals generate an alert 
 Annual inspection: per CAN/ULC-S302, including a full functional test of every zone and a verified test signal to the central station 
 

 Study Note 

 The integrator installs equipment that meets ULC-S304 listing. The integrator does not run a central station; the central station is a separate ULC-S301 or ULC-S302 listed service that the institution contracts. Verify the central station's listing at the start of every project; check the ULC public listing register, not the central station's marketing material. Some central stations have lapsed listings or scope changes that affect their authority to receive alarms. 

 False alarm reduction 

 When the rule applies 

 Every monitored install. False alarms degrade the institution's response: the central station ignores them, the police down-prioritise the address, and the system loses its institutional credibility. False-alarm reduction is design discipline, not after-the-fact tuning. 

 The spec 

 
 Dual-technology motion detectors in areas with documented false-alarm sources (HVAC airflow, fluorescent fixtures, sun warming) 
 Pet-immune PIRs in spaces where small animals are present (some institutional environments include service animals or wildlife) 
 Glassbreak sensors with frequency analysis (not just acoustic threshold) to reject non-glass sounds 
 Entry-exit delay sized to the realistic disarming time, not the minimum panel value (typical 30 to 60 seconds entry, 45 to 90 seconds exit) 
 Verified alarm protocol: panel reports the initial alarm and any subsequent zone activations within a defined window; central station responds only after two confirming events for non-critical zones, or immediately for critical zones (panic, hold-up, fire) 
 Cross-zoning: two zones must trip within a defined window before alarm is reported to central station (used selectively, where false-alarm reduction matters more than detection sensitivity) 
 Operator training: covered in chapter 22; users trained on the difference between bypass, arm-stay, arm-away, and how to cancel an accidental alarm 
 Annual review of false-alarm statistics with the institutional security team; tune problem zones at every review 
 

 Study Note 

 Many jurisdictions charge a fee for repeat false alarms (typical $100 to $500 per false alarm after the first two or three in a year). The fee is paid by the institution, not the integrator. A poorly-designed install generates real operating cost that the institution sees on every bill. Build false-alarm reduction into the design and into the commissioning checklist; do not leave it to be tuned after the institution starts paying false-alarm fees. 

 Integration with access control and video 

 When the rule applies 

 Most institutional deployments combine intrusion with access control and video on shared infrastructure. The integration determines what the operator sees when an alarm occurs. 

 The spec 

 
 Access control sharing: intrusion panel disarms on first valid card-read at a designated entry door; arms on last-card-out where the institutional policy supports it 
 Video integration: alarm event triggers VMS pop-up of the associated camera on the operator workstation; recording priority increased for the camera during the alarm window 
 Camera-on-alarm: VMS bookmarks the recording at the alarm event for easy retrieval during investigation 
 Unified audit: alarm, access, and video events correlated in the institutional SIEM or unified platform 
 Shared display: institutional security operations centre has a unified display showing all three systems 
 

 Intrusion is the supervised loop that tells the institution something is wrong. ULC-S304 listed panel (Bosch B Series institutional default, DSC PowerSeries for smaller installs), one sensor per zone with EOL resistor supervision at the sensor end. Dual-technology motion in spaces with false-alarm sources. Optex outdoor and perimeter sensors where the false-alarm rate at the perimeter matters; Optex REDSCAN where the budget supports laser-perimeter detection. Dual-path encrypted IP and cellular communication to a ULC-S301 or S302 listed central station. Build false-alarm reduction into the design, not into post-install tuning. Get the design right and the system catches the events that matter; get it wrong and the institution pays false-alarm fees while the system credibility erodes.

================================================================

## Detention and high-security

URL: https://hans.study/standards-guidance/cssir-16-detention-high-security/
Type: kb
Date: 2026-05-10
Description: Detention and high-security installs for Canadian institutional work. Anti-ligature hardware, pick-proof sealants, RGS-only pathway, sallyport interlocks, holding cell coverage, evidence room access, courtrooms, secure document handling, federal compliance, Hirsch ScramblePad for high-security PIN entry.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Detention and high-security work is where the rules tighten and the stakes multiply. The pathway changes (RGS only, no LBs, tamper-resistant fasteners). The hardware changes (anti-ligature, pick-proof, double-strapped, no grab points). The commissioning changes (every interlock tested, every release tested, every credential workflow tested). Walk into a detention project with the institutional-office playbook and the result is unsafe, non-compliant, and a defect the AHJ will catch. Walk in with the discipline this chapter describes and the install holds up to detention-grade scrutiny. 

 What makes detention different 

 The character of the work 

 Detention environments include holding cells in police facilities, courtrooms with custody cells, provincial and federal correctional facilities, secure psychiatric and forensic units, and immigration detention. The threat model is different from institutional offices: the principal threat is from the protected population itself, the consequences of failure include serious injury or death, and the equipment has to survive deliberate attempt to defeat it. 

 The three governing principles 

<DefList>
 <dt>Anti-ligature</dt>
 <dd>Every protrusion below 3.7 m (12 ft) AFF is a potential ligature point. Hardware below this height is anti-ligature: smooth, angled, sloped, or otherwise unable to support body weight at any attachment point. Anti-ligature hardware is purpose-built; commercial-grade fixtures do not meet the requirement regardless of how durable they appear.</dd>

 <dt>Pick-proof</dt>
 <dd>Every visible fastener, every sealant, every penetration is attempted-defeat resistant. Standard fire caulk is not pick-proof. Standard Phillips or slot fasteners are not pick-proof. Pick-proof fasteners are tamper-resistant (Torx with security pin, Tri-wing, one-way, or proprietary heads) and pick-proof sealants are detention-grade products specifically tested against picking and gouging.</dd>

 <dt>Double-strapped</dt>
 <dd>Every conduit, every cable support, every fastener doubled. The single point of failure on a commercial install is acceptable risk; on a detention install it is unacceptable. Two clamps per support point, two fasteners per cover, redundant attachment for every device feeding the protected envelope.</dd>
</DefList>

 Pathway inside the detention envelope 

 When the rule applies 

 Every conduit run inside the detention envelope: holding cells, cell corridors, sallyports, prisoner intake, custody-side of any custody door. The pathway-side rules also live in chapter 02; consolidated here for the detention reference. 

 The spec 

 
 RGS only. EMT, IMC, FMC, LFMC, and PVC are not used inside the detention envelope. 
 Conduit feeds device boxes from above through the slab where the structure permits, with the device box mounted at 3.7 m (12 ft) AFF or higher to keep it out of reach 
 Tamper-resistant fastener heads on every conduit support, every box cover, every device cover (Torx with security pin, Tri-wing, or one-way as the project specification calls for) 
 Conduit body covers (LB, T, C, X) prohibited inside the protected space; junction and pull boxes only with screw-cover and screws inaccessible from the protected side 
 Caulk and sealant at every conduit penetration: pick-resistant detention-grade sealant. Standard fire-rated caulk is not pick-resistant. 
 Cable serviced from the secure side of the wall: every device on the prisoner-facing wall is fed by conduit running through the secure-side mechanical chase, with the box opening and the service access on the secure side only 
 No ceiling-cable or J-hook runs inside the protected space; all cable in conduit, all conduit terminations on the secure side 
 Double-strap every conduit run inside the envelope: two clamps per support point, with two-hole HDG malleable iron straps replacing single-hole where the project specification calls for it 
 

 Study Note 

 RGS with threaded couplings throughout. Iberville Krydon cast junction boxes on the secure side with stainless cover screws and tamper-resistant Torx heads. Pick-proof detention-grade sealant per the project specification (the standard fire caulk is not pick-proof; the manufacturer publishes which products meet the detention-grade rating). Service every device from the secure side; the prisoner-facing wall is smooth, anti-ligature, and unbroken. 

 Anti-ligature hardware 

 When the rule applies 

 Every device installed below 3.7 m (12 ft) AFF inside a holding cell, mental health room, or any space where the institutional clinical assessment requires anti-ligature design. The project specification typically calls out the specific anti-ligature requirement; the integrator's job is to verify every specified device meets the requirement. 

 The spec 

 
 Anti-ligature hardware purpose-built for the application; commercial equivalents not used regardless of durability rating 
 No grab points: angled tops on fixtures, sloped enclosures, smooth surfaces 
 No attachment points: hardware mounted flush, no protrusions, no cord loops, no exposed conduit 
 Anti-ligature certification: the institutional specification typically references a specific test standard (e.g., the institution's own anti-ligature acceptance criteria); verify against the listing 
 Camera housings: anti-ligature dome models specifically rated for detention installation; standard institutional cameras not used in cells 
 Reader and intercom mounting: flush-mount, anti-ligature, vandal-resistant; sloped face on any reader installed below 3.7 m AFF 
 Conduit and cable: not exposed below 3.7 m; service from above through the slab, or from the secure side of the wall through a mechanical chase 
 Light fixtures, plumbing fixtures, ventilation fixtures: all anti-ligature per the architectural specification 
 

 Study Note 

 The institutional spec for anti-ligature hardware varies by project (police, court, correctional, healthcare forensic, immigration). Read the spec at design and verify every device against it; do not discover at commissioning that a device the architect approved as the project camera fails the anti-ligature requirement. Where a project does not have an anti-ligature spec but the use case is detention or holding, raise the gap during design rather than installing standard institutional hardware that creates a known life-safety risk. 

 Sallyport interlock and door sequencing 

 When the rule applies 

 Every sallyport on the project. A sallyport is a two-door pass-through where only one door can be open at a time; used at vehicle yards, prisoner intake, secure visitor entry, evidence-room entry. 

 The spec 

 
 Two doors in series, with the interlock logic preventing both doors from being open simultaneously 
 Interlock implementation:: Hardware interlock (relay logic): the access control panel uses internal relay logic to enforce the interlock; preferred for redundancy and for offline operation Software interlock (panel firmware): the panel's firmware enforces the interlock through logic blocks; backed up by hardware where the institutional design supports it 
 Door open during interlock cycle: if Door A is open, Door B remains locked and cannot be commanded open; controller logs the attempt to violate the interlock 
 Sallyport override: secure override credentials (typically supervisor-level) can disable the interlock under controlled circumstances; override is logged and time-limited 
 Fire alarm release: per the institutional life-safety design; some institutions release both doors on fire alarm, others release only the egress door 
 Power outage behaviour: per the institutional design; some institutions fail-secure (both doors locked), others fail to a specified state 
 Camera coverage: every sallyport has video coverage of both door faces, both door interiors, and the central area; recording priority is high during sallyport cycles 
 Intercom: bi-directional intercom in the sallyport, communicating to the control room 
 

 Commissioning the interlock 

 At commissioning, test the interlock in every state: Door A open / command Door B, Door B open / command Door A, both doors closed / command both, supervisor override / disable interlock / enable interlock. Document every test in the commissioning record. The interlock is a life-safety device; a failure that the commissioning test would have caught becomes a serious incident in service. Build the interlock test into chapter 22's checklist and run it as a witnessed test with the institutional security team. 

 Holding cell coverage 

 When the rule applies 

 Every cell and every secure detention space. The institutional design specifies the camera count and the coverage requirement; this section describes what good practice looks like across the typical Canadian institutional detention environment. 

 The spec 

 
 Minimum one camera per holding cell, positioned to view the full interior including the bunk area, the toilet area (with privacy screening as required by the institutional policy), and the door 
 Camera mounted at 3.7 m (12 ft) AFF or higher, in an anti-ligature housing, fed from the secure side 
 Resolution: 40 PPF (recognition) minimum on every viewable surface of the cell 
 Low-light performance: the cell may be in low-light mode at night while still under monitoring; specify camera with IR or starlight-grade sensitivity 
 Audio recording: per the institutional policy and the privacy framework; most jurisdictions disable audio recording in cells by default, with limited authorised exceptions 
 Cell corridor coverage: cameras at the corridor ends and at any blind spots, with PPF appropriate to the institutional purpose (recognition or identification) 
 Tamper-resistant housing and tamper-monitored cable: any attempt to disable the camera reports immediately to the control room 
 

 Study Note 

 The institutional privacy office and the legal counsel govern what cameras can view and what audio can be captured in detention spaces. Cell privacy screening, toilet-area masking, and audio policies vary by jurisdiction and by detention type. Coordinate at design with the institutional privacy office; install cameras and cables but leave them disabled until the privacy framework is signed off. 

 Courtroom and evidence room work 

 When the rule applies 

 Court facilities and evidence rooms have specific access, audit, and video requirements that go beyond general institutional design. Federal facilities and court installations often require FICAM or HSPD-12 compliance, supervised PIV/CAC card reading, and PIN entry through a randomized keypad. 

 The spec 

 
 Court holding cells: detention-envelope rules apply (above) 
 Judges' chambers and secure office spaces: institutional-grade access with tamper monitoring on the door and the panel 
 Evidence room: dual-authentication required at the door (card plus PIN, or card plus second card); access log retained per institutional evidence-handling policy 
 Evidence room video: continuous recording with extended retention (typical 5 to 7 years for criminal evidence rooms); separate VLAN and separate VMS instance from the building general video; storage protected against tamper and against accidental deletion 
 Evidence-room operator workstation: dedicated workstation in a secure room, single-purpose, no general browsing or productivity software 
 Federal court facilities: FICAM- or HSPD-12-compliant access where the institutional spec calls for it; supervised PIV/CAC readers; randomized PIN keypad for two-factor 
 Audit log: every access event, every search of the evidence database, every video review, every credential change recorded and retained per the institutional retention policy 
 

 Study Note 

 The Hirsch ScramblePad is the field default for high-security PIN entry: randomized PIN layout, FICAM-listed, shoulder-surfing-resistant. Used in evidence rooms, secure server rooms, federal court facilities, and any application where shoulder-surfing is a documented threat. The ScramblePad integrates with most access control platforms through OSDP or Wiegand and pairs with a 13.56 MHz smart card reader for two-factor authentication. 

 Wiring topology in detention 

 When the rule applies 

 Every cable run inside the detention envelope. Wiring is in conduit on the secure side; nothing visible on the prisoner-facing wall; serviceable from the secure side only. 

 The spec 

 
 Every cable in RGS conduit, with the conduit on the secure-side wall or routed through the slab from above 
 Device boxes flush-mounted on the prisoner-facing wall, with the back of the box opening into the mechanical chase or the slab cavity 
 Service access (box cover, cable splicing, terminal access) only from the secure side 
 WAGO 221 lever-action connectors at the device-box service splice on the secure side 
 Cable identification: per chapter 06, with the labels on the secure-side accessible position; do not place labels inside the prisoner-facing space 
 Cable type: standard Cat 6A and security signal cable inside the conduit (the conduit and the secure-side service is the security; the cable itself does not have to be detention-rated) 
 End-of-line resistors at the sensor end of every supervised loop (chapter 15); EOL inside the device or junction box accessible from the secure side only 
 

 Commissioning detention installations 

 When the rule applies 

 Every detention project. The commissioning checklist includes everything from chapter 22 plus the detention-specific verifications below. 

 The spec 

 
 Sallyport interlock tested in every state with the institutional security team witnessing 
 Every door release tested: fire alarm release, panic release, emergency release, supervisor override 
 Every camera tested: live view, recording, low-light mode, tamper alarm, IR or starlight performance 
 Every reader tested: valid credential, invalid credential, after-hours schedule, two-factor flow where required, ScramblePad randomization (if installed) 
 Every intrusion zone tested: alarm, restoration, tamper, fault, EOL supervision 
 Every anti-ligature device walked clinically with the institutional clinical or operational team to verify no grab points 
 Pick-proof sealant inspected at every penetration with the institutional security team 
 Tamper-resistant fasteners verified at every cover, junction box, and conduit support 
 Audit log: 24-hour audit log review at commissioning confirming every event was captured and recorded 
 Annual inspection plan handed over to the institution: who inspects, how often, against what checklist 
 

 Detention is where the rules tighten and the stakes multiply. RGS conduit only, no LBs, tamper-resistant fasteners, pick-proof detention-grade sealant at every penetration. Anti-ligature everywhere below 3.7 m AFF, with the institutional anti-ligature spec as the governing reference. Sallyport interlocks tested in every state at commissioning. Cell coverage with anti-ligature cameras at 40 PPF minimum, fed from the secure side, with audio policy per the institutional privacy framework. Evidence and court facilities with dual-authentication, FICAM compliance where required, and Hirsch ScramblePad for high-security PIN entry. Service every device from the secure side; the prisoner-facing wall is smooth, anti-ligature, and unbroken. Walk into a detention project with this discipline and the install holds up to detention-grade scrutiny.

================================================================

## Healthcare environments

URL: https://hans.study/standards-guidance/cssir-17-healthcare-environments/
Type: kb
Date: 2026-05-10
Description: Healthcare security installs for Canadian institutional work. CSA Z32 patient-care areas, hospital-grade power, infant abduction systems, elopement prevention in long-term care, behavioral health anti-ligature, pharmacy and controlled substances, privacy frameworks (PHIPA, HIPAA), audio recording defaults.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Healthcare security has a different design principle than commercial or institutional office work. The patient is the primary stakeholder on every decision: privacy, dignity, clinical workflow, life-safety. The security system supports the patient's safety without compromising the patient's care. Cameras are placed for safety, not surveillance. Doors are secured for patient protection, not access control. Locks release on fire alarm but also on medical emergency. Walk into a healthcare project with the institutional-office playbook and the design fails the clinical walkthrough; walk in with the discipline this chapter describes and the install supports the clinical mission. 

 The governing standards 

 When the standards apply 

 Every healthcare project in Canada. The standards below define the electrical environment, the privacy framework, and the clinical-area requirements that shape security work. 

 The standards 

 
 CSA Z32 : Electrical Safety and Essential Electrical Systems in Health Care Facilities. Governs the electrical environment in patient care areas: receptacle types, grounding redundancy, critical branch power, leakage current limits. 
 CSA Z317.13 : Infection Control During Construction, Renovation, and Maintenance of Health Care Facilities. Governs how the install proceeds in occupied healthcare spaces. 
 CSA Z8000 : Canadian Health Care Facilities. Architectural and engineering standard for healthcare buildings; references the security-related portions of the institutional design. 
 PHIPA / PIPEDA / provincial health privacy law : Personal Health Information Protection Act (Ontario) and provincial equivalents govern collection and retention of patient information including video. 
 Accreditation Canada : institutional accreditation body whose standards include security-related items for patient safety, infant security, controlled substance access. 
 Health Canada : federal regulator for controlled substances, with specific access and retention rules for pharmacy and dispensary areas. 
 

 Patient care areas under CSA Z32 

 When the rule applies 

 Any security device installed in a CSA Z32-defined patient care area. The institutional electrical design classifies each area (Basic Care, Intermediate Care, Critical Care) and the security install's equipment has to satisfy the electrical requirements for the area. 

 The three patient care area classifications 

<DefList>
 <dt>Basic Care</dt>
 <dd>Areas where patients receive non-invasive treatment. General medical-surgical inpatient rooms, examination rooms, treatment rooms without invasive procedures. Standard hospital-grade electrical environment.</dd>

 <dt>Intermediate Care</dt>
 <dd>Areas where patients may receive minor invasive procedures or have body-contact electrical equipment. Step-down units, post-anesthesia care, some imaging areas. Enhanced electrical environment with redundant grounding.</dd>

 <dt>Critical Care</dt>
 <dd>Areas where patients receive life-support, invasive monitoring, or major invasive procedures. ICUs, operating rooms, cardiac catheterization labs. Highest electrical requirements with critical-branch power and equipotential bonding.</dd>
</DefList>

 The spec 

 
 Hospital-grade receptacle on every dedicated security circuit in a patient care area (green dot marking on the receptacle face) 
 Isolated-ground receptacle where the equipment manufacturer requires it (orange triangle marking) 
 Redundant equipment grounding: every chassis bonded to both the safety ground in the branch circuit and a separate grounding conductor to the building telecommunications grounding bus (chapter 04) 
 Leakage current: equipment meets the leakage limit for the area classification (typically <300 μA for Basic Care, <100 μA for Critical Care) 
 Critical-branch circuit: head-end servers, life-safety-related access control, and intrusion panels on the institutional critical-branch power per the electrical design 
 Patient-vicinity equipment: special precautions for any device installed within 1.8 m of the patient bed; consult the institutional electrical design 
 Equipotential bonding: in Critical Care areas, every metal surface within the patient vicinity bonded to a common reference (chapter 04) 
 

 Study Note 

 The electrical contractor on a healthcare project is responsible for the patient-care-area electrical infrastructure. The security install's job is to confirm that every security device installed in a patient care area satisfies the institutional electrical design. Read the electrical drawings at design and verify each device against the area classification. The CSA Z32 details are the electrical contractor's domain; your domain is verifying alignment. 

 Infant abduction prevention 

 When the rule applies 

 Every maternity, postpartum, and neonatal area in a hospital. Infant abduction systems use RFID tags on the infant, monitored exits, and integration with the access control, video, elevator, and stairwell systems to create a single coordinated response. 

 The spec 

 
 RFID transmitter (typically ankle-worn) on every infant in the protected area, with tamper detection (cut band, removed transmitter) 
 Reader antennas at every exit from the protected area, including stairwell doors, elevator lobby, service corridors 
 Detection logic: a tagged infant approaching an exit without authorisation triggers a system-wide alert 
 Door integration: tagged infant at the door causes the door to lock if not already locked; existing access permissions overridden for the duration of the alarm 
 Elevator integration: tagged infant in the elevator lobby holds the elevator at the floor; tagged infant inside the elevator returns the car to the protected floor and locks it open 
 Stairwell integration: tagged infant in the stairwell triggers stairwell access lockdown 
 Camera integration: alarm event triggers VMS pop-up of the affected area on the nursing station and security monitoring workstations 
 Mass notification: voice notification on the unit with the documented response phrase (typically "Code Pink" or per institutional naming) 
 Annual functional test: every transmitter, every reader, every door, every elevator, every stairwell tested per the manufacturer's procedure 
 

 Study Note 

 The institutional accreditation body expects the infant abduction system to operate as a single coordinated response across door, elevator, stairwell, and video systems. A common defect is parallel systems: the infant abduction transmitter triggers its own alarm but does not actually lock the elevators or hold the stairwells. The institutional commissioning has to test every integration path; bookmark the test in chapter 22's checklist. 

 Elopement prevention in long-term care 

 When the rule applies 

 Long-term care facilities, memory care units, dementia wards, and any healthcare facility housing residents at risk of wandering. The elopement prevention system uses RFID tags similar to infant abduction, with door delay and coordinated alerting. 

 The spec 

 
 RFID tag (wrist-worn or ankle-worn) on each at-risk resident, with tamper detection 
 Reader antennas at every exit from the unit and at the facility perimeter exits 
 Door delay: tagged resident at a delayed-egress door triggers a 15- or 30-second delay (per AHJ approval) before the door releases, with audible and visual alarm during the delay 
 Fire alarm coordination: delayed-egress doors release immediately on fire alarm regardless of delay state 
 Staff override: staff credential at the door bypasses the delay (resident accompanied by staff exits without delay) 
 Camera integration: alarm at a delayed-egress door triggers VMS pop-up at the nursing station 
 Tracking and location: where the institution specifies real-time location, the system reports each tagged resident's current zone to the institutional dashboard 
 Annual functional test: per the manufacturer's procedure and the institutional safety committee's requirement 
 

 Study Note 

 Delayed-egress doors are a code-permitted configuration but they require AHJ approval. The building code section permitting delayed egress varies by jurisdiction; verify with the AHJ at design that the proposed delay time and the proposed signage meet local requirements. Some jurisdictions also require posted occupancy load limits before approving delayed egress on a building. 

 Behavioral health and forensic mental health 

 When the rule applies 

 Inpatient psychiatric units, addiction treatment, forensic mental health, and any healthcare environment where patient self-harm is a documented clinical concern. The security design treats the unit as anti-ligature throughout, similar to detention work (chapter 16) but with the clinical mission driving the choices. 

 The spec 

 
 Anti-ligature hardware on every device below 3.7 m (12 ft) AFF, per chapter 16 
 Anti-ligature cameras in patient rooms and common areas, with the institutional privacy office signing off on camera placement 
 Tamper-resistant fasteners on every cover, junction box, and conduit support inside the unit 
 Pick-proof sealant at every penetration on the patient-facing wall 
 Door hardware: anti-ligature handle sets, anti-ligature hinges, anti-ligature closers; specified by the institutional clinical and operational team 
 Camera audio: disabled by default; audio recording subject to the institutional privacy framework and consent processes 
 Camera viewing: patient rooms typically not monitored continuously; observation cameras in common areas at recognition-level PPF 
 Seclusion and restraint rooms: continuous monitoring with two-camera redundancy, recording priority, and event-bookmark integration with the clinical record 
 Clinical walkthrough before install and after install with the institutional clinical team and the institutional safety committee 
 

 Study Note 

 The institutional clinical team is the authoritative voice on what behavioral health installations look like. The architectural drawings show the rooms; the clinical team's walkthrough confirms that every device meets the institutional anti-ligature standard. Build the clinical walkthrough into the project schedule before install and again after install. Findings from the walkthrough become rework items; bake the rework allowance into the schedule and the cost. 

 Pharmacy and controlled substances 

 When the rule applies 

 Hospital pharmacies, automated dispensing cabinets, controlled-substance storage rooms, and chemotherapy compounding areas. Health Canada regulations and institutional pharmacy policy define the access and audit requirements that the security install supports. 

 The spec 

 
 Dual-authentication at controlled-substance storage doors: card plus PIN, or card plus second card (per institutional pharmacy policy) 
 Time-stamped access log retained for the period required by Health Canada (typically 2 years minimum, longer for some controlled substances) 
 Video coverage with extended retention at the controlled-substance storage area (typical 90 days or longer) 
 Automated dispensing cabinet (ADC) integration: alarm output from the cabinet's tamper, the cabinet's controlled-substance discrepancy event, and the cabinet's unauthorized access attempt reported to the institutional pharmacy management system 
 Chemotherapy compounding areas: clean-room environmental security with controlled-access entry, change rooms with audit logging, and HEPA-filtered ventilation monitoring 
 Pharmacy general access: limited to authorised pharmacy staff with the institutional credential standard, after-hours access requiring supervisor approval 
 Annual access audit: review of every cardholder with pharmacy access, removal of any cardholder no longer in the role 
 

 Privacy framework for video and audio 

 When the rule applies 

 Every healthcare video installation in Canada. PHIPA (Ontario), provincial equivalents, and PIPEDA federally govern collection and retention of personal health information; video and audio capture in healthcare environments fall under the framework. 

 The spec 

 
 Privacy Impact Assessment (PIA) conducted before any new camera installation in a healthcare environment 
 Audio recording disabled by default on every camera; audio capture requires explicit institutional privacy office approval and specific signage 
 Patient room cameras only with written institutional authorisation and clinical justification 
 Public-area cameras (corridors, lobbies, parking) with visible signage identifying the institution as the operator 
 Treatment area cameras (procedure rooms, treatment bays): per institutional privacy policy, typically disabled or restricted to specific clinical circumstances 
 Retention: per institutional policy (typically 30 days for general healthcare, 90 days for behavioral health, 1 year for pharmacy and controlled-substance areas) 
 Access to recordings: restricted to authorised users with documented patient-safety or operational purpose; access logged in the VMS audit trail 
 Disclosure: per institutional disclosure process, typically requiring privacy office review and legal authority (warrant, court order, or specific patient consent) 
 

 Study Note 

 Privacy office review can take weeks or months. Cable and mount the cameras during the install but leave them disabled until the privacy office signs off. The cameras can be energised independently once authorisation is in hand; do not energise them on the assumption that authorisation will come. 

 Code Blue and clinical emergency integration 

 When the rule applies 

 Healthcare facilities with clinical emergency response plans (Code Blue for cardiac arrest, Code Pink for infant abduction, Code Silver for active shooter, others per institutional naming). 

 The spec 

 
 Code-button locations per institutional clinical design: nurse stations, treatment rooms, behavioral health observation areas 
 Code button activation triggers: voice notification to the responding team, VMS pop-up of the affected area on the security operations workstation, door release per the institutional code response (Code Pink locks down the unit; Code Silver may unlock for evacuation), notification to the institutional incident management system 
 Mass notification integration: institutional mass notification platform (where present) receives the code event and notifies the broader response team 
 Annual code-response drill: every code tested in a coordinated drill with the institutional clinical and operational teams 
 Code button hardware: clearly labelled, tamper-resistant against accidental activation, located per institutional clinical workflow 
 

 Infection control during install 

 When the rule applies 

 Every install or maintenance event in an occupied healthcare environment. CSA Z317.13 governs how the work proceeds without compromising infection control. 

 The spec 

 
 Infection Control Risk Assessment (ICRA) completed before any work begins in an occupied healthcare space 
 Work isolation: portable barriers, HEPA-filtered negative-pressure enclosures, or full anteroom construction as the ICRA classification requires 
 Personal Protective Equipment (PPE) per the institutional infection-control standard: respirator, gowns, gloves, foot covers 
 Cleaning after work: HEPA-vacuum the work area, wet-wipe all surfaces, and verify with the institutional infection-control coordinator before removing barriers 
 Tool sanitation: tools brought into the work area cleaned before and after entry per the institutional standard 
 Cable and equipment storage: clean storage area outside the patient care zone, with materials staged in batches matching the work plan 
 

 Study Note 

 The ICRA classification (Class I through Class IV) determines how invasive the work can be relative to occupied patient areas. Class I (low-risk, minor maintenance) requires minimal precautions; Class IV (major construction, infection-sensitive patients nearby) requires anteroom construction, HEPA filtration, and dedicated cleaning protocols. Confirm the ICRA classification with the institutional infection-control team at every project kickoff and at every change in work scope. 

 The patient is the primary stakeholder on every decision. CSA Z32 in patient-care areas means hospital-grade receptacles, redundant grounding, critical-branch power where the design specifies. Privacy review by the institutional privacy office before commissioning, not after. Audio off by default. Infant abduction integrates with door, elevator, and stairwell control as one coordinated system. Elopement prevention uses delayed egress with AHJ approval. Behavioral health is anti-ligature throughout, with clinical walkthrough before install and after install. Pharmacy and controlled substances get extended video retention and audit-ready access logs. CSA Z317.13 infection control governs how the work proceeds in occupied spaces. Walk into a healthcare project with this discipline and the install supports the clinical mission instead of fighting it.

================================================================

## Education and transit

URL: https://hans.study/standards-guidance/cssir-18-education-transit/
Type: kb
Date: 2026-05-10
Description: Education and transit security installs for Canadian institutional work. K-12 lockdown integration, post-secondary residences, transit stations and platforms, vandal-resistant hardware, outdoor cabling in Canadian climates, mass notification, help-point integration.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Education and transit are the two institutional sectors with the highest occupant turnover and the highest exposure to the elements. School populations rotate annually; transit ridership is the broader public; both environments demand heavier-duty infrastructure than office-grade work to survive what the user load and the Canadian climate impose on them. The discipline is matching the equipment to the environment, integrating with the institution's emergency response plan, and accepting that this work fails differently and faster than office work if the design is short-changed. 

 K-12 lockdown integration 

 When the rule applies 

 Every K-12 school project in Canada. The school board's emergency response plan defines the lockdown procedure; the security install implements the technical side of the procedure. 

 The spec 

 
 Lockdown trigger: secure-button activation at the main office, with secondary triggers at administrative offices per the school board's plan 
 Lockdown response (coordinated single action across all systems):: All perimeter doors lock; all interior classroom doors not already locked may lock per board policy PA system announces the lockdown phrase per the board's protocol Mass notification platform pushes the lockdown message to staff phones, classrooms, and the board's emergency operations centre Police automatic notification through the central station or direct connection per board policy Video recording priority increased; cameras at main entries and exterior perimeter prioritised 
 Egress: classroom locks always permit egress from inside the classroom (building code requirement) 
 All-clear: secure-button or workstation deactivates lockdown after authorised response; system returns to normal state 
 Drill mode: lockdown can be tested in a drill mode that does not trigger police notification 
 Annual drill: every school tests its lockdown system in a coordinated drill with the board and (where appropriate) local police 
 

 Study Note 

 The lockdown response policy belongs to the school board and the school's emergency response team, not the security integrator. Your job is to implement the policy through the technical integration of door, PA, mass notification, and police notification. Confirm the policy at design and verify the implementation at commissioning. Where the policy is vague or under development, escalate to the board for clarity before installing the technical integration; do not invent the response. 

 Classroom door hardware 

 When the rule applies 

 Every classroom door in K-12 work. The classroom lock has to satisfy the school board's safety policy, the building code's egress requirements, and the AHJ's interpretation of both. 

 The spec 

 
 Mechanical classroom function lock with teacher-side keying: teacher can lock the door from the inside without opening the door 
 Egress: door always permits egress from inside the classroom; locking the door does not lock occupants in 
 Lockset rated for high-traffic institutional use (BHMA Grade 1 or equivalent) 
 Hinges with non-removable pin (NRP) on outward-swinging doors 
 Door closer rated for institutional traffic, with delayed-action close where the institutional preference supports it 
 Door position switch (DPS) at every classroom door for the access control system to verify door state during lockdown 
 Master keying coordinated with the school board's key control programme 
 Electronic access at administrative doors and at specific classrooms per the board's policy (rare on standard classrooms; common on labs, gym, and specialty rooms) 
 

 Study Note 

 Allegion / Schlage L-series mortise lock in the classroom function (L9056). Allegion / LCN 4040XP series door closers for institutional traffic. Hinges with NRP from any major institutional supplier matching the door's existing hardware. The school board typically standardizes on one lock manufacturer across the district; align with that standard at design. 

 Post-secondary residences 

 When the rule applies 

 University and college residence buildings, including traditional dormitories, suite-style residences, and apartment-style residences. The institution manages large numbers of students who rotate through credentials annually. 

 The spec 

 
 Main building entry: monitored by access control, with the institutional credential as the access method 
 Floor or wing access: monitored by access control for residences with floor segregation (gender, year, or program) 
 Room access: per the institution's policy: Traditional dormitory: mechanical key per resident, master keying for staff Suite or apartment style: electronic lock at the suite door, with the institution's credential Newer institutional installs: full electronic access at every room door, with the resident's credential 
 Credential lifecycle: bulk provisioning at semester start, bulk deactivation at semester end, replacement-card workflow for lost cards (typical fee structure for cost recovery) 
 Visitor management: visitor sign-in at the main entry, temporary credential for the duration of the visit per institutional policy 
 After-hours access: institutional staff credential bypasses normal restrictions; logged in the audit trail 
 Emergency overrides: residence director credential opens any door in the residence; logged with reason code 
 Camera coverage: main entries, public common areas, exterior perimeter, exit-only doors; not in residential corridors or near unit doors unless the institutional privacy framework specifically authorises it 
 

 Study Note 

 Residence access work is dictated by the academic calendar. Major changes happen during reading week, between semesters, and during the summer break. The institutional residence operations team has very narrow windows for commissioning and for major upgrades. Build the project schedule around the calendar at design; do not propose work during exam periods or move-in weeks. 

 Transit station and platform infrastructure 

 When the rule applies 

 Subway stations, light rail stations, bus terminals, and intermodal transit hubs. Transit work has its own infrastructure standards (different from general institutional commercial), driven by the harsh environment, the public exposure, and the agency's operational requirements. 

 The spec 

 
 Vandal-resistant housings (IK10 minimum) on every device in public access areas: cameras, intercoms, help points, reader housings 
 Conduit-fed cabling throughout public access areas; no exposed cable runs, no J-hook routing in public spaces 
 Industrial-rated equipment for the temperature range and the contaminant exposure: -40°C to +70°C operating range typical, EN 50121-4 rated for railway environments where applicable 
 Help points at platform edges, intermodal transition points, and other locations per the agency's standard; two-way audio to the operations centre, with video link from the nearest camera 
 Camera coverage at boarding zones (recognition PPF), gate or fare-line areas (identification PPF where fare evasion is a documented concern), platform-edge approach (observation PPF), and station perimeter exits (recognition PPF) 
 Operations centre integration: every camera, every help point, every door alarm, every intrusion zone reports to the agency operations centre (or a delegated regional operations centre) 
 Power: critical-branch power for the security system where the agency design supports it; UPS at every station per chapter 03 
 Backbone: redundant fibre paths to the operations centre, with diverse routing where the station geography allows 
 

 Study Note 

 Transit agencies (TTC, GO Transit, OC Transpo, Translink, STM, others) maintain their own security infrastructure standards. The institutional spec on a transit project is the agency's standard, not a generic institutional spec. Confirm the standard at design and align every product, every cable, every cabinet, and every commissioning step with the agency's documented practice. Where the agency's standard differs from the integrator's preferred field default, the agency's standard wins. 

 Outdoor cabling in Canadian climates 

 When the rule applies 

 Every outdoor pathway on transit, education, and any institutional install with exterior camera or device coverage. Canadian climate hits outdoor infrastructure differently from southern climates: ice loading, freeze-thaw cycles, salt exposure, and large daily temperature swings. 

 The spec 

 
 Conduit type per chapter 02: RGS for exposed exterior, IPEX Schedule 40 PVC for underground, transition fittings per the design 
 Ice loading per NBC Appendix C climatic data for the project location; aerial cables, support brackets, and pole-mounted equipment sized against the ice load 
 Expansion fittings on long metallic conduit runs in unconditioned exterior spaces: thermal expansion calculation per chapter 02 
 Drain holes at the low points of every outdoor conduit run; sealed fittings at every interior-to-exterior penetration 
 Outdoor cable: OSP-rated, UV-stable jacket, with the 15 m indoor entry rule honoured per chapter 07 
 Surge protection on every conductor entering the building from outdoor per chapter 03 
 Outdoor enclosures: NEMA 4 or NEMA 4X for damp / washdown exposure, with breather drains and gasketted covers 
 Heaters in outdoor enclosures where the design requires battery backup or sensitive electronics: thermostat-controlled, sized to maintain the equipment's operating range 
 Salt-spray exposure (near roadways, transit yards): stainless or epoxy-coated hardware where corrosion is documented 
 

 Study Note 

 NBC Appendix C gives ice-load values by region across Canada. Toronto's values differ from those in Atlantic Canada and from those in the Prairies. Pull the values for the project location at design and size aerial cables, brackets, and pole mounts against the regional value. Skipping this leads to aerial cable failures during the first severe ice storm; the cost of remediation is significantly more than the cost of the proper bracket and cable at install. 

 Mass notification integration 

 When the rule applies 

 Education and transit installations where the agency's emergency response plan calls for mass notification. The mass notification platform delivers urgent messages across multiple channels (PA, digital signage, phone, email, mobile push) coordinated with the security event. 

 The spec 

 
 Mass notification platform per the institutional standard (Singlewire InformaCast, Rave Mobile Safety, AlertMedia, or institutional equivalent) 
 Security event triggers notification: lockdown, fire alarm, severe weather, evacuation, missing person, all-clear 
 Multi-channel delivery: PA voice, IP phones, digital signage, building intercom, mobile app push, SMS, email 
 Audience segmentation: campus-wide, building-specific, role-specific (staff, students, residents, visitors), institutional response team 
 Pre-recorded messages: standard messages for each event type, with the institutional voice and the institutional language standards 
 Live messaging: authorised users can deliver live audio or text from the security operations workstation 
 Integration testing: every event type tested at commissioning in a coordinated drill with the institutional emergency response team 
 

 Study Note 

 Mass notification is owned by the institutional emergency office, not the security integrator. Your job is to integrate the security event trigger with the institutional notification platform. Confirm at design which platform, which integration mechanism (typically HTTP API or syslog-trigger), which audiences receive which notifications, and which events trigger automatic versus authorised-manual notification. Build the integration into commissioning testing. 

 Help points and intercoms 

 When the rule applies 

 Public-access transit stations, parking structures, university campuses, and educational facilities with after-hours pedestrian routes. Help points provide a public emergency communication path back to the institutional operations centre. 

 The spec 

 
 Help point housing: stainless steel pedestal or wall-mount, vandal-resistant (IK10 minimum), high-visibility colour (yellow or blue per the agency standard) 
 Activation: single-button activation, ADA-compliant force and reach 
 Communication: two-way audio between the help point and the operations centre, full-duplex hands-free 
 Video: the nearest camera bookmark-records on help-point activation; operations centre operator sees the live video alongside the audio call 
 Visible identifier: each help point has a unique identifier visible on the housing; identifier matches the operations centre dispatch system 
 Lighting: LED illumination of the help point and the surrounding area, activated continuously or on motion per the design 
 Heating in cold-climate help points: thermostat-controlled heater inside the housing to maintain electronic operating range 
 Annual functional test: every help point tested for audio quality, video bookmark, illumination, and dispatch accuracy 
 

 Education and transit demand heavier-duty infrastructure than office-grade work because the user load and the Canadian climate beat on the install. K-12 lockdown is one coordinated response across door, PA, mass notification, and police; the school board owns the policy and the integrator owns the technical integration. Classroom locks always permit egress from inside; verify with the AHJ at design. Post-secondary residences need bulk credential workflows aligned with the academic calendar. Transit stations need vandal-resistant housings, conduit-fed cabling, industrial-rated equipment, and help-point integration with the operations centre. Outdoor conduit in Canadian climates needs NBC Appendix C ice-load values, expansion fittings on long runs, drain holes at low points, sealing fittings at building entries. Mass notification coordinates with the institutional emergency office. Get this discipline right and the install survives the user load and the climate.

================================================================

## Critical infrastructure

URL: https://hans.study/standards-guidance/cssir-19-critical-infrastructure/
Type: kb
Date: 2026-05-10
Description: Critical infrastructure security installs for Canadian institutional work. CSA Z246 oil and gas, electric utility substations, water and wastewater, Health Canada licensed cannabis facilities. SCADA segregation, hazardous-area equipment, EMI-hardened design, regulatory video and retention requirements.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Critical infrastructure work is where a security failure becomes a safety failure. Oil and gas yards, electric utility substations, water and wastewater plants, and Health Canada licensed cannabis facilities operate under regulatory frameworks that treat the security system as part of the operational safety envelope, not as a separate convenience layer. The pathway changes (hazardous-area listings, EMI-hardened equipment), the network changes (SCADA segregation, operations-centre integration), and the audit changes (regulatory retention, mandatory reporting). Walk into a critical infrastructure project with the institutional-office playbook and the install fails the regulatory audit; walk in with the discipline this chapter describes and the install supports the operator's compliance. 

 The risk profile 

 How critical infrastructure differs 

 Commercial and institutional office work has a relatively standard threat model: theft, vandalism, unauthorised access, occasional targeted attack. Critical infrastructure adds nation-state actors, organised attempts at operational sabotage, regulatory inspectors who treat the audit findings as enforcement actions, and the consequence that a successful attack causes physical harm or service disruption to large populations. The integrator's risk tolerance has to match the operator's. 

 The four common verticals 

<DefList>
 <dt>Oil and gas (upstream, midstream, downstream)</dt>
 <dd>Wellheads, pipelines, compressor stations, refineries, terminals. CSA Z246 governs the security framework, with the operator's risk assessment driving design. Hazardous-area classifications limit equipment selection; classified Zone 1 and Zone 2 areas require certified equipment.</dd>

 <dt>Electric utility</dt>
 <dd>Generation stations, substations, transmission yards. CER (Canada Energy Regulator) requirements for federally-regulated assets, provincial regulator requirements for distribution. EMI-hardened equipment for substation environments. Physical security at the substation perimeter is the typical institutional project scope.</dd>

 <dt>Water and wastewater</dt>
 <dd>Treatment plants, pumping stations, reservoirs. Operator (municipal or regional authority) defines the security framework. Indoor environments are corrosive (chlorine, hydrogen sulfide); outdoor environments are weather-exposed. Equipment selection accounts for both.</dd>

 <dt>Health Canada licensed cannabis</dt>
 <dd>Cultivation, processing, storage, and retail facilities licensed under the Cannabis Act and Cannabis Regulations. Prescriptive video, access, and audit requirements with specific retention periods. Health Canada inspects the security install as part of the licence renewal process.</dd>
</DefList>

 Oil and gas (CSA Z246) 

 When the rule applies 

 Every oil and gas facility in Canada under the CSA Z246 framework. The standard sets the framework; the operator's site-specific risk assessment defines the design. 

 The spec 

 
 Security framework per CSA Z246; the operator's risk assessment defines the specific design 
 The operator performs the risk assessment (typically with a security consultant); the integrator implements the design that results 
 Hazardous-area equipment per CEC Section 18 in classified areas:: Class I Division 1 / Zone 0: continuously hazardous atmosphere; intrinsically-safe equipment only Class I Division 2 / Zone 2: hazardous atmosphere under abnormal conditions; non-incendive equipment Equipment certification: CSA marking for the specific Zone and Class 
 Perimeter detection at facility boundaries: photoelectric beams, perimeter LiDAR, or vibration sensors per the operator's risk assessment 
 Access control at every facility entry, with two-factor authentication for restricted areas 
 Video coverage at perimeter, entries, control rooms, and high-value assets (compressor stations, control valves, transformer pads) 
 SCADA network segregated from the physical security network; no bridging between the two without operator's explicit authorisation and a documented architecture 
 Operations-centre integration: events from the security system report to the operator's control room or to a delegated regional operations centre 
 

 Study Note 

 Cameras, readers, intercoms, and other electronic devices installed in CEC-classified hazardous areas have to be certified for the Zone and Class of the area. Verify the certification at procurement, not at install. Cameras certified for Zone 2 cost significantly more than commercial cameras; the operator's risk assessment defines which cameras can be in classified areas and which can be located outside the classification boundary looking in. Do not attempt to field-modify a non-rated camera for hazardous-area service. 

 Electric utility substations 

 When the rule applies 

 Substation security perimeter, control buildings, and equipment yards on transmission and distribution utility assets. CER and provincial regulators define the framework; the utility's standard implements it. 

 The spec 

 
 EMI-hardened equipment for substation environments: cameras, intercoms, access readers rated for the electromagnetic field strength near switchgear and transformers 
 Equipment certifications: IEC 61850-3 for substation electronic equipment, IEEE 1613 for North American substation hardening 
 Redundant grounding per chapter 04 with substation-specific equipotential bonding 
 Perimeter detection at the substation fence line: photoelectric beam, perimeter LiDAR, or vibration sensors per the utility's standard 
 Camera coverage at the perimeter, control building entries, high-value asset pads, and transmission line termination structures 
 Access control at the perimeter gates and the control building doors, with two-factor authentication and supervised credentials per the utility's policy 
 Operations-centre integration: every event reports to the utility's control centre, with the utility's preferred protocol (often DNP3, IEC 61850, or MODBUS over an isolated path) 
 Physical security separation from SCADA: zero bridging between the security network and the operational technology network unless the utility has explicitly authorised and architected the bridge 
 

 Study Note 

 Electric utilities (Hydro One, Hydro Quebec, BC Hydro, AltaLink, others) maintain detailed substation security standards that supersede generic institutional specs. The institutional spec on a substation project is the utility's standard; confirm it at design and align every product, every cable, and every commissioning step with the utility's documented practice. Get a copy of the relevant utility standard before specifying any equipment. 

 Water and wastewater 

 When the rule applies 

 Treatment plants, pumping stations, reservoirs, and water distribution control buildings. The operator (municipal or regional authority) defines the security framework. Federally-regulated water systems (some First Nations, some federal assets) have additional requirements. 

 The spec 

 
 Equipment selection for corrosive indoor atmospheres: chlorine in water treatment, hydrogen sulfide in wastewater. Epoxy-coated enclosures, stainless hardware, gasketted device housings. 
 Equipment selection for outdoor weather exposure: NEMA 4 or NEMA 4X enclosures, IP66 or IP67 device housings, integrated heaters in cold-climate environments 
 Wash-down compatibility at treatment plant interior areas where pressure washing is part of routine cleaning 
 Perimeter detection at the facility boundary per the operator's risk assessment 
 Access control at every facility entry, with extended retention on the audit log per institutional policy 
 Video coverage at the perimeter, entries, treatment process areas, and the SCADA control room 
 SCADA network segregation per chapter 11 and per the operator's IT standard 
 Chlorine and chemical storage room security: dual-authentication at the door, video coverage with extended retention, audit log of every entry 
 Operations-centre integration: security events report to the operator's control centre or to a regional centre 
 

 Study Note 

 Water and wastewater facilities have two distinct equipment environments. Indoor areas near treatment processes have chlorine, hydrogen sulfide, or other corrosive atmospheres that degrade standard institutional equipment. Outdoor areas have weather exposure in Canadian climates. Equipment selection has to address both; verify the device rating against the actual installed environment at design. The institutional-office camera does not survive in a chlorine room; the standard outdoor camera does not survive in a hydrogen sulfide environment. 

 Health Canada licensed cannabis facilities 

 When the rule applies 

 Every facility licensed under the Cannabis Act and Cannabis Regulations: cultivation, processing, storage, packaging, testing, and retail. The Cannabis Regulations Part 4 (Physical Security Measures) define the prescriptive security requirements; Health Canada inspects the install as part of the licence application and renewal. 

 The spec 

 
 Visual monitoring of every entrance to and exit from an operations area (cultivation, processing, packaging, storage) 
 Visual monitoring of every storage area where cannabis is stored 
 Visual monitoring of every location in the facility where cannabis is present 
 Recording quality sufficient to identify a person 
 Recording retention: 1 year minimum per Cannabis Regulations 
 Intrusion detection system covering every entrance to and exit from operations areas and storage areas 
 Intrusion detection system monitored by a licensed monitoring service (ULC-S301 or S302) 
 Access control: documented list of authorised persons, with access records retained for inspection 
 Physical barriers and locks on every operations area and storage area 
 Compliance officer at the facility responsible for the security framework 
 Security records retained for at least 2 years per Health Canada requirements 
 

 Cannabis facility design pattern 

 Unlike most institutional security work, the Health Canada cannabis security requirements are explicitly prescriptive: the regulation says what has to be done, not just what risk has to be managed. Read the Cannabis Regulations in full before designing for a licensed facility. Pull the current regulation at the start of every cannabis project, not the previous project's specification; Health Canada updates the regulations on its own cycle. 
 The institution's compliance officer is the authoritative source for the applicable regulation version; confirm with them at design. 

 Study Note 

 1-year retention on every camera in every operations and storage area is significantly more storage than typical institutional 30-day retention. At 50 cameras with H.265 compression at 2 MP / 15 fps continuous, 1-year retention is roughly 650 TB usable storage. Budget the storage at design; the typical NVR appliance does not support this depth without significant expansion. Consider tiered storage (hot storage for recent recordings, archive storage for the 1-year tail) with the institutional VMS supporting the architecture. 

 SCADA and operational technology segregation 

 When the rule applies 

 Every critical infrastructure project. The Supervisory Control and Data Acquisition (SCADA) network and the broader operational technology (OT) network are the operator's safety-critical control infrastructure. The physical security network is a separate domain that, in general, does not bridge to the SCADA network. 

 The spec 

 
 Physical security network on dedicated infrastructure: separate VLANs at minimum, separate switches and separate physical cabling where the operator's policy requires 
 SCADA network on its own dedicated infrastructure per the operator's IT/OT standard 
 No bridging between the two networks without operator's explicit authorisation and a documented architecture review 
 Where integration is required (security event triggers SCADA acknowledgment, for example), the bridge uses a data diode, application gateway, or unidirectional gateway with documented inspection 
 Network management: the security network has its own NMS, separate from the SCADA NMS 
 Cybersecurity baseline: the security network follows the operator's IT cybersecurity standard; the SCADA network follows the operator's OT cybersecurity standard (typically IEC 62443 or NERC CIP for North American utility) 
 Audit: the security network's audit log is reviewed by the institutional security team; the SCADA audit log is reviewed by the operations team 
 

 Operations centre integration 

 When the rule applies 

 Every critical infrastructure facility. The operator (or a delegated regional operations centre) is the response party for security events; integration is the technical path that gets the event from the facility to the responder. 

 The spec 

 
 Communication path: encrypted WAN connection from the facility to the operations centre, primary and secondary paths 
 Protocol: the operator's preferred event protocol (Genetec federation, Milestone interconnect, SIA-DC09, MODBUS, DNP3, or IEC 61850 depending on the operator) 
 Event types reported: alarm, fault, tamper, access denied, after-hours access, supervisory test, return-to-normal 
 Video stream: cameras viewable from the operations centre on demand; alarm-triggered cameras prioritised 
 Recording: local at the facility (primary) and replicated to a regional or central archive (secondary) per the operator's retention policy 
 Response plan: documented for each event type, with the operator's standard response procedure 
 Annual integration test: every event type tested, every camera viewable, every response procedure verified 
 

 Study Note 

 Operations centres for critical infrastructure vary widely: dedicated operator centres, contracted regional centres, RCMP integration on federal assets, provincial-government centres on some utility assets. Confirm the destination, the protocol, the response time expectations, and the test schedule at design. Build the integration testing into the commissioning plan. 

 Critical infrastructure work needs heavier-duty equipment than commercial and a different risk tolerance. CSA Z246 governs oil and gas; the operator's risk assessment drives the design. Hazardous-area certification is non-negotiable. Electric utility yards need EMI-hardened equipment, redundant grounding, operations-centre integration on the utility's protocol. Water and wastewater have corrosive indoors and weather outdoors; specify for both. Health Canada cannabis facilities have prescriptive video, access, and retention rules; pull the current regulation at every project. SCADA and physical security networks stay segregated; do not bridge without explicit operator authorisation. Operations-centre integration is the technical path that closes the loop. Get this discipline right and the install supports the operator's compliance; get it wrong and the regulatory audit finds the gaps.

================================================================

## Rack and cabinet hardware

URL: https://hans.study/standards-guidance/cssir-20-rack-cabinet-hardware/
Type: kb
Date: 2026-05-10
Description: Rack and cabinet hardware for Canadian institutional security installs. 19-inch rack standards, U-space planning, floor and wall-mount racks, cable management, airflow, PDUs, ground bonding hardware, environmental cabinets, lockable doors and access control.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Racks and cabinets are the furniture that holds the rest of the install up. The active equipment, the patch panels, the UPSs, the controllers, the cable management, the PDUs, and the ground bonding hardware all live in or on the rack. A well-planned rack lasts the building's life with one or two refresh cycles inside; a poorly-planned rack becomes a serviceability problem within five years. The work is straightforward: pick the right rack for the space, plan the U-space at design, install the cable management before the cable, and bond every section per chapter 04. 

 The 19-inch standard 

 When the standard applies 

 Every institutional rack and cabinet on the project. The 19-inch standard (482.6 mm rail spacing) is the universal mounting standard for telecommunications and networking equipment in North America and most international institutional work. 

 The spec 

 
 Rail spacing: 482.6 mm (19") between front rails, EIA-310-D compliant 
 U (rack unit) height: 44.45 mm (1.752") per U 
 Standard heights: 12U, 24U, 36U, 42U, 45U, 48U (42U is the institutional default for floor-standing racks) 
 Mounting hole types:: Square-hole (cage nut) rails: institutional default, accepts cage nut for screw mounting, supports tool-less equipment Threaded rails (12-24 or 10-32): legacy, present on older racks and on some specialty equipment racks Round-hole rails: rare on modern institutional work, present on some older institutional installations 
 Rail depth: adjustable on most institutional racks, sized to the deepest equipment plus 100 mm (4") cable management margin 
 Equipment mounting hardware: cage nuts and machine screws sized for the equipment (typically M6 for square-hole rails) 
 

 Floor-standing racks 

 When the rule applies 

 Main equipment rooms, IDFs with significant equipment density, head-end installations. Floor-standing racks provide full 42U or more of equipment space with cable management and power distribution integrated. 

 The spec 

 
 Height: 42U typical for institutional work, 45U or 48U where the ceiling height supports it and the equipment count warrants 
 Width: 600 mm (24") for standard equipment, 800 mm (32") for high-density installations needing more cable management space 
 Depth: 1000 mm (40") or 1200 mm (48") sized to the deepest equipment plus cable management 
 Open-frame (two-post or four-post) vs. enclosed (cabinet) per the institutional environment:: Open-frame two-post: lightweight, lower cost, used for patch panels and small switches; not for servers or heavy equipment Open-frame four-post: full rail support front and rear, used for general institutional equipment in dedicated equipment rooms Enclosed cabinet: doors front and rear, used where physical security, airflow management, or dust protection is required 
 Castors for installation; levelling feet for the operating position; remove castors after positioning where the institutional standard requires 
 Cage nut rails with the institutional-standard hole pattern; cage nuts supplied and pre-installed where the rack manufacturer supports it 
 Ground bonding hardware per chapter 04: rear-rail ground strip, paint-piercing washers at every assembly bolt, rack ground busbar at the top 
 

 Study Note 

 Hammond C2RR series 42U four-post open-frame racks for general institutional IDFs and equipment rooms; the C2RR has square-hole rails, adjustable depth, levelling feet, and integrated cable management lacers. Hammond NB series enclosed network cabinets where airflow management or physical security warrants the enclosure (the NB series provides front and rear lockable doors, side panels, and roof and floor cable entry options). For very high-density installations, Hammond's larger PROrack series with hot-aisle or cold-aisle containment compatibility. 
 Hammond is the Canadian-manufactured field default for institutional rack work; the product range covers small wall-mount up through enterprise-class floor-standing with consistent rail patterns and accessory compatibility across the line. 

 Wall-mount racks 

 When the rule applies 

 Smaller IDFs, telecom closets, and remote equipment locations where floor space is limited or where the equipment count does not warrant a floor-standing rack. Wall-mount racks come in fixed (non-hinged) and swing-frame (hinged) variants. 

 The spec 

 
 Height: 6U, 9U, 12U, 18U, 24U sized to the equipment count plus 25% spare 
 Depth: 400 mm (16") or 600 mm (24") sized to the equipment depth plus cable management 
 Hinged swing-frame variant where rear access is needed for cable and equipment service 
 Fixed (non-hinged) variant where the wall mounting orientation provides natural rear access 
 Load rating: rated for the equipped weight plus 50% margin; wall mounting hardware sized for the load 
 Wall attachment: into structural studs or to a backboard, sized per the load; concrete anchors per chapter 02 where mounting to masonry 
 Ventilation: passive ventilation slots in the cabinet sides and top; active fans where the equipment heat load warrants 
 Lockable doors with the institutional key control programme 
 Ground bonding hardware per chapter 04 
 

 Study Note 

 Hammond RB series wall-mount cabinets for smaller IDFs and remote equipment locations. The RB series comes in 6U through 24U heights, 400 mm and 600 mm depths, hinged and fixed variants, with lockable front doors and integrated cable management. For installations needing more cable space, Hammond's larger SmartRack wall-mount cabinets with deeper interior dimensions. 

 U-space planning 

 When the rule applies 

 Every rack on the project. U-space planning determines whether the rack accommodates the day-one equipment plus the next refresh, or runs out of space at the first addition. 

 The spec 

 
 Day-one equipment count: every patch panel, every switch, every UPS, every controller, every recorder, every cable manager, with each item's U-height 
 Cable management: 1U or 2U cable management between every functional grouping (between patch panel and switch, between switch and switch, between equipment and UPS) 
 Spare U: minimum 25% spare U-space at install for future expansion (10U on a 42U rack) 
 Patch panels at the top of the rack working downward; equipment switches below; UPS at the bottom (heaviest equipment lowest for centre-of-gravity) 
 Service space: 1U or 2U minimum free space above each switch for tool access during service events 
 Power: PDU mounted vertically (0U) on the rear rail to save U-space for active equipment 
 Cable entry: from the top (overhead cable tray) or the bottom (underfloor) per the equipment room design 
 

 Study Note 

 Plan the U-layout at design with a rack elevation drawing showing every item, its U-height, and its position in the rack. The rack elevation is the deliverable the institution uses at commissioning to verify the install matches the design. Build the elevation in the institutional drafting standard; the architectural and electrical drawings include rack elevations as a standard sheet. 

 Cable management 

 When the rule applies 

 Every rack on the project. Cable management is what separates a rack the next technician can service from a rack that requires an hour of cable tracing for every fifteen-minute change. 

 The spec 

 
 Horizontal cable management: 1U or 2U finger-type or D-ring managers between every patch panel and the adjacent switch, between switches in different functional groups, and between switches and the rack exit 
 Vertical cable management: full-height side channels (typically 4" or 6" wide) for routing patch cords vertically between horizontal managers 
 Cable lacing on horizontal cable from the rear of the patch panel: Velcro hook-and-loop ties at 150 mm (6") intervals, hand-tightened, never zip ties 
 Service slack: 300 mm (12") minimum inside the rack at every termination, coiled neatly 
 Cable separation: data cables on one side of the rack rear, power cables on the other side; do not bundle data and power together 
 Bend radius respected at every dressing point: minimum 4× cable OD for U/UTP, 6× for shielded, 10× for fibre 
 Cable identification at the patch panel face per chapter 06 
 

 Study Note 

 Panduit NMF or NetManager horizontal cable managers in 1U and 2U sizes with hinged front covers for service access. Panduit PatchRunner vertical cable managers in 6" and 8" widths for full-height side routing in 42U racks. Hammond's integrated cable management on the C2RR series for projects where the rack manufacturer's matching cable management is preferred for visual consistency. Velcro hook-and-loop wraps (Panduit HLT or equivalent reusable Velcro) for cable lacing. 

 Airflow and thermal management 

 When the rule applies 

 Every rack with active equipment (switches, servers, UPSs). Heat is the silent killer of rack equipment; airflow management at install determines whether the equipment operates within manufacturer specifications or runs hot for years. 

 The spec 

 
 Front-to-back airflow direction matched across all equipment in the rack: cool air enters the front, warm air exits the rear 
 Blanking panels in every unused U-space to prevent air recirculation around equipment 
 Cable entry sealed at the rack top or bottom to prevent recirculation 
 Enclosed cabinets in cooled equipment rooms: front and rear doors with perforated panels (minimum 60% open area) to allow airflow without compromising security 
 Active rack cooling (fans, AC) where the equipment heat load exceeds the room's cooling capacity at the rack location; institutional design typically locates this in a dedicated equipment room rather than relying on rack-mounted active cooling 
 Temperature monitoring: temperature sensor in the top of every rack with active equipment, reporting to the institutional NMS with alarm thresholds 
 

 Study Note 

 Empty U-spaces in a rack with active equipment create air bypass paths that pull warm exhaust air back to the equipment intake. The equipment runs hot and ages prematurely. Blanking panels in every empty U-space solve the problem at install for pennies per U. Plan blanking-panel quantity at design and install them at commissioning before the equipment is energised. 

 Power distribution at the rack 

 When the rule applies 

 Every rack with active equipment. The rack PDU distributes the branch-circuit power to the equipment; the PDU choice and the topology determine redundancy, monitoring, and serviceability. 

 The spec 

 
 Two PDUs per rack: dual-cord configuration with each PDU on a separate branch circuit and ideally a separate panel per chapter 03 
 PDU form factor: vertical (0U) mounted on the rear rail to save U-space; horizontal 1U or 2U where vertical mounting is impractical 
 Outlet count sized for as-installed plus 25% spare 
 Outlet types per equipment connector: NEMA 5-15R and 5-20R for general 120 V equipment, C13 / C19 for IEC-cord servers and switches 
 Per-outlet metering and remote switching where the institution's NOC manages power remotely 
 Per-PDU current monitoring with alarm threshold at 80% of PDU rating 
 Each PDU labelled with source circuit and served equipment (chapter 06) 
 Surge protection at the rack point-of-use per chapter 03 (some PDU models include integrated SPD) 
 

 Study Note 

 Eaton ePDU G3 in metered or switched variants depending on institutional requirement. Vertical 0U for 42U racks to preserve U-space. Eaton ePDU Basic for non-monitored applications where per-outlet visibility is not required. Match the PDU outlet count and amperage to the rack equipment plus 25% spare; do not undersize the PDU at install because the rack equipment count is going to grow. 

 Environmental cabinets 

 When the rule applies 

 Equipment installed outside standard equipment rooms: outdoor IDFs, transit stations, industrial environments, parking structures, environmental closets in unconditioned spaces. 

 The spec 

 
 Environmental rating per the installation:: NEMA 1 (indoor general): dust and incidental dripping NEMA 4 (outdoor general): rain, sleet, splashing water, hose-directed water NEMA 4X (corrosive outdoor): NEMA 4 plus corrosion resistance NEMA 12 (industrial indoor): dust, dripping non-corrosive liquids NEMA 6P (submersible): occasional temporary submersion 
 Internal thermal management: thermostat-controlled heater for cold-climate operation, fan or vortex cooler for warm-climate operation; sized to maintain the equipment's operating temperature range 
 Door seal: continuous gasket on the door perimeter, replaced periodically per the manufacturer's service schedule 
 Cable entry: gasketed cable glands or compression fittings preserving the enclosure's rating 
 Mounting: outdoor pedestal mount, pole mount, or wall mount with hardware sized for the loaded weight and the wind/ice load (NBC Appendix C climatic data) 
 Security: lockable door with the institutional key control programme; tamper monitoring on the door reported back to the head-end 
 Grounding: enclosure bonded to the building grounding system per chapter 04 
 

 Study Note 

 Hammond's outdoor NEMA-rated cabinet line covers most institutional environmental applications: NEMA 4 and 4X for outdoor, NEMA 12 for industrial indoor, NEMA 6P for submersible service. Sized to the equipment U-count plus thermal management plus spare. For very large environmental installations (transit substations, utility yards), Hammond's PROrack series with environmental options provides the same form factor as indoor equipment with the appropriate environmental rating. 

 Rack access control and tamper monitoring 

 When the rule applies 

 Racks holding access control head-end equipment, sensitive servers, or critical infrastructure equipment. The rack is treated as a secure asset; access is monitored and tampered conditions are reported. 

 The spec 

 
 Lockable doors front and rear on enclosed cabinets, with the institutional key control programme 
 Higher-security applications: electronic access at the rack door using an Allegion / Schlage cabinet lock with the institutional credential 
 Tamper switch on the rack door reporting to the head-end (door open / closed status with alarm on after-hours open) 
 Audit log: rack open events with timestamp, credential (where electronic), and duration retained per the institutional retention policy 
 Camera coverage of the rack location for critical assets (access control head-end, evidence-room recording servers, federal court rack rooms) 
 Physical key control: master keying coordinated with the institutional key control programme; spare keys held in the institutional key vault 
 

 Racks are furniture that holds everything else up. Hammond is the Canadian-made institutional default for both floor-standing and wall-mount, with consistent product range from 6U wall to 48U floor. 42U four-post open-frame in dedicated equipment rooms, enclosed cabinet where airflow or physical security warrants it, wall-mount in smaller IDFs. Plan the U-space at design with 25% spare. Cable management between every functional grouping, horizontal and vertical. Blanking panels in every empty U-space. Dual-PDU configuration with each PDU on a separate circuit. Environmental cabinets sized to the actual environment, not generic outdoor ratings. Bond every rack section per chapter 04. Get this layer right and the rack outlasts two equipment refreshes without rework.

================================================================

## Tools of the trade

URL: https://hans.study/standards-guidance/cssir-21-tools-of-the-trade/
Type: kb
Date: 2026-05-10
Description: Tools for Canadian institutional security install work. Hand tools, power tools, cable installation and termination tools, test instruments, software platforms, truck stock, calibration and maintenance schedule.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Tools are the smallest line item on the project budget and one of the largest factors in the quality of the install. The right tool, maintained and calibrated, produces a consistent result across hundreds of repetitions. The wrong tool, worn or improvised, produces termination quality that varies by technician and by day. The list below is the institutional field kit: what is on the truck, what is in the shop, and what gets calibrated at what interval. 

 Hand tools for general install 

 When the tools apply 

 Every project. The hand tools are the technician's daily kit and travel with the truck. 

 The spec 

 
 Screwdrivers: insulated for electrical work, Phillips #1 / #2 / #3 and slotted in matching sizes, plus Robertson #1 / #2 (institutional Canadian) 
 Pliers: lineman's pliers, needle-nose pliers, side-cutting pliers, channel-lock pliers, insulated for electrical work 
 Wire strippers: gauge-marked for the common AWG range (10 to 24 AWG) 
 Crimpers: ratcheting crimpers for terminals and ferrules, sized for the wire gauge range 
 Hex key set: metric and SAE, full range from 1.5 mm to 10 mm and 1/16" to 3/8" 
 Nut driver set: metric and SAE, matching common terminal screw sizes 
 Tape measure: 25 ft / 8 m minimum for general work, with metric and imperial markings 
 Utility knife: retractable blade, fixed-blade for cable jacket stripping 
 Drywall saw, hole saw set for backbox installation 
 Spirit level: 12" / 300 mm minimum for camera and reader mounting 
 Headlamp and flashlight: rechargeable, with red-light mode for camera installations where ambient light disturbance matters 
 

 Study Note 

 Klein Tools for the general hand-tool kit: insulated screwdrivers, lineman's pliers, side-cutters, wire strippers. Knipex Cobra pliers for water-pump grip and adjustable wrench applications. Wera screwdriver sets for precision work and for Torx with security-pin fasteners on detention and high-security installs. Klein's institutional-grade tape measure and utility knife round out the basic kit. The Klein / Knipex / Wera combination has been the institutional field default for years; the tools last under daily use and the warranty support is consistent across Canadian distribution. 

 Power tools 

 When the tools apply 

 Cable pulling, conduit cutting, hole drilling, anchor installation, equipment mounting. Battery-powered tools are the institutional default for portability and for working in occupied spaces; corded tools are reserved for sustained high-power applications. 

 The spec 

 
 Cordless drill / driver: 18 V or 20 V minimum, brushless motor, with hammer-drill mode for masonry anchors 
 Cordless impact driver: 18 V or 20 V, for fastener driving and structural mounting 
 Cordless reciprocating saw: 18 V or 20 V, for cutting drywall, conduit, and through-wall openings 
 Cordless rotary hammer: 18 V or 20 V, for concrete and masonry anchor installation with SDS-plus or SDS-max bits per anchor size 
 Cordless band saw or cut-off tool: for cutting RGS and IMC conduit in trade sizes up to 50 mm (2") 
 Battery platform: single platform across all tools (one manufacturer, one battery family) for kit consolidation 
 Corded tools for sustained heavy work: hydraulic conduit bender for RGS, hydraulic crimper for large-gauge lugs, drain rod / fish tape for long conduit pulls 
 Personal protective equipment: safety glasses, hearing protection, dust mask, gloves, hard hat per the job 
 

 Study Note 

 Pick one battery platform per technician and stay in it. Mixing platforms means carrying multiple chargers, multiple battery types, and multiple sets of spare batteries. The institutional default tends to be Milwaukee M18 or DeWalt 20V Max, both with broad tool ranges across drill, impact, saw, hammer, and specialty applications. The choice is less important than the consistency; pick one and equip the whole crew. 

 Cable installation tools 

 When the tools apply 

 Every cable pull on every project. The cable installation kit gets used more than any other category of tool; the discipline is treating cable-handling tools as precision instruments, not as commodity items. 

 The spec 

 
 Fish tape: steel for general pulls, fibreglass for non-conductive applications (near energised conductors), in 50 ft, 100 ft, and 200 ft lengths 
 Cable lubricant: water-based, polymer-based for Cat 6A and fibre pulls to reduce friction and pulling tension 
 Cable pulling grip: basket-weave grip in sizes matching common cable OD ranges; mesh grip for jacketed cable 
 Cable reel stand: collapsible stand for paying cable off spools cleanly, in single and multi-spool configurations 
 Cable caddy: portable cable holder for short pulls and for in-rack patch-cord work 
 Pulling rope: 1/4" and 3/8" pulling rope in 100 ft and 200 ft lengths, with swivel hardware 
 Tension gauge: inline tension meter for monitoring pull tension on long Cat 6A and fibre pulls (chapter 07 and chapter 08 pulling tension limits) 
 Cable separator: comb tool for separating cable bundles after a pull, before termination 
 

 Study Note 

 Rack-A-Tiers cable pulling tools for the institutional field kit: the Bullet Trainer fish tape, the cable caddy, and the wire dispenser collection are the Canadian-made field defaults for pulling and reel-stand work. Rack-A-Tiers also makes specialty cable-pulling accessories that hold up under daily use better than the consumer-grade alternatives. The cable-management portion of the truck pays back many times over the install life of a single project. 

 Termination tools 

 When the tools apply 

 Every termination on every project. The termination tools are the precision instruments that determine cable plant performance. 

 The spec 

 
 110 punch tool: impact punch with replaceable blade, gauge-marked for cycle count, with the cut-off feature for trimming conductors flush after punch 
 Keystone-specific punch tools: per the jack manufacturer's specification (Panduit Mini-Com tool, CommScope SYSTIMAX tool, Belden REVConnect tool, depending on the cable warranty programme) 
 Cat 6A cable jacket stripper: rotary stripper sized for the Cat 6A jacket OD, with adjustable depth to avoid nicking conductor insulation 
 Coax tools: rotary stripper, compression connector tool, F-connector torque driver 
 Ferrule crimper: ratcheting crimper for wire ferrules in the AWG range typical for institutional signal cabling 
 Fibre tools: precision strippers for 250 μm and 900 μm fibre, cleaver matched to the fusion splicer, cleaver blade gauge for tracking blade rotation interval 
 OTDR launch reels: in single-mode and multimode, minimum 100 m of fibre, calibrated annually 
 Connector inspection scope: handheld for spot inspection, automated IEC 61300-3-35 evaluation for production work (chapter 08) 
 

 Study Note 

 The 110 punch blade wears with use; a worn blade produces inconsistent terminations and Cat 6A links that test near the limit instead of with margin. Replace blades on the manufacturer's interval (typical 5,000 to 10,000 cycles) and keep a spare blade in the kit. The cleaver blade on the fusion splicer follows the same principle: rotate or replace on the manufacturer's interval, never run a cleaver into the next install without confirming the blade position. 

 Test instruments 

 When the tools apply 

 Cable testing, fibre testing, network troubleshooting, electrical verification, environmental monitoring. The test instruments are calibrated annually and verified at the start of each shift. 

 The spec 

 
 Cable certifier: Cat 6A and Cat 6 certification per ANSI/TIA-568.2-E (chapter 10) 
 Fibre certifier: Tier 1 OLTS for insertion loss, Tier 2 OTDR where required (chapter 10) 
 Fibre inspection scope: automated IEC 61300-3-35 evaluation for connector end-faces 
 Network analyser: handheld for Ethernet link verification, PoE budget verification, VLAN tagging verification 
 Toner and probe: for cable tracing on uncertified runs and for troubleshooting 
 Multimeter: digital multimeter with TRMS, CAT III 600 V or CAT IV 600 V rating for institutional electrical environments, with current clamp accessory 
 Earth ground tester: for building grounding electrode resistance measurement (chapter 04) 
 Insulation tester (megger): for cable insulation verification 
 Light meter and lux meter: for camera lighting verification at commissioning 
 Temperature and humidity meter: for IDF environmental verification 
 

 Study Note 

 Fluke Networks for cable and fibre testing: DSX-8000 or DSX2-8000 for copper certification, CertiFiber Pro for fibre Tier 1, OptiFiber Pro for fibre Tier 2 where required, FI-7000 FiberInspector Pro for connector inspection. NetAlly for network troubleshooting: EtherScope nXG or AirCheck G3 for handheld network analysis. Fluke for general electrical instruments: 87V multimeter, 1625-2 earth ground tester, 1587 FC insulation multimeter. The Fluke and NetAlly product lines integrate cleanly with LinkWare Live (Fluke's cloud platform) and Link-Live (NetAlly's platform) for institutional documentation. 

 Software platforms 

 When the tools apply 

 Every project. Software platforms support design, commissioning, certification, documentation, and project management. The list below is the typical institutional kit. 

 The spec 

 
 Camera design and PPF calculation: Axis Site Designer, JVSG IP Video System Design Tool, or IPVM Camera Calculator for camera position and lens selection (chapter 14) 
 Cable certification platform: Fluke Networks LinkWare Live for copper and fibre certification reports, project archival, and warranty registration (chapter 10) 
 Network analysis platform: NetAlly Link-Live for network test reports and historical comparison 
 Drafting and as-built: AutoCAD or Revit per the institutional standard; institutional drafting templates supplied at design 
 Project management: institutional standard project management platform (Microsoft Project, Smartsheet, Procore, or institutional equivalent) 
 Documentation: PDF authoring, Markdown editing, and institutional document management for as-built deliverables 
 Code reference: digital copies of the current CEC, OBC or provincial building code, CSA T-series, ULC standards, ANSI/TIA, BICSI manuals (chapter 01) on the field laptop 
 Access control programming tools: per the platform vendor (Genetec Config Tool, Software House C-CURE 9000 Administration Workstation, HID Aero Configurator, Hirsch Velocity client) 
 Camera configuration tools: per the manufacturer (Axis Device Manager, Bosch Configuration Manager, Avigilon Camera Configuration Tool) 
 Switch configuration: per the platform vendor (Cisco CLI, Aruba CLI, vendor management platform) 
 

 Truck stock 

 When the inventory applies 

 Daily service work and small-scale installations. The truck stock is the consumables and small parts that prevent return trips for items the technician should have on board. 

 The spec 

 
 Cable: 100 ft to 500 ft spools of Cat 6A CMP, Cat 6A CMR, 18/2 stranded security signal cable, 22/4 shielded for access control reader runs 
 Connectors: RJ45 plugs and field-terminable jacks for emergency restoration, 110 keystone jacks in the project-standard category 
 WAGO 221 series lever-action connectors in 2-conductor, 3-conductor, and 5-conductor variants 
 Terminal block accessories: end barriers, partition plates, jumpers, ferrules in common AWG sizes 
 Mounting hardware: cage nuts, M6 screws, machine screws, drywall anchors, concrete anchors in common sizes 
 Fasteners: tamper-resistant Torx with security pin in common sizes for detention and high-security service 
 Cable management: Velcro hook-and-loop wraps, cable lacing cord, blanking panels in 1U and 2U 
 Labels: DYMO Rhino or Epson LabelWorks PX cartridges in the project-standard sizes 
 Batteries: replacement SLA batteries in common sizes for door power supplies and intrusion panels 
 Patch cords: Cat 6A patch cords in 1 m, 2 m, 3 m, 5 m lengths in the project-standard colour 
 Fibre patch cords and pigtails: in OS2 and OM4, LC duplex, UPC polish standard 
 Common spare parts: PIR sensors, glass-break sensors, door contacts, basic-style readers for emergency replacement 
 

 Study Note 

 Truck stock that does not get used decays into dead inventory. Cycle the stock monthly: replace anything with an expiry date (sealant compounds, some adhesives), restock the consumables to the standard level, and remove anything that has not been used in six months and is not on the standard list. The truck weight matters for fuel economy and for vehicle suspension; do not let the truck become a mobile parts depot. 

 Calibration and maintenance schedule 

 When the schedule applies 

 Every calibrated instrument and every wear-item tool. The institutional kit maintains its accuracy and its useful life on a documented schedule, not by guess. 

 The spec 

 
 Cable certifier: factory calibration annually, self-test at the start of each shift 
 Fibre certifier: factory calibration annually, reference set at the start of each test session 
 Multimeter: factory calibration annually for CAT-III and CAT-IV instruments 
 Earth ground tester: factory calibration annually 
 Punch tool: blade replacement at manufacturer interval (typically 5,000 to 10,000 cycles) 
 Fusion splicer cleaver: blade rotation at manufacturer interval, blade replacement when all positions are exhausted 
 Hydraulic crimper: pressure verification annually, die replacement when crimp dimensions drift outside the manufacturer's tolerance 
 Battery-powered tools: battery replacement when capacity falls below 80% of new (the tool platform's battery analyser reports this) 
 Cable reels and stands: visual inspection monthly, mechanical service annually 
 Calibration records: retained in the institutional QA system with the calibration certificate, the calibration date, and the next-due date for every instrument 
 

 Study Note 

 Institutional projects often require certificate of calibration for every test instrument used at acceptance. The institution's QA reviews the certificates and checks the calibration date against the test date. An expired calibration invalidates the test result; the work has to be re-tested with a calibrated instrument. Build the calibration schedule into the institutional QA system and never let it drift. 

 Tools are the work made visible. Klein, Knipex, and Wera for general hand tools. Single battery platform for power tools across the crew. Rack-A-Tiers for cable pulling and wire dispensing on Canadian institutional installs. Manufacturer-specific punch tools matched to the project's cable warranty programme. Fluke and NetAlly for test instruments, with annual calibration and start-of-shift self-test. Software platforms standardised across the team (Fluke LinkWare Live, NetAlly Link-Live, institutional drafting and PM tools). Truck stock cycled monthly to prevent dead inventory. Calibration records retained for every instrument. Choose the tools once, take care of them, and replace them when they wear or when the technology improves enough to warrant it.

================================================================

## Commissioning and acceptance

URL: https://hans.study/standards-guidance/cssir-22-commissioning-acceptance/
Type: kb
Date: 2026-05-10
Description: Commissioning and acceptance for Canadian institutional security installs. Pre-commissioning verification, CAN/ULC-S1001 integrated systems testing, per-system commissioning, final acceptance walkdown, training, post-substantial-completion follow-up, documentation handover.

import SpecBlock from '../../components/kb/SpecBlock.astro';
import RecBlock from '../../components/kb/RecBlock.astro';
import Callout from '../../components/kb/Callout.astro';
import Warn from '../../components/kb/Warn.astro';
import Take from '../../components/kb/Take.astro';
import Note from '../../components/kb/Note.astro';
import Tip from '../../components/kb/Tip.astro';
import DefList from '../../components/kb/DefList.astro';

 Commissioning is where the work becomes the institution's. Up to this point, the install is the integrator's responsibility: the cable plant, the hardware, the configuration, the test results. After acceptance, the system is the institution's: the cardholders, the recordings, the audit logs, the operational practice. The handover happens through a documented commissioning process that confirms every system performs against the design intent, every integration works, every record is in place, and the institutional staff can operate the system without the integrator on call. Get the commissioning right and the project closes cleanly; skip it and the institution holds the integrator on the project for months past substantial completion. 

 Pre-commissioning verification 

 When the verification applies 

 Before any system testing begins. The pre-commissioning checks confirm that the install is physically ready for testing: as-built drawings match the install, cable plant is certified, panel directories are complete, and the test instruments are calibrated. 

 The spec 

 
 As-built drawings updated to reflect the install: every device, every cable route, every panel, every conduit 
 Cable certification reports complete and submitted (chapter 10): every link PASS without asterisk, manufacturer warranty registered within 30 days of cable plant completion 
 Panel directories complete (chapter 06): every breaker entry identifies the served device, every circuit type identified with the institutional convention 
 Identification and labelling complete (chapter 06): every cable labelled both ends, every conduit colour-banded at terminations and transitions, every device with lamacoid plate 
 Firestop documentation complete (chapter 05): every penetration identified on the firestop drawing with ULC system number, hour rating, installer, date 
 Grounding measurements complete (chapter 04): every TGB and TMGB measured at less than 5 ohm to building ground reference, every rack measured at less than 1 ohm to TGB 
 Test instruments calibrated and certified (chapter 21): every certifier, every multimeter, every ground tester with current calibration certificate 
 Institutional team present: institutional security manager, institutional IT representative (where applicable), institutional facility management representative 
 Commissioning agenda distributed in advance with the test sequence, the responsible parties, and the expected duration 
 

 Study Note 

 Pre-commissioning is not a formality; it is the checkpoint that catches defects before the full commissioning. A failed pre-commissioning check (incomplete certifications, missing labels, drawings out of date) means commissioning gets postponed and rescheduled. Schedule pre-commissioning two weeks before the planned commissioning date to give time for any remediation. Walk the pre-commissioning checklist with the project manager and the institutional representative; do not self-certify the pre-commissioning state. 

 CAN/ULC-S1001 integrated systems testing 

 When the standard applies 

 Every project where the security system interfaces with life-safety systems: fire alarm, voice evacuation, smoke control, sprinkler, elevator recall, magnetic lock release, access control release. CAN/ULC-S1001 governs the integrated test that confirms all systems work together during a fire event. 

 The spec 

 
 Integrated test conducted with the fire alarm contractor, the security integrator, the elevator contractor, the sprinkler contractor, and the institutional life-safety coordinator 
 Test scenarios per the project's life-safety design narrative:: General alarm: building-wide release of fail-safe locks and maglocks per the institutional release strategy Smoke compartment alarm: locks in the affected compartment release; others remain controlled (healthcare and high-rise) Sprinkler waterflow: same release as general alarm or per the design Manual pull station: same release as general alarm Elevator recall: elevator cars return to ground floor; access control elevator interface verifies floor access is restricted post-recall Voice evacuation: PA system delivers the institutional evacuation message; mass notification platform delivers complementary messages 
 Each scenario tested in real-time with the building's actual systems, not in simulation 
 Reset sequence tested: fire alarm reset returns all systems to normal state without manual intervention at each system 
 Test results documented: timestamp of each event, system response, witnesses present, any deficiencies noted 
 Re-test of any failed scenario after remediation 
 Final report signed by all participating contractors and the institutional life-safety coordinator 
 

 Study Note 

 CAN/ULC-S1001 integrated systems testing is the gate to occupancy permit on most institutional Canadian projects. The AHJ reviews the S1001 report before issuing the occupancy permit. The security integrator is one of several trades that participates; the fire alarm contractor typically leads the test, but every trade's interfaces are tested. Schedule the S1001 with at least four weeks of lead time; coordinating five or six contractors plus the AHJ takes that long. 

 Per-system commissioning 

 When the checklist applies 

 Every security system on the project. The per-system commissioning verifies each system's performance against design intent before the integrated systems testing and the institutional acceptance walkdown. 

 Cabling commissioning 

 
 Cable certification reports complete and submitted to manufacturer for warranty registration (chapter 10) 
 Permanent link test PASS without asterisk on every Cat 6A and Cat 6 link 
 Fibre Tier 1 OLTS PASS on every link, both directions, at both wavelengths 
 Fibre Tier 2 OTDR where required, with event table and overall loss within budget 
 Labels match the as-built cable schedule at both ends of every cable 
 Patch cords installed and labelled per the design 
 Service slack present at every termination per the design 
 

 Power and grounding commissioning 

 
 Every security circuit traced from breaker to receptacle, with the receptacle labelled per the panel directory 
 Receptacle voltage measured under load: within +/-5% of nominal 
 Receptacle polarity, neutral, and ground continuity verified with receptacle tester 
 UPS runtime tested at actual installed load: discharge UPS to a representative test load and measure runtime against the design target (chapter 03) 
 Generator transfer tested where the building has emergency power: simulate utility loss, observe ATS transfer, verify every security device rides through, verify UPS does not exhaust, verify return transfer when utility restores 
 Surge protection alarm contacts verified: SPD alarm output reaches the head-end and triggers an event 
 Grounding measurements: TMGB to building ground less than 5 ohm, TGB to TMGB less than 1 ohm, rack to TGB less than 1 ohm (chapter 04) 
 Bonding measurements at every paint-piercing washer, every cable tray splice, every equipment chassis bonding point 
 

 Access control commissioning 

 
 Every door tested with valid credential: card present, door unlocks, door opens, door closes, door re-locks, event logged 
 Every door tested with invalid credential: card present, door does not unlock, denial event logged 
 Every door tested with REX (request-to-exit): REX activates, door unlocks for fail-secure or releases hold for fail-safe, door-forced alarm shunts 
 Every door tested with DPS (door position switch): door open, alarm reports; door closed, alarm clears 
 Every door tested for door-held-open alarm: door open beyond programmed time, alarm reports 
 Every door tested for door-forced alarm: door opened without REX or valid credential, alarm reports 
 Every door tested for fire alarm release per the institutional release strategy (covered in S1001 above) 
 Cardholder enrollment workflow tested: add cardholder, assign access group, present credential at trained door, verify access 
 De-provisioning workflow tested: remove cardholder, present credential at door, verify denial 
 Audit log verified: every event captured with correct timestamp, correct location, correct cardholder identifier 
 Where two-factor is implemented: card-plus-PIN flow tested at every two-factor door, including PIN lockout after failed attempts and PIN reset workflow 
 Where infant abduction or elopement prevention is installed: every transmitter, every reader antenna, every elevator integration, every stairwell integration tested with a transmitter at the device 
 Where sallyport interlock is installed: interlock tested in every state with the institutional security team witnessing (chapter 16) 
 

 Video commissioning 

 
 Every camera live-viewable from the institutional security operations workstation 
 Every camera recording: verified by reviewing 24 hours of recording from each camera post-commissioning 
 PPF measurement at each camera's design target location: tape measure or pixel-counting tool confirms the design PPF is achieved 
 Camera focus, aim, and field of view verified at the design location 
 Low-light performance verified after dark for cameras in areas with night-time activity 
 IR illumination verified for cameras with IR; image quality at full darkness verified 
 Camera tamper alarm tested: physical tamper of the camera generates a tamper event at the head-end 
 VMS storage verified: storage volume matches design, recording retention matches institutional policy 
 VMS user accounts created per institutional access policy; password complexity and account expiry verified 
 Camera time sync verified: timestamp on every recording within 1 second of the institutional time source 
 VMS health monitoring: alarm threshold tested for camera offline, storage full, server CPU high 
 

 Intrusion commissioning 

 
 Every zone tested in normal state: zone shows "normal" at the panel 
 Every zone tested in alarm state: trigger the sensor, verify alarm at the panel, verify report to the central station 
 Every zone tested for tamper: open the sensor housing or the junction box, verify tamper at the panel 
 Every zone tested for fault: short the loop, verify fault at the panel; cut the loop, verify open fault at the panel 
 EOL resistor supervision verified by measurement at the sensor end of every loop 
 Arm/disarm workflow tested with valid user credential 
 Entry/exit delay verified at programmed time 
 Panel reports to central station: every event type tested with central station confirming receipt 
 Panel battery backup tested: AC removed, verify panel runs on battery for the design hold time, verify "AC fail" event reports to central station 
 Panel tamper tested: open the cabinet, verify panel tamper alarm and central station report 
 Communication path failure tested: disable primary IP communication, verify failover to cellular within the supervised interval 
 

 Final acceptance walkdown 

 When the walkdown applies 

 After per-system commissioning is complete and the S1001 integrated test has been signed off. The acceptance walkdown is the institutional representatives' physical walk of the entire install, confirming visual, functional, and operational standards are met. 

 The spec 

 
 Institutional team participates: security manager, IT representative, facility management representative, privacy officer where applicable, clinical lead where applicable (healthcare), accessibility consultant where applicable 
 Integrator team participates: project manager, lead technician, system commissioner 
 Walkdown sequence: pre-walk the route with the institutional team, present the as-built drawings and the commissioning documentation, walk the install systematically (perimeter, public areas, controlled areas, secure areas, equipment rooms) 
 At each location: confirm device installed per design, labelled per identification standard, mounted per height standard, operational per functional test 
 Deficiencies recorded in real-time on the deficiency list, with location, description, photo, and target resolution date 
 Minor deficiencies (labels, cosmetic, non-functional) get a follow-up date; functional deficiencies (failed operational test) require immediate remediation and re-test before acceptance 
 Final acceptance form signed by the institutional security manager and the integrator project manager when the deficiency list is closed or contains only documented future-work items 
 

 Study Note 

 The deficiency list is the official record of what is not yet done. Every item gets an action owner, a target resolution date, and a verification path. Open items prevent final acceptance and prevent the final payment milestone. Close the deficiency list cleanly: rework completed, re-tested, and signed off, not just claimed-as-done. Build the deficiency list workflow into the commissioning plan and assign a dedicated person on the integrator's team to track it. 

 Training delivery 

 When the training applies 

 At commissioning or shortly after, before the system goes into operational use by the institutional staff. Training is the handover that gives the institution the knowledge to operate the system independently. 

 The spec 

 
 Operator training: for security operations staff, covering daily operational tasks (monitoring, responding to alarms, retrieving recordings, processing cardholder requests) 
 Administrator training: for security technical staff, covering system administration (adding/removing cardholders, modifying access groups, configuring schedules, managing reports) 
 Facility maintenance training: for facility management staff, covering basic troubleshooting, replacement of consumable items (UPS batteries, sensor batteries on wireless systems), and escalation procedures 
 Training delivered as a combination of classroom (concepts and overview) and on-system (hands-on practice with the actual installed system) 
 Training materials: institutional-branded operator manuals, administrator references, quick-reference cards for the common workflows 
 Training records: each trainee signs an attendance record retained in the institutional training documentation 
 Follow-up training: scheduled at 30 days, 90 days, and 1 year post-acceptance to refresh and to address questions arising from operational experience 
 

 Study Note 

 Most institutional environments have their own training infrastructure: an LMS, an internal trainer team, an ongoing-education programme. Rather than delivering all training directly, train the institutional trainer to deliver the institution's standard course. The integrator's role becomes the master content source and the technical reference; the institutional trainer carries the recurring delivery. This pattern scales better than direct training at every refresh. 

 Documentation handover 

 When the handover applies 

 At final acceptance. The documentation package is the institution's reference for the system's operational life: how it was designed, how it was installed, what it tested at, how it gets serviced. 

 The spec 

 
 As-built drawings: every device, every cable route, every panel, every conduit, in the institutional drafting standard 
 Cable certification reports: PDF and native certifier format files, archived for manufacturer warranty audit 
 Manufacturer warranty certificates: cable plant warranty, equipment warranty for each major component 
 Firestop documentation: firestop drawing with every penetration identified, ULC system numbers, installer details, dates 
 Configuration backups: switch configurations, access control panel configurations, intrusion panel configurations, VMS configuration, head-end server backup 
 Panel directories: every electrical panel feeding security loads 
 Key control records: every credential issued at commissioning, every physical key cut, every electronic credential created 
 CMMS asset registration: every major component registered in the institutional CMMS (chapter 06) 
 Operator manuals and administrator references 
 Training records 
 Test and commissioning reports: per-system commissioning, S1001 report, acceptance walkdown sign-off 
 Spare parts inventory at handover: what spare parts are on site, where they are stored, who is responsible for the inventory 
 Service contact list: integrator service number, manufacturer support contacts, central station contact 
 

 Post-substantial-completion follow-up 

 When the follow-up applies 

 30 days, 90 days, and 1 year after substantial completion. The follow-up walkdowns address issues that emerge in operation but did not appear during commissioning. 

 The spec 

 
 30-day walkdown: visit the site with the institutional security manager, walk the install, address any operational issues that have arisen in the first month 
 30-day review topics: false alarm rate, user feedback on workflow, any service tickets logged, any items from the deficiency list still outstanding 
 90-day walkdown: same scope as 30-day, plus review of audit logs, recording retention, and capacity utilisation 
 90-day review topics: storage utilisation trending, PoE budget consumption, switch resource utilisation, false alarm trends 
 1-year walkdown: full inspection of the install per CAN/ULC-S302 for monitored intrusion, plus operational review with the institutional team 
 1-year review topics: warranty status of every component, lifecycle planning for the upcoming year, scheduled preventive maintenance plan 
 All walkdowns documented with attendees, findings, action items, and follow-up dates 
 Action items from walkdowns tracked in the institutional service ticket system 
 

 Study Note 

 Commissioning verifies that the system performs as designed at install. The first year of operation reveals what was not foreseen: user workflows that the design did not anticipate, environmental factors that produce false alarms, integration edge cases that come up in actual use. Build the follow-up walkdowns into the project; they are the difference between an install that gets fine-tuned over the first year and one that accumulates frustration and service calls for years afterward. 

 Commissioning is where the work becomes the institution's. Pre-commissioning checkpoint two weeks before commissioning to catch missing items. CAN/ULC-S1001 integrated systems testing is the gate to occupancy; coordinate with fire alarm, elevator, sprinkler, and life-safety trades four weeks ahead. Per-system commissioning covers cabling, power, grounding, access control, video, and intrusion with documented test results. Final acceptance walkdown with the institutional team produces a deficiency list that gets closed before sign-off. Training delivered to operators, administrators, and facility maintenance; train the institutional trainer where the LMS supports it. Documentation handover includes as-builts, certifications, warranties, configurations, panel directories, key control records, CMMS registrations, manuals, and training records. 30-day, 90-day, and 1-year follow-up walkdowns close the install lifecycle. Get this right and the institution operates the system independently; get it wrong and the integrator is on the project months past substantial completion.

================================================================

## Hardening Windows Server 2016, 2019, and 2022: Getting Started

URL: https://hans.study/standards-guidance/hardening-microsoft-windows-server-2019-and-2022-environments-getting-started/
Type: kb
Date: 2025-04-22
Description: Baseline Windows Server hardening: update management, roles audit, local accounts, Windows Firewall, services, NTP, PowerShell logging, and TLS.

// Lifecycle notice, updated 23 August 2026 
 Windows Server 2016 reaches end of support on 12 January 2027. Everything below still applies to a 2016 host, and hardening one you cannot move yet is worth doing. But if that box carries a VMS, an access control server, or anything else that has to keep running, the hardening work and the migration plan belong in the same conversation. Server 2019 runs to 9 January 2029 and Server 2022 to October 2031. The supported routes and a full pre-flight checklist are in the Windows Server migration reference . 
 If you are standing up a new system this year, do not build it on 2016 because the application vendor still lists it as supported. Vendor support matrices lag Microsoft lifecycle by years, and "supported by the VMS" and "supported by Microsoft" have quietly stopped meaning the same thing. 
 

 
 Baseline Hardening, Before and After 
 
 Telnet enabled → SSH only Remote access protocol 
 SMBv1 on → SMBv1 off File sharing protocol 
 Admin shared → LAPS unique Local administrator password 
 Balanced power → High Performance Power plan (+ performance) 
 FW default → FW explicit rules Windows Firewall 
 No NTP → Domain NTP Time synchronization 
 
 These are table-stakes changes. Not optional. Apply before the system goes into production. 
 
 Not every environment is running Windows Server 2025. Many organizations are still operating on Server 2016, 2019, or 2022, and plenty will be for years. These are supported, viable platforms that can be secured effectively. The steps to do that are well-established, and most of them are not complicated. 
 This post covers the baseline hardening approach for Windows Server 2016 through 2022. The focus is on what to do in the first pass, the changes that should be applied to every server before it handles production workloads. The Advanced Audit Policy configuration and Group Policy hardening are covered in separate posts in this series. 
 
 Why This Needs to Be Done Deliberately 
 A freshly installed Windows Server is not hardened. The default configuration is designed for maximum compatibility. Services that may be needed are enabled. Protocols that have been deprecated are still active. Default accounts exist with default settings. The assumption is that the administrator will configure the server appropriately for its purpose. In practice, that configuration step gets skipped more often than it gets done. 
 Physical security environments compound this problem. Genetec servers, C-CURE servers, Milestone servers, these systems often run on Windows Server. The integrators who deploy them are usually excellent at the security application but frequently less comfortable with the OS hardening. The result is a well-configured VMS running on a poorly hardened Windows installation. 
 This is the starting point. Get these right before anything else. 
 
 Windows Update Configuration 
 Security updates should be applied. On servers supporting physical security applications, test updates before applying them to production. Most Genetec, Milestone, and C-CURE deployments have documented compatibility with specific Windows patch levels, check the vendor's release notes before applying a major cumulative update to a production system. 
 For servers where automatic updates are acceptable, configure Windows Update through Group Policy to defer feature updates (which can break application compatibility) while applying security updates on a defined schedule. 
 For isolated or mission-critical systems where automatic updates are not acceptable, use WSUS to control update distribution. Document the update approval and testing process. A server that has not received security updates in 12 months is not a stable system. It is a system where stability is being traded for exposure. 
 Consider Windows LTSC (Long-Term Servicing Channel) for servers running physical security applications. LTSC receives security updates without the feature releases that can cause application compatibility problems. Several major VMS vendors explicitly support LTSC versions. This is particularly relevant for servers that cannot be updated frequently due to application compatibility constraints. 
 
 Roles and Features Audit 
 Windows Server installs with a set of roles and features that may not be needed for the server's specific function. Every enabled feature is part of the attack surface. Disable what you do not need. 
```
## Audit installed roles and features:
Get-WindowsFeature | Where-Object {$_.Installed -eq $true} | Select DisplayName, Name
## Remove features that are not needed:
## Example: Remove Windows Media Player (often installed by default)
Remove-WindowsFeature Windows-Media-Player
## Remove Internet Explorer (use Edge or Chrome, not IE):
Remove-WindowsFeature Internet-Explorer-Optional-amd64
## Remove SMBv1:
Remove-WindowsFeature FS-SMB1
```
 SMBv1 must be removed. It is not simply a matter of disabling the protocol, the feature should be removed entirely. Windows Server 2022 does not install SMBv1 by default, but Server 2016 and 2019 do. Remove it. 
 
 Local Account Hardening 
 The built-in Administrator account is a known attack target. Its existence is documented, its SID is predictable, and it cannot be locked out by standard lockout policies. Rename it. Create a named local administrator account with a different name for actual administrative use, and disable or rename the built-in Administrator. 
```
## Rename the built-in Administrator account:
## Computer Management > Local Users and Groups > Users > Administrator > Rename
## Or via command line:
wmic useraccount where name='Administrator' rename 'LOCALADM'
## Disable the renamed built-in account:
## (After creating a different named account for admin access)
Disable-LocalUser -Name "LOCALADM"
```
 Deploy LAPS (Local Administrator Password Solution) for all servers. LAPS ensures each server has a unique, randomly generated local administrator password stored in Active Directory. Without LAPS, the shared local administrator password across all servers means one compromised server exposes the local admin credentials for every server that shares that password. 
 Disable the Guest account. It should already be disabled by default, but verify: 
```
Get-LocalUser "Guest" | Select Name, Enabled
## Should return Enabled: False
```
 
 Windows Firewall Configuration 
 The Windows Firewall should be enabled on all server profiles (Domain, Private, Public). Do not disable the Windows Firewall to resolve application connectivity problems. Identify the specific ports the application needs and add explicit rules for those ports. 
```
## Verify firewall is enabled on all profiles:
Get-NetFirewallProfile | Select Name, Enabled
## Enable if disabled:
Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True
## Example: Allow Genetec Directory port inbound:
New-NetFirewallRule -DisplayName "Genetec Directory TCP 5500" -Direction Inbound -Protocol TCP -LocalPort 5500 -Action Allow -Profile Domain
## Block unnecessary inbound rules from the default ruleset:
## Review Get-NetFirewallRule | Where-Object {$_.Enabled -eq "True" -and $_.Direction -eq "Inbound"}
## Disable rules that are not needed for this server's function
```
 The Windows Firewall default profile is permissive for many inbound connections because Windows assumes the administrator will configure it for the server's role. Review the enabled inbound rules and disable those that are not required. The goal is an explicit allow list, not a default-permit list with a few blocked exceptions. 
 
 Services Audit 
 Disable services that are not needed for the server's function. Unnecessary services are attack surface and resource consumption. The specific services to disable depend on the server's role, but common candidates on dedicated security application servers: 
```
## Services to evaluate for disabling on dedicated security application servers:
## (Verify compatibility with the specific application before disabling)
$services_to_disable = @(
 "Fax", # Fax service
 "XblGameSave", # Xbox Game Save
 "XboxNetApiSvc", # Xbox Live Networking
 "WinRM", # Windows Remote Management (if not using WinRM)
 "RemoteRegistry", # Remote Registry (high-value target - disable if not needed)
 "Spooler" # Print Spooler (if no printing needed - EternalBlue target)
)
foreach ($svc in $services_to_disable) {
 try {
 Stop-Service -Name $svc -Force -ErrorAction SilentlyContinue
 Set-Service -Name $svc -StartupType Disabled -ErrorAction SilentlyContinue
 Write-Host "Disabled: $svc"
 } catch { Write-Host "Not found or error: $svc" }
}
```
 The Print Spooler service deserves specific attention. The PrintNightmare vulnerabilities (CVE-2021-1675, CVE-2021-34527) are critical vulnerabilities in the Print Spooler service that allow privilege escalation and remote code execution. On servers that do not need printing functionality, which includes most VMS and access control servers, disable the Print Spooler entirely. 
 
 Time Synchronization 
 Configure all servers to synchronize time from the domain hierarchy. On domain-joined servers, the Windows Time Service (W32tm) handles this automatically by default. Verify it is configured correctly and monitor for drift. A 5-minute clock difference causes Kerberos authentication failures. A significant clock difference causes event log timestamps to be incorrect, which degrades the value of audit logs for incident response. 
```
## Check current NTP configuration:
w32tm /query /configuration
## Check current time accuracy:
w32tm /query /status
## Force sync:
w32tm /resync /force
```
 On servers that are not domain-joined, configure NTP explicitly: 
```
w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update
net stop w32tm && net start w32tm
```
 
 PowerShell Hardening 
 PowerShell is the primary administrative scripting environment on Windows and is heavily used by attackers for post-exploitation. Hardening PowerShell does not mean disabling it, it means logging its use and restricting what it can do. 
```
## Enable PowerShell script block logging (logs all script execution):
Set-ItemProperty "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name EnableScriptBlockLogging -Value 1
## Enable PowerShell module logging:
Set-ItemProperty "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging" -Name EnableModuleLogging -Value 1
Set-ItemProperty "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging" -Name ModuleNames -Value @("*")
## Set execution policy to RemoteSigned (allows local scripts, requires signing for remote):
Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force
```
 PowerShell Constrained Language Mode restricts what scripts can do and is worth considering for servers where interactive PowerShell use is not needed. It prevents PowerShell from being used as a post-exploitation framework while allowing automated management scripts to continue functioning: 
```
## Enable Constrained Language Mode for all users except administrators:
## (Configure via AppLocker or WDAC policy - see Microsoft documentation)
```
 
 TLS Baseline Settings 
 Enable TLS 1.2 and TLS 1.3 (where supported). Disable TLS 1.0, TLS 1.1, SSL 2.0, and SSL 3.0. Use IISCrypto (free tool) to apply these settings safely with built-in rollback capability. The detailed TLS configuration is covered in the other considerations post in this series, but the core setting applies here as part of the baseline.

================================================================

## Hardening Security Operator Workstations: The Client Side of the Video and Access Control System

URL: https://hans.study/standards-guidance/hardening-security-operator-workstations/
Type: kb
Date: 2026-09-03
Description: Guard desk and control room machines are the most exposed hosts on the security network and the least hardened. Operating system choice, local administrator removal, application allow-listing, removable media, session and lock policy for 24/7 desks, browser and mail, and the decode hardware that keeps operators from working around the controls.

Every hardening guide on this site so far has been about servers, because the servers hold the evidence and the servers are where the vendors' hardening guides point. The workstations are where the people are, and people are where most compromises start. A guard desk machine is on 24 hours a day, logged in, in a lobby, with a USB port facing the public, running a browser someone installed to check the weather. It can see every camera on the site and it can unlock every door. On most sites it has never been hardened at all. 
 This is the baseline for those machines: the Security Desk, Smart Client, ACC Client, and access control operator workstations, and the shared machines in control rooms and at reception. It assumes domain-joined Windows; the reasoning carries to anything else. 
 

 What the workstation is exposed to that the server is not 
 
 Physical access by people who are not staff. A lobby desk faces the public. The USB ports are reachable. The keyboard is reachable when the guard walks a patrol. 
 Shared accounts. Three shifts, one login, one password on a sticky note, because logging off means the video wall goes blank and the last shift did not want to be the one who did that. 
 General-purpose use. Email, browsing, a spreadsheet for the patrol log, a personal phone charging off the front port. Every one of those is an entry point the server does not have. 
 Privilege. An operator account that can unlock doors and export video is a privileged account whether or not it is a Windows administrator, and it sits on the most exposed machine in the building. 
 
 

 The operating system 
 Use Windows 11 Enterprise LTSC, or IoT Enterprise LTSC, on dedicated operator machines. Long-term servicing gives a fixed feature set with security updates only, no consumer applications, no store, no feature updates that reboot a control room machine into a new Start menu on a Tuesday. The client software vendors qualify against it. General-purpose Windows Pro is what most operator machines run because it is what the hardware shipped with, and it brings the whole consumer surface with it. 
 Whatever the edition, the machine is a security appliance from that point on. It is not a general-purpose PC that also runs Security Desk. That framing is the whole hardening posture, and everything below follows from it. 
 

 Accounts and privilege 
 No local administrators except the managed one. Remove the account the integrator created at commissioning, the one called install or the company name, and the one called admin that everyone knows the password to. Rename the built-in Administrator and put it under Windows LAPS so its password is unique per machine, rotated, and retrievable only by the people who should have it. 
 Operators are standard users. The VMS and access control clients run fine as a standard user; where they do not, the vendor has a documented set of permissions to grant, and it is never local administrator. If an integrator says the client needs admin, it needs a particular folder or registry key, and the answer is to grant that. 
 One account per person. The shared operator login is the hardest thing to remove and the most important. The audit trail in the VMS and the access system says who unlocked the door and who exported the video, and if the answer is "the day shift account," the audit trail is worthless. Individual domain accounts, individual VMS accounts mapped from them, and a fast-switch workflow at shift change that operators have been shown and that does not blank the wall. 
 Second factor where the platform allows it. Smart card logon to Windows is the cleanest, and it also solves the shared-account problem, because the card is the account. Where that is not on, the VMS's own multi-factor on login is the next best and it is in most current releases. 
 

 Session lock on a 24-hour desk 
 The standard baseline says lock after fifteen minutes of inactivity. A video wall that locks after fifteen minutes is a video wall that shows nothing during the quietest and most important hours, and the operators will find a way around it, usually a mouse jiggler, which is worse than no policy at all. 
 The design that works: the workstation driving the wall runs a dedicated, minimally privileged display account whose session does not lock and whose only application is the client in a monitoring-only configuration, with no ability to unlock doors, export, or change anything. The operator's own session, on the same machine or on a second one, locks on the normal timer and is where privileged actions happen. The wall stays up; the privilege goes away when the operator does. On platforms with a dedicated wall or kiosk mode, that is what it is for. 
 Document the exception. A locked-down display account on a machine in a physically controlled control room is a defensible compensating control under any of the frameworks. An unlocked general-purpose session on a lobby desk is not, and the auditor will know the difference. 
 

 Application allow-listing 
 An operator workstation runs a known and short list of applications. That is the ideal case for allow-listing, and it is the control that most reduces what a plugged-in USB stick or a downloaded file can do. AppLocker is available on Enterprise and LTSC editions and is enough here; Windows Defender Application Control is stricter and is the right choice on a machine that can unlock doors. 
 Allow the client software from its installed path, signed by the vendor, plus the Windows binaries the machine needs, and deny everything else. Run the policy in audit mode for two weeks first; the log shows what the operators actually run, and there is always something nobody mentioned. The event forwarding subscription for workstations should include the AppLocker log, because a block event on an operator machine is worth knowing about. 
 

 Removable media 
 Block removable storage by Group Policy on every operator machine, read and write. Video export goes to a designated network share with its own access controls and its own audit, not to a USB stick handed to whoever asked. Where an export to physical media is genuinely required, one designated machine in the control room, not the lobby, has write access to a specific encrypted device class, and the export is logged in the VMS. 
 The front USB ports on a lobby desk machine can be disabled in firmware or physically blocked. Both are cheap. The threat is a passer-by with a stick and thirty seconds, and both stop it. 
 

 Browser, mail, and everything else 
 An operator workstation does not have a mail client. It does not have a general-purpose browser. If the operators need either, they need a second machine or a separate, unprivileged session, and the cost of that is small against a phishing email opened on the machine with the door controls. 
 Where a browser is required for a web-based part of the platform, the Web App in Security Center 5.14 for example, restrict it by policy to the platform's URLs and nothing else, disable extensions, and disable downloads. Remove every other application that came with the image. Disable the store, the consumer features, and the assistants. The machine's job is the client, and the fewer other things it can do, the fewer things can go wrong on it. 
 

 The platform baseline still applies 
 The rest of the workstation baseline is the same as the server baseline in the main hardening guide , applied to a client: Windows Firewall on with inbound denied, RDP disabled, SMB signing required, TLS 1.0 and 1.1 off, PowerShell logging on, NTP from the domain, patches monthly with a defined window that the control room knows about, BitLocker with a TPM on every drive. Defender on, with the client cache exclusions the vendor lists and nothing broader. 
 The CIS Windows workstation benchmark at Level 1 is a good starting point and the exceptions you need for the client software are few and documented by the vendor. Apply it by Group Policy to the operator workstation OU, not by hand. 
 

 Decode hardware, because operators route around slow machines 
 This is a hardening item because a slow workstation is a workstation the operators will "fix." They will lower the security settings the integrator can be talked into lowering, they will install the driver from the forum post, and they will keep the old unpatched machine that felt faster. The 64-bit media pipeline in Security Center 5.14 and the current Milestone Smart Client both decode on the GPU when one is present, and a control room machine with sixteen H.265 streams on a wall needs one. 
 Specify the workstation for the decode load, with a supported discrete GPU and the vendor's current driver, and it stops being a reason to weaken anything else. The architecture article covers the client sizing for Security Center. 
 

 The checklist 
 
 LTSC edition, or a documented reason it is not. 
 Built-in Administrator renamed and under LAPS; no other local administrators; commissioning accounts gone. 
 Operators as standard users, one account per person, with the VMS mapping to match. 
 Second factor at Windows or VMS login. 
 Wall driven by a monitoring-only display account; operator sessions lock on the normal timer; exception documented. 
 AppLocker or WDAC enforced after an audit period; block events forwarded. 
 Removable storage blocked; export to a controlled share; front ports disabled or blocked. 
 No mail client; browser restricted to platform URLs or absent. 
 Server baseline applied as a client: firewall, no RDP, SMB signing, TLS, PowerShell logging, NTP, BitLocker, Defender with narrow exclusions. 
 CIS Level 1 workstation benchmark by Group Policy to the operator OU. 
 Decode hardware sized for the wall, so nobody has a reason to work around any of the above. 
 
 The servers hold the evidence. The workstations hold the people, and the doors. Harden them like the exposed, privileged machines they are.

================================================================

## Hardening Windows Server 2016, 2019, and 2022: Hardening with Group Policy

URL: https://hans.study/standards-guidance/hardening-windows-server-2016-2019-2022-environments-group-policy/
Type: kb
Date: 2025-06-03
Description: GPO structure, password policy, Kerberos, NTLM restriction, Advanced Audit Policy, Defender, SMBv1 removal, and LAPS via Group Policy.

// Lifecycle notice, updated 23 August 2026 
 Windows Server 2016 reaches end of support on 12 January 2027. Everything below still applies to a 2016 host, and hardening one you cannot move yet is worth doing. But if that box carries a VMS, an access control server, or anything else that has to keep running, the hardening work and the migration plan belong in the same conversation. Server 2019 runs to 9 January 2029 and Server 2022 to October 2031. The supported routes and a full pre-flight checklist are in the Windows Server migration reference . 
 The good news for anyone facing the migration: Group Policy baselines carry forward. A hardened GPO set built against 2016 transfers to 2019 and 2022 with additions rather than a rebuild, so the work in this chapter is not thrown away when the host moves. 
 

 
 GPO Structure, Domain Hardening Hierarchy 
 
 📁 domain.local Default Domain Policy, password, lockout, Kerberos 
 
 🏛 OU=Domain Controllers Highest precedence Default Domain Controllers Policy + STUDY-DC-Hardening GPO 
 📁 OU=Physical Security STUDY-PhysSec-Servers GPO, Windows Defender, firewall, power plan 
 📋 STUDY-Baseline-Servers GPO Applied here SMBv1 disabled, NLA, audit policy, NTP, LAPS, TLS 
 🚫 Block Inheritance, Isolated Systems OU Legacy systems with documented exceptions, no baseline GPO applied 
 
 
 DC OU GPO always takes highest precedence. Create a separate hardening GPO, never modify the Default Domain Controllers Policy directly. 
 
 Group Policy is one of the most effective tools for hardening Active Directory environments at scale. A single GPO applied to an OU consistently enforces security settings across hundreds of servers simultaneously, without needing to touch each server individually. And when a new server joins the domain and is placed in the correct OU, the policy applies automatically on next Group Policy refresh. 
 The settings below address weaknesses that exist in default Active Directory configurations and have existed across all three server versions. This is not the full Group Policy hardening guide. It is the practical settings that make the most difference in the environments I work in. 
 Never modify the Default Domain Policy or Default Domain Controllers Policy directly. Create new GPOs for hardening settings and link them to the appropriate OUs. If you break something in a custom GPO, you can disable or delete that GPO. If you break something in the Default Domain Policy, recovery is significantly more complex and can affect authentication across the entire domain. 
 
 Domain Controller GPO Structure 
 Create a dedicated GPO for domain controller hardening, for example, DC-Hardening-Baseline , and link it to the Domain Controllers OU with a precedence higher than the Default Domain Controllers Policy (lower link order number = higher precedence in GPO processing). This GPO contains the security settings that should apply to all domain controllers. 
 GPO processing order: Local Policy is applied first, then site GPOs, then domain GPOs, then OU GPOs, with later GPOs winning on conflict. The Domain Controllers OU GPO processes after the domain-level Default Domain Policy, which means your DC-specific hardening GPO can safely override domain-level settings without affecting workstations and member servers. 
 
 Password and Account Policies 
 Password policy applies at the domain level, not the OU level, for domain user accounts. Fine-Grained Password Policies can override this for specific users or groups, but the baseline applies domain-wide through the Default Domain Policy. 
```
# Group Policy path:
# Computer Configuration > Windows Settings > Security Settings > Account Policies
# Recommended minimum settings:
Minimum password length: 14 characters
Password history: 24 passwords
Maximum password age: 90 days (or use NIST's approach - no expiry + MFA + breach detection)
Complexity requirements: Enabled (but length matters more than complexity rules)
# Account lockout policy:
Account lockout threshold: 10 invalid attempts
Account lockout duration: 30 minutes
Reset account lockout counter after: 10 minutes
```
 The NIST SP 800-63B guidance has moved away from mandatory periodic password changes for accounts without evidence of compromise, preferring longer passwords combined with MFA and breach credential monitoring. Many regulated environments still require periodic changes. Apply the policy that your compliance framework requires, but ensure the minimum length requirement is at least 14 characters regardless. 
 
 Kerberos Policy 
 Kerberos is the primary authentication protocol for Active Directory environments. The default Kerberos settings are not optimal for security: 
```
# Computer Configuration > Windows Settings > Security Settings
# > Account Policies > Kerberos Policy
Maximum tolerance for computer clock synchronization: 5 minutes
Maximum lifetime for service ticket: 600 minutes (10 hours)
Maximum lifetime for user ticket: 10 hours
Maximum lifetime for user ticket renewal: 7 days
```
 The clock synchronization tolerance (5 minutes) is the Kerberos ticket validity window. Keep this at 5 minutes and ensure all servers synchronize time correctly. A tighter tolerance (1-2 minutes) reduces the window for ticket replay attacks but requires reliable time synchronization across all systems, if any server drifts, authentication failures follow. 
 
 Restrict NTLM Authentication 
 NTLM is the legacy authentication protocol that Kerberos replaced in Active Directory environments. In a properly configured AD environment, most authentication should use Kerberos. NTLM is still used in specific scenarios (systems accessing resources by IP address instead of hostname, some legacy applications), but it should be restricted rather than allowed by default everywhere. 
```
# GPO: Computer Configuration > Windows Settings > Security Settings
# > Local Policies > Security Options
# Restrict NTLM on domain controllers:
"Network security: Restrict NTLM: NTLM authentication in this domain"
= Deny for domain accounts to domain servers
# Audit NTLM usage before restricting (identify what uses NTLM):
"Network security: Restrict NTLM: Audit NTLM authentication in this domain"
= Enable auditing for domain accounts
```
 Before restricting NTLM, enable NTLM auditing for a period (2-4 weeks) and review the event log to identify what is still using NTLM authentication. Systems accessing servers by IP address, NAS devices, some applications, and printers are common sources. Address those dependencies before implementing restrictions, or you will break things unexpectedly. 
 At minimum, disable NTLMv1 and LM authentication entirely. These are the weakest variants of NTLM and should not be in use anywhere: 
```
# Security Options:
"Network security: LAN Manager authentication level"
= Send NTLMv2 response only. Refuse LM and NTLM
```
 
 Audit Policy via Group Policy 
 Advanced Audit Policy Configuration provides significantly more granularity than basic audit policies and should be used in all Windows Server 2016 and later environments. Basic audit policies have coarse settings. Advanced Audit Policy lets you specify exactly which events are logged within each category. 
```
# GPO: Computer Configuration > Windows Settings > Security Settings
# > Advanced Audit Policy Configuration > Audit Policies
# Account logon:
Audit Credential Validation: Success, Failure
Audit Kerberos Authentication Service: Success, Failure
Audit Kerberos Service Ticket Operations: Success
# Account management:
Audit Computer Account Management: Success, Failure
Audit Security Group Management: Success, Failure
Audit User Account Management: Success, Failure
# Logon/Logoff:
Audit Logon: Success, Failure
Audit Logoff: Success
Audit Special Logon: Success
# Object access (apply where needed):
Audit File System: Failure (Success generates high volume)
Audit SAM: Failure
# Policy change:
Audit Audit Policy Change: Success
Audit Authentication Policy Change: Success
# Privilege use:
Audit Sensitive Privilege Use: Success, Failure
# System:
Audit Security State Change: Success
Audit System Integrity: Success, Failure
```
 On domain controllers specifically, enable these through the DC-specific GPO to ensure DC audit settings take precedence over domain-level settings. Domain controller audit events are particularly important because DCs are the authentication and authorization hub for the entire domain. 
 
 Windows Defender via Group Policy 
 Manage Windows Defender centrally through Group Policy rather than configuring it manually on each server. GPO-managed Defender settings survive Windows Updates and cannot be accidentally disabled by local administrators. 
```
# GPO: Computer Configuration > Administrative Templates
# > Windows Components > Microsoft Defender Antivirus
Key settings:
"Turn off Microsoft Defender Antivirus" = Disabled (ensures Defender stays enabled)
"Configure behavior monitoring" = Enabled
# Exclusions for Genetec environments:
Computer Configuration > Admin Templates > Windows Components
> Microsoft Defender Antivirus > Exclusions
"Path Exclusions", add Genetec installation and archive directories
"Process Exclusions", add Genetec service processes
```
 
 SMBv1 Disable via Group Policy 
 Disabling SMBv1 through Group Policy ensures it cannot be re-enabled manually and applies to all servers in the OU consistently: 
```
# GPO: Computer Configuration > Preferences > Windows Settings > Registry
# Create a new Registry item:
Key path: SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value name: SMB1
Value type: REG_DWORD
Value data: 0
```
 This is more reliable than applying it through PowerShell per-server because it reapplies with every Group Policy refresh. A server that has SMBv1 re-enabled for a legacy application will have it disabled again on the next GP refresh cycle (every 90 minutes by default), making it impossible to accidentally leave SMBv1 enabled long-term. 
 
 LAPS via Group Policy 
 Windows LAPS (available on Server 2022 and through Windows Update for earlier versions) is configured entirely through Group Policy. Once the LAPS policy is enabled, the Windows LAPS agent handles password generation and storage in Active Directory automatically. 
```
# GPO: Computer Configuration > Administrative Templates > System > LAPS
"Configure password backup directory" = Active Directory
"Password Settings":
 - Password complexity: Large letters, small letters, numbers, specials
 - Password length: 20 characters minimum
 - Password age: 30 days
"Do not allow password expiration time longer than required by policy" = Enabled
```
 After deploying the LAPS policy, the local administrator password on each server is unique, randomly generated, and stored in AD. Retrieve it using the LAPS PowerShell module or the LAPS UI tool. The password is automatically rotated on the configured schedule.

================================================================

## Hardening Windows Server 2016, 2019, and 2022: Other Considerations

URL: https://hans.study/standards-guidance/hardening-windows-server-2016-2019-2022-guide/
Type: kb
Date: 2025-03-18
Description: TLS 1.2 enforcement, legacy exceptions, Remote Desktop hardening, SMB signing, LAPS, and certificate management for Windows Server.

// Lifecycle notice, updated 23 August 2026 
 Windows Server 2016 reaches end of support on 12 January 2027. Everything below still applies to a 2016 host, and hardening one you cannot move yet is worth doing. But if that box carries a VMS, an access control server, or anything else that has to keep running, the hardening work and the migration plan belong in the same conversation. Server 2019 runs to 9 January 2029 and Server 2022 to October 2031. The supported routes and a full pre-flight checklist are in the Windows Server migration reference . 
 On a large site the migration is not a weekend. Recording and management servers have to move in the right order, cameras have to re-trust the new host, archives have to survive the cut, and licences usually need reactivating after a hardware change. Start the inventory now rather than in the fall. 
 

 
 Protocol Security Configuration Status 
 
 ✕ SSL 2.0 / SSL 3.0 Disabled, deprecated, broken 
 ✕ TLS 1.0 Disabled, disable via registry 
 ✕ TLS 1.1 Disabled, disable via registry 
 ✓ TLS 1.2 Enabled, minimum required 
 ✓ TLS 1.3 Enabled, preferred where supported 
 ⚠ Legacy exceptions Document and isolate, review annually 
 
 Use IISCrypto (free tool) to configure TLS settings safely with rollback capability. 
 
 This post covers the additional hardening considerations for Windows Server 2016, 2019, and 2022 environments that fall outside the baseline configuration covered in the getting started post. If you have not read that post, start there. The steps here build on the foundation it establishes. 
 
 TLS 1.2 as the Minimum Standard 
 TLS 1.0 and TLS 1.1 should be disabled on all production Windows Server environments. Both are deprecated protocols with known vulnerabilities, BEAST, POODLE, and related attacks have been well-documented for years. Current guidance from NIST, the Canadian Centre for Cyber Security, and most enterprise security frameworks requires TLS 1.2 as the minimum, with TLS 1.3 preferred where all communicating systems support it. 
 On Windows Server 2016 and 2019, TLS 1.0 and 1.1 are still enabled by default. On Windows Server 2022, TLS 1.0 and 1.1 are disabled by default, but verify this in your specific deployment, server builds can vary. 
 The safest way to configure TLS on Windows Server is using IISCrypto, a free tool from Nartac Software. It provides a GUI for managing Schannel settings with a template-based approach and the ability to back out changes if something breaks. The equivalent can be done directly via registry, but IISCrypto reduces the risk of errors: 
```
# Registry locations for TLS protocol control (manual approach):
# HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
# To disable TLS 1.0 (Server side):
[HKLM\...\Protocols\TLS 1.0\Server]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
# To disable TLS 1.0 (Client side):
[HKLM\...\Protocols\TLS 1.0\Client]
"Enabled"=dword:00000000
"DisabledByDefault"=dword:00000001
# Repeat for TLS 1.1 at the same paths
```
 After changing TLS settings, restart the server. Changes to Schannel settings do not take effect without a restart. 
 
 Legacy Application Exceptions 
 Some legacy applications, particularly older security system management platforms, still require TLS 1.0 for their own components or for communication with supported hardware. The existence of a legacy dependency is not justification for leaving the protocol enabled on the entire server. It is justification for a specific, documented exception with a plan to address it. 
 The approach to legacy TLS dependencies: 
 Identify and document the specific systems. Which application requires TLS 1.0 or 1.1? What does it communicate with? What hardware or platforms on the other end impose the limitation? Document this explicitly. 
 Isolate where possible. If the legacy platform can be moved to a dedicated server that runs only that application and its dependencies, the TLS exception can be scoped to that server rather than applied to the entire environment. The primary domain controllers and critical servers can be hardened to TLS 1.2 minimum while the legacy system runs in isolation with compensating controls. 
 Plan a path forward. Legacy TLS dependencies usually exist because hardware has not been updated or software has not been upgraded. Document the reason and a timeline for remediation. "We still need TLS 1.0 because the X system is on version Y which does not support TLS 1.2" is an acceptable interim position with a plan. "We always leave TLS 1.0 enabled because it might break something" is not. 
 Apply compensating controls. If a server must run TLS 1.0 for a specific legacy system, apply additional controls: restrict the server's inbound connections to known IP addresses, ensure TLS 1.2 is still enabled and preferred, monitor the server more closely for anomalies, and increase the logging verbosity on Schannel events. 
 
 Remote Desktop Service Hardening 
 Remote Desktop is a common administrative access method for Windows servers. Default RDP settings leave several hardening items unaddressed. 
 Network Level Authentication (NLA). NLA requires the connecting user to authenticate before the Remote Desktop session is established. Without NLA, the login screen is rendered before authentication, which allows unauthenticated users to reach the RDP session login and is the attack surface for credential stuffing and brute force against the RDP login screen. NLA should be enabled on all servers and enforced through Group Policy. 
```
# GPO Setting: Computer Configuration > Administrative Templates
# > Windows Components > Remote Desktop Services > Remote Desktop Session Host
# > Security > Require user authentication for remote connections by using NLA
# Set to: Enabled
```
 RDP port and access restriction. The default RDP port (3389) should not be accessible from the internet. Remote administrative access should go through a VPN first. If RDP is accessible from the internal network, restrict access to specific management IP addresses using the Windows Firewall or the host-based firewall policy. 
 RDP encryption level. Set the RDP encryption level to High through Group Policy. This ensures all data transmitted over the RDP session is encrypted with 128-bit encryption. 
```
# GPO: Computer Configuration > Admin Templates > Windows Components
# > Remote Desktop Services > RDS Session Host > Security
# "Set client connection encryption level" = High Level
```
 Idle session timeout. Configure timeouts for disconnected and idle RDP sessions. An authenticated session that is left idle indefinitely is an open door if the client machine is compromised. 
 
 SMB Hardening 
 SMBv1 is a 30-year-old protocol with critical vulnerabilities including EternalBlue, which was used in the WannaCry and NotPetya ransomware attacks. SMBv1 should be disabled on all modern Windows Server deployments without exception. There is no valid business reason to have it enabled on any server running Windows Server 2016 or later. 
```
# Disable SMBv1:
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
# Verify:
Get-SmbServerConfiguration | Select EnableSMB1Protocol
```
 SMB signing should be required on all servers, not just domain controllers. SMB signing prevents man-in-the-middle attacks on SMB traffic. Require SMB signing through Group Policy on all servers in the environment, not just those that are likely targets. 
 
 LAPS for Local Administrator Accounts 
 Local Administrator Password Solution (LAPS) manages unique, randomly generated passwords for the local administrator account on each server. Without LAPS, organizations typically either use the same local administrator password across all servers (which means one compromised server exposes all servers) or disable the local administrator account (which removes a recovery option if the domain is unavailable). 
 LAPS stores the password in a confidential Active Directory attribute that is readable only by authorized accounts and computers. Passwords rotate automatically on a configurable schedule. For Windows Server 2022 and Windows 11 systems, Windows LAPS is built into the OS and replaces the legacy LAPS MSI. 
```
# Deploy Windows LAPS via Group Policy (Server 2022 / Win11):
# Computer Configuration > Administrative Templates > System > LAPS
# Enable the policy and configure password settings
# For legacy LAPS on Server 2016/2019:
# Deploy LAPS.msi via Group Policy Software Installation
# Configure via LAPS GPO ADMX templates after installation
```
 
 Certificate Management 
 Servers using TLS for services need valid certificates. Self-signed certificates generate warnings for users and administrators and cannot be easily validated through a trust chain. For internal services, an internal Certificate Authority is preferable to self-signed certificates because it allows the organization to maintain a trusted root without purchasing commercial certificates for every service. 
 Windows Server includes Active Directory Certificate Services (ADCS) for deploying an internal CA. For smaller environments without a dedicated PKI infrastructure, a standalone CA on a dedicated server is a reasonable approach. Configure auto-enrollment through Group Policy for certificate distribution to domain-joined servers. 
 Monitor certificate expiration dates. An expired certificate on a critical service causes immediate, visible failures and generates unnecessary urgency. A certificate inventory with expiration dates and a renewal schedule eliminates this class of avoidable incidents.

================================================================

## Hardening Windows Server 2016, 2019, and 2022: Audit Logging

URL: https://hans.study/standards-guidance/hardening-windows-server-2016-2022-environments-audit-logging/
Type: kb
Date: 2025-07-15
Description: Advanced Audit Policy, domain controller GPO, event log sizing, Windows Event Forwarding, Sysmon, key event IDs, and log retention for Windows Server.

// Lifecycle notice, updated 23 August 2026 
 Windows Server 2016 reaches end of support on 12 January 2027. Everything below still applies to a 2016 host, and hardening one you cannot move yet is worth doing. But if that box carries a VMS, an access control server, or anything else that has to keep running, the hardening work and the migration plan belong in the same conversation. Server 2019 runs to 9 January 2029 and Server 2022 to October 2031. The supported routes and a full pre-flight checklist are in the Windows Server migration reference . 
 Plan the log estate before the migration, not after. Audit history is the first thing lost in a server move, and it is the thing you will want if an incident review reaches back across the cut. Forward to a collector that outlives the host. 
 

 
 Audit Log Flow, Sources to Centralized Collection 
 
 
 Domain Controller Kerberos · Account Events 
 VMS Server Application Events 
 AD Server Directory Events 
 Workstations Logon Events 
 
 Windows Event Forwarding (WEF) or Syslog 
 ↓ 
 
 
 Centralized Log Collector SIEM · Syslog Server · WEF Collector 
 
 
 Logs that only exist on the compromised system are useless after a breach. Get them off the host. 
 
 Configuring Audit Policies is one of those steps that gets skipped during deployment because it does not make the system work better in any visible way. It only matters when something goes wrong. And when something goes wrong, the difference between "we can reconstruct what happened" and "we have no idea what happened" is entirely determined by what was logged before the event. 
 All three Windows Server versions, 2016, 2019, 2022, support Advanced Audit Policy Configuration, which should be used instead of the basic audit policies under Local Policies. Advanced policies provide significantly more granularity. The basic audit policies are coarse settings that either audit an entire category or none of it. Advanced Audit Policy lets you specify which subcategories within each category are audited, and whether success events, failure events, or both are logged. 
 
 Advanced Audit Policy vs Basic Audit Policy 
 The basic audit policies are in: Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy . 
 The Advanced Audit Policy Configuration is in: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies . 
 Use Advanced Audit Policy. The basic policies are a legacy interface that predates granular auditing. On a domain, configure Advanced Audit Policy through Group Policy. On a standalone server, configure it through Local Group Policy. 
 Do not mix basic audit policies with Advanced Audit Policy on the same system. When Advanced Audit Policy settings exist, they take precedence over basic audit policy settings. Having both configured creates confusion about which settings are actually in effect. If you are transitioning from basic to advanced, clear the basic audit policy settings when enabling the advanced ones. 
 
 Domain Controller Audit Policy 
 Create a new GPO for domain controller audit policy and give it precedence over the Default Domain Controller Policy. Link it to the Domain Controllers OU. The Default Domain Controllers Policy has basic audit settings that are insufficient for security monitoring. Your new GPO with Advanced Audit Policy settings will override them. 
```
## The GPO should configure these audit subcategories at minimum:
## Account Logon:
Audit Credential Validation: Success and Failure
Audit Kerberos Authentication: Success and Failure
Audit Kerberos Service Ticket: Success and Failure
Audit Other Account Logon Events: Success and Failure
## Account Management:
Audit Computer Account Management: Success and Failure
Audit Other Account Mgmt Events: Success and Failure
Audit Security Group Management: Success and Failure
Audit User Account Management: Success and Failure
## Logon/Logoff:
Audit Account Lockout: Success and Failure
Audit Logoff: Success
Audit Logon: Success and Failure
Audit Other Logon/Logoff Events: Success and Failure
Audit Special Logon: Success
## Object Access:
Audit SAM: Failure
Audit File System: Failure (Success is high-volume)
## Policy Change:
Audit Audit Policy Change: Success and Failure
Audit Authentication Policy Change: Success
Audit MPSSVC Rule-Level Policy Change: Success and Failure
## Privilege Use:
Audit Sensitive Privilege Use: Success and Failure
## System:
Audit Security State Change: Success and Failure
Audit Security System Extension: Success and Failure
Audit System Integrity: Success and Failure
```
 These settings generate a significant volume of events on a domain controller. Plan the event log sizing accordingly. The Security event log on a domain controller should be configured to a minimum of 512 MB to avoid log wrapping that overwrites old events before they can be collected. 
 
 Event Log Sizing and Retention 
 The default event log sizes on Windows Server are too small for environments with meaningful audit logging enabled. Increase them: 
```
## Configure via Group Policy:
## Computer Configuration > Administrative Templates > Windows Components
## > Event Log Service > [Security|Application|System]
## Security log: 1 GB minimum on domain controllers, 256 MB on member servers
## Application log: 256 MB
## System log: 256 MB
## Via PowerShell (run as administrator):
$logs = @("Security", "Application", "System")
foreach ($log in $logs) {
 $wevtutil = "wevtutil"
 if ($log -eq "Security") {
 & $wevtutil sl $log /ms:1073741824 # 1 GB for Security log
 } else {
 & $wevtutil sl $log /ms:268435456 # 256 MB for others
 }
}
```
 Log retention policy should be set to "Do not overwrite events (Clear logs manually)" or "Archive the log when full, do not overwrite events", not "Overwrite events as needed." An overwrite policy means old events are silently deleted when the log fills. For security logs, this can mean critical evidence from an incident is overwritten before anyone knows to look for it. 
 Combine this with a centralized log collection solution so that security events are forwarded off the server and stored in a location the attacker cannot easily access or modify. 
 
 Windows Event Forwarding 
 Windows Event Forwarding (WEF) is a built-in Windows mechanism for collecting events from multiple sources onto a central collector. It requires no third-party software and works with the existing Windows infrastructure. Events from domain controllers, member servers, and workstations can all be forwarded to a single Windows Event Collector (WEC) server. 
```
## On the collector server:
## Enable Windows Remote Management:
winrm quickconfig
## Enable the Windows Event Collector service:
wecutil qc /quiet
## On the source servers:
## Configure via Group Policy:
## Computer Configuration > Administrative Templates > Windows Components
## > Event Forwarding > Configure the server address for WS-Management
## The subscription defines which events to forward and where.
## Create subscriptions on the collector using Event Viewer or wecutil:
```
 The subscription can be configured to forward all security events, or a filtered subset. For environments without a SIEM, forwarding the Security, Application, and System logs from all servers to a WEC collector, and retaining those logs for 90 days, is a reasonable starting configuration that significantly improves incident response capability at no software cost. 
 For environments that have a SIEM or a syslog-based log management solution, a Windows agent (Sysmon, NXLog, or similar) provides more flexible forwarding options and better filtering. The choice of approach depends on the existing infrastructure, but the requirement, getting logs off the source host and into a centralized, tamper-resistant storage location, is the same regardless of the method. 
 
 Sysmon for Enhanced Windows Event Collection 
 Sysmon (System Monitor) is a free Microsoft Sysinternals tool that logs detailed process creation, network connection, and file system events to the Windows Event Log. The events it generates are significantly more useful for security monitoring than the native Windows audit policy events alone. 
```
## Download Sysmon:
## https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
## Install with a configuration file:
sysmon64.exe -accepteula -i sysmon-config.xml
## Community configuration files (good starting points):
## SwiftOnSecurity/sysmon-config (GitHub)
## olafhartong/sysmon-modular (GitHub)
```
 Sysmon event ID 1 (Process Create) logs every process that starts on the system, including the full command line. Event ID 3 (Network Connect) logs every outbound network connection with source and destination. Event ID 7 (Image Load) logs DLL loading. These events are the foundation for detecting lateral movement and post-exploitation activity. 
 Deploy Sysmon via Group Policy Software Installation or a configuration management tool. The configuration file controls what is logged, start with an established community configuration and tune it for your environment based on the noise level and false positive rate. 
 
 Key Event IDs to Monitor 
 These event IDs should be monitored and ideally alerted on in any environment with centralized log collection: 
 
 Event ID Log Description Why It Matters 
 
 4625 Security Failed logon Brute force indicator, high volume from single source is an attack 
 4648 Security Logon with explicit credentials Lateral movement indicator, pass-the-hash, credential reuse 
 4672 Security Special privileges assigned Elevated access, admin logon tracking 
 4720 Security User account created Unauthorized account creation, persistence mechanism 
 4728, 4732 Security Member added to privileged group Privilege escalation, adding to Admins/Domain Admins 
 4740 Security Account locked out Brute force or credential stuffing against a specific account 
 4768, 4769 Security Kerberos TGT/TGS requested Kerberoasting and Pass-the-Ticket detection 
 4776 Security Credential validation Failed NTLM auth, monitor for high volume 
 7045 System New service installed Persistence mechanism, attacker-installed services 
 4104 PowerShell/Operational Script block logged Post-exploitation PowerShell activity 
 
 
 A high volume of Event 4625 (Failed logon) from the same source IP in a short time window is a brute force attack in progress. A single instance of Event 4720 (User account created) at 3 AM on a production server may warrant immediate investigation. The events above are the ones where the context and volume tell you whether there is a problem. 
 
 Log Retention Guidance 
 Retain security logs for a minimum of 90 days in readily searchable storage, and for 1 year in archive storage. This timeframe is driven by two factors: the average attacker dwell time before detection (historically measured in months), and the investigation timeline after an incident is discovered. 
 If an attacker establishes persistence in January and the intrusion is discovered in March, you need logs from January to reconstruct how they got in. If those logs were overwritten in February, you can determine what they did but not how they got in, which means you cannot fully remediate because you do not know every access path they established. 
 The 1-year archive accommodates regulatory requirements in many industries and covers the extended investigation timeline for sophisticated incidents. Store archives in a location that is not directly accessible from the servers being monitored, an attacker who has compromised a server should not be able to delete their own audit trail.

================================================================

## Hardening Windows Server 2025: What Changed From 2022, and What It Breaks on Security Systems

URL: https://hans.study/standards-guidance/hardening-windows-server-2025-what-changed/
Type: kb
Date: 2026-09-01
Description: SMB signing and NTLM blocking on by default, Credential Guard on new installs, LAPS built in, delegated managed service accounts, hotpatching, and the integrations that stop working when you move a VMS or access control host to Server 2025.

Server 2016 leaves support on 12 January 2027, and a good share of the video and access control hosts I see are still on it. The natural move is straight to Server 2025, and the 2016 to 2022 hardening guides on this site still apply almost entirely. What they do not cover is the handful of defaults that changed in 2025, several of which are things those guides told you to turn on by hand. On a general-purpose server that is good news. On a server running a VMS that talks to a ten-year-old NAS over SMB, it is an outage on the first reboot. 
 This page is the delta. Read the older guides for the baseline; read this for what 2025 does differently and what to check before you move a security system onto it. 
 

 The changes that matter, in one table 
 
 
 Change 2022 behaviour 2025 behaviour Risk to security systems 
 
 SMB signing Required on domain controllers only; optional elsewhere Required by default on all SMB connections, client and server High. Archive storage on SMB, older NAS, and some appliances refuse or degrade. 
 NTLM over SMB Allowed Client can block NTLM to remote SMB servers; auditing on by default, blocking available by policy Medium. Non-domain storage targets and workgroup appliances authenticate with NTLM. 
 Credential Guard Off unless enabled On by default on new installs that meet the hardware requirements Medium. Some integrations that store or replay credentials in ways Credential Guard blocks. 
 LAPS Separate download, legacy schema Windows LAPS built in, with Entra and AD support Low. Positive change; needs the schema extension. 
 Service accounts gMSA gMSA plus delegated managed service accounts (dMSA) Low. Opportunity, not a risk. 
 TLS TLS 1.3 available TLS 1.3 preferred; TLS 1.0 and 1.1 disabled by default Medium. Older cameras, panels, and SDK integrations that only speak 1.0 or 1.1. 
 Hotpatching Azure only Available on-premises through Azure Arc, subscription required Low. Useful for hosts that cannot take a monthly reboot. 
 SMB over QUIC Azure Edition only Standard and Datacenter Low. Not something a video host should be exposing. 
 
 
 
 

 SMB signing, required everywhere 
 Every hardening guide for the last decade has said to require SMB signing. Almost nobody did it on member servers because it costs CPU and because something always broke. Server 2025 requires it by default, on outbound connections from the SMB client and on inbound connections to the SMB server, and the things that always broke now break on day one. 
 On a security system, the SMB connections that matter are archive storage and export shares. An Archiver writing to an SMB share on a NAS that does not support signing, or supports it badly, will either fail to connect or write at a fraction of its previous throughput. Some older NAS firmware negotiates signing and then performs so poorly under it that the Archiver falls behind and records gaps. The fix is to update the NAS firmware, move the storage to iSCSI, or as a last resort relax the signing requirement for that host through policy while you plan one of the first two. The storage design article covers why iSCSI is the better answer anyway. 
 Check before the move, not after: 
```
# On the 2022 host today: does the storage target support signing?
Get-SmbConnection | Select-Object ServerName, ShareName, Signed, Dialect

# On a 2025 host: what the client will insist on
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
```
 A Dialect below 3.0 on any connection is a target that will need attention regardless, because SMB1 is not installed on 2025 and SMB2 without signing is exactly what the default now refuses. 
 

 NTLM blocking 
 Server 2025 continues the NTLM deprecation that started in 2024. The SMB client can now be configured to refuse NTLM authentication to remote servers, and while the default is audit rather than block, the CIS and STIG baselines that will follow are going to recommend blocking, and a security team that applies them will do so. 
 What authenticates with NTLM on a security network: any storage target in a workgroup, any appliance that presents SMB but is not domain-joined, any camera or panel that pulls firmware or configuration from a share, and older SDK integrations that connect with a username and password rather than Kerberos. Domain-joined hosts talking to domain-joined hosts with proper SPNs use Kerberos and are unaffected. 
 Run the audit for a month before blocking. The audit events tell you exactly which connections would fail: 
```
# Events for NTLM use by the SMB client (Server 2025)
Get-WinEvent -LogName "Microsoft-Windows-SMBClient/Audit" -MaxEvents 200 |
 Where-Object Id -in 31017, 31018 |
 Select-Object TimeCreated, Message
```
 Every distinct target in that list is a decision: join it to the domain, give it a service principal name so Kerberos works, replace it, or exempt it explicitly and document why. 
 

 Credential Guard on by default 
 Credential Guard isolates domain credentials in a virtualisation-based container so that a compromised kernel cannot read them. On a fresh 2025 install on hardware with UEFI, Secure Boot, and a TPM, it is now on. That is correct, and it should stay on. 
 What it breaks: anything that depends on credential delegation mechanisms Credential Guard disables, most visibly unconstrained Kerberos delegation and older NTLMv1 flows. Security system integrations occasionally lean on these, particularly the ones that were written to make single sign-on work between a VMS and a directory and never updated. The symptom is an integration that authenticated fine on the old host and fails with an access denied on the new one, with nothing else changed. 
 Test the integrations on a 2025 host in the lab with Credential Guard on before the production move. If one fails, the vendor's current SDK almost always has a fix; the wrong answer is to turn Credential Guard off on the production host to accommodate an old plugin. 
 

 Windows LAPS, built in 
 The baseline guides told you to deploy LAPS for the local administrator password. On 2025 it is part of the operating system, it supports both Active Directory and Entra, and it can manage the DSRM password on domain controllers. Extend the schema, set the policy, and the shared local administrator password that every video server on the site had in common stops being a problem. 
 Two things to get right on security hosts. First, the account LAPS manages should be the built-in administrator, renamed, and there should be no other local administrator accounts, including the one the integrator created at commissioning. Second, the password rotation should not be so aggressive that it rotates during a maintenance window someone is in the middle of. Thirty days is fine. 
 

 Delegated managed service accounts 
 Group managed service accounts have been the right way to run a service without a password since Server 2012, and most VMS and access control services are still running as a named domain user with a password that expires in ninety days and takes the service down when it does. Server 2025 adds delegated managed service accounts, which can be linked to an existing service account and take over its permissions, which makes the migration from a password-bearing account much less disruptive. 
 Whether the platform supports it is the question. Genetec, Milestone, and most access control servers will run their services as a gMSA, and the vendor documentation for each says how. The dMSA path is the same from the platform's point of view. Plan the service account migration as part of the host move, because it is far easier to do on a fresh install than to retrofit. 
 

 TLS 1.0 and 1.1 gone by default 
 Server 2025 disables TLS 1.0 and 1.1 out of the box. The baseline guides told you to do this by registry on 2016 through 2022, and on the systems where it was done, the things that broke are known. On the systems where it was not, the move to 2025 is where they break. 
 The usual suspects: cameras on old firmware whose HTTPS only offers 1.0, access control panels with embedded web servers from the previous decade, and SDK integrations compiled against an old .NET framework that never enabled 1.2. The camera and panel problem is a firmware update or a replacement. The SDK problem is a vendor conversation. Neither is a reason to re-enable TLS 1.0 on a host that holds video evidence. 
 The TLS section of the getting-started guide has the registry keys and the .NET strong-crypto settings that apply unchanged on 2025. 
 

 Is the platform supported on it yet 
 None of this matters if the VMS or access control vendor has not qualified Server 2025 for the release you run. Check the vendor's supported platform matrix for your exact release before planning the move, and plan for the possibility that the answer is "supported from the next release," which turns an OS move into a platform upgrade with an OS move underneath it. For Genetec, the migration paths page covers the version rules that decide what order the two moves have to happen in. 
 

 Pre-move checklist 
 
 Vendor platform matrix confirms 2025 for the release in production. 
 Every SMB target inventoried with its dialect and signing support. Archive storage on SMB has a plan: firmware, iSCSI, or a documented exemption. 
 NTLM audit run for a month on the existing host; every target on the list has a decision. 
 Integrations tested on a 2025 lab host with Credential Guard on. 
 Cameras, panels, and SDK integrations checked for TLS 1.2 support. 
 LAPS schema extended; policy ready; commissioning accounts removed. 
 Service accounts moving to gMSA or dMSA as part of the build. 
 The rest of the baseline guide applied, because 2025 changed defaults, not the need for a baseline. 
 
 The short version: Server 2025 turns on several things you were supposed to have turned on already. If you did, the move is uneventful. If you did not, the move is where you find out what was depending on them being off.

================================================================

## IP Addressing for Security Integrators: What You Actually Need to Know

URL: https://hans.study/standards-guidance/ip-addressing-for-security-integrators/
Type: kb
Date: 2024-11-12
Description: The IP addressing conversation comes up on every deployment. Not always at the right time. I have walked into more than a few projects mid-installation whe...

The IP addressing conversation comes up on every deployment. Not always at the right time. I have walked into more than a few projects mid-installation where nobody had planned the addressing scheme and the team was handing out addresses verbally as devices came out of boxes. The cabling is done, the cameras are going up, and someone is keeping track of what went where in a sticky note on the switch cabinet. It works until it does not. 

 This is not a certification study guide. It is a practical reference for integrators who need to plan, document, and commission physical security networks. If the concepts feel familiar but your projects end up with address conflicts, overlapping subnets, or documentation that nobody can read a year later, this should help close those gaps. 

 

 Why the Physical Layer Starts at the IP Layer 

 Every device on a security network needs an address. Cameras, access control panels, door controllers, intercoms, recording servers, management workstations, switches, firewalls. All of it. The addresses need to be planned before the installation starts, not sorted out when you are already on site. 

 An unplanned addressing scheme creates problems that compound. Conflicts when devices come online. Subnets too small to accommodate the final device count. Ranges that overlap when you segment into VLANs later. Cameras that need to be re-addressed mid-installation because someone used the range you needed for something else. And a year down the road, when something breaks or needs to change, nobody knows what is at which address without tracing physical cables. 

 None of that is necessary. The planning takes maybe an hour on a mid-sized project. It saves considerably more than that when something goes wrong. 

 

 The Three Private Address Ranges 

 IP addresses used on internal networks come from three ranges defined in RFC 1918. They are called private address ranges because they are not routed on the public internet. You can use any of them on an internal network without conflict with anything outside your building. 

 
 
 
 Range 
 From 
 To 
 CIDR 
 Addresses 
 
 
 
 
 Class A 
 10.0.0.0 
 10.255.255.255 
 /8 
 16,777,216 
 
 
 Class B 
 172.16.0.0 
 172.31.255.255 
 /12 
 1,048,576 
 
 
 Class C 
 192.168.0.0 
 192.168.255.255 
 /16 
 65,536 
 
 
 

 For any physical security deployment with more than a handful of devices, use the 10.0.0.0/8 range . It gives you the most flexibility. You can create hundreds of distinct subnets without running out of space, which matters as soon as you start segmenting into VLANs for cameras, access control, management, and systems. 

 The 192.168.x.x range is fine for home networks and small single-VLAN deployments. On anything with multiple segments, it becomes a constraint. The 172.16.x range is valid but frequently causes confusion. Many people do not immediately recognize it as a private range, which creates trouble when you are walking through routing with someone who does not know what they are looking at. 

 Use 10.x.x.x. It is the right answer for this environment. 

 

 Subnet Masks and CIDR: The Practical Explanation 

 A subnet mask tells the network equipment which portion of an IP address identifies the network and which portion identifies the individual device. That is the whole job. Nothing more complicated than that. 

 CIDR notation counts the number of bits used for the network portion. The address 10.42.67.47/24 means 24 bits are the network, 8 bits identify the host. The breakdown looks like this: 

 
 
 IP Address Anatomy, 10.42.67.47/24 

 
 10 
 . 
 1 
 . 
 101 
 . 
 47 
 /24 
 

 
 ← 24 bits, Network Portion 
 8 bits, Host → 
 
 
 Identifies the network segment 
 Identifies the device 
 

 
 
 Subnet Mask (decimal) 
 255.255.255 . 0 
 
 
 Network Address 
 10.1.101 . 0 
 
 
 Broadcast Address 
 10.1.101 . 255 
 
 
 Usable Range 
 10.1.101 . 1, 254 (254 hosts) 
 
 
 
 

 The /24 mask gives you 254 usable addresses in a subnet. For most security VLANs on a single site, that is the right size. Large enough to accommodate cameras, servers, spares, and future growth. Simple enough to remember and document. 

 A /25 gives you two ranges of 126 hosts each. A /26 gives you four ranges of 62 hosts each. You can go smaller if you need to, a /29 gives you only 6 usable addresses and is appropriate for a management VLAN where only switches and infrastructure devices will live. Going smaller than /24 for production device VLANs is usually not worth the complexity on a physical security deployment. 

 One thing that catches people: the first and last address in every subnet are reserved. .0 is the network address. .255 is the broadcast address. Neither can be assigned to a device. Your 254 usable addresses run from .1 through .254. 

 

 An Addressing Scheme That Actually Holds Together 

 Here is the scheme I use on most mid-sized security deployments. It is not magic. It is just consistent. 

 Format: 10.<site>.<vlan>.<device> 

 The site octet is a number from 1 to 254. Each physical site gets its own number. If you only have one site, use 1. If you have ten sites, number them. The VLAN octet matches the VLAN ID, which ties your IP scheme directly to your network segmentation plan. The device octet is the individual address. 

 
 
 10.x.99.254 
 → 
 VLAN 99 
 Management (switches, infrastructure) 
 
 
 10.x.100.11+ 
 → 
 VLAN 100 
 Systems (VMS servers, workstations) 
 
 
 10.x.101.xx 
 → 
 VLAN 101 
 CCTV (cameras) 
 
 
 10.x.102.xx 
 → 
 VLAN 102 
 Access Control (panels, controllers) 
 
 
 10.2.101.xx 
 → 
 VLAN 101 
 Site 2, Camera VLAN 
 
 

 The readability of this scheme is the point. When you see 10.3.101.47 in a switch log, you know it is a camera at site 3 without looking anything up. When a device shows up in a Wireshark capture or a Genetec health monitor, the address tells you exactly what it is and where it lives. 

 Within each /24, reserve addresses by function: 
 
 .254 , Default gateway (the firewall or L3 switch interface for this VLAN) 
 .253 descending , network infrastructure (switch SVIs, secondary switches, management interfaces) 
 .11 through .50 , Servers, recording systems, static infrastructure 
 .50 through .99 , Reserved for future growth 
 .100 through .254 , Cameras, panels, field devices 
 

 

 Static vs DHCP: The Security Network Position 

 Use static addresses for everything on a physical security network. 

 DHCP is convenient for user workstations where addresses change and the specific address does not matter. On a security network, you want to know exactly what is at every address. When a camera drops off at 3 AM and you are troubleshooting in the morning, you should be able to look up the address in your documentation and know which camera it is, where it is physically installed, and which switch port it connects to. 

 DHCP on a camera network means you might see a camera stop recording and not be able to cross-reference the device in your NVR with anything in your switch logs. The lease expired, the address changed, your documentation is now wrong, and you are tracing cables to figure out what is what. 

 DHCP reservations are an acceptable middle ground if you are forced to use a DHCP server. A reservation ties a specific MAC address to a specific IP address. The device always gets the same address, and the DHCP server is the management point. The downside is that reservations take about the same time to set up as static addressing on a large deployment, and they introduce a dependency on the DHCP server, if it is unavailable, newly connected or rebooted devices may not get addresses. 

 
 The documentation is as important as the address. A spreadsheet with every device, its address, its MAC address, its physical location, and its switch port assignment is not optional. It is how you service the system in two years when nobody on the current team is around to explain it. 
 

 

 Gateway Addressing 

 The gateway is the device that routes traffic between subnets, usually a firewall or a Layer 3 switch. Pick a convention for the gateway address and use it consistently across all subnets. 

 I use .254 for the gateway on every subnet. So: 
 
 10.1.99.254 , Gateway for the management VLAN 
 10.1.100.254 , Gateway for the systems VLAN 
 10.1.101.254 , Gateway for the camera VLAN 
 10.1.102.254 , Gateway for the access control VLAN 
 

 Some engineers prefer .1. Either works. The important thing is that it is the same on every subnet so you are not looking it up every time you configure a device. 

 

 Common Mistakes 

 Using 192.168.1.x for everything. Works fine until you need a second VLAN. Then you either create confusing address ranges or you are re-addressing the whole site. 

 Not planning for growth. The client has 40 cameras today. The contract mentions potential future phases. A /24 gives you room. A /27 with 30 addresses does not. 

 Assigning .254 to a device. That is your gateway address. Reserve it. A camera at .254 and the Layer 3 switch interface trying to own .254 at the same time is a conflict you will troubleshoot at the worst possible moment. 

 Inconsistent documentation. The IP scheme is only useful if it is documented accurately and updated when things change. A spreadsheet that was accurate at commissioning and has not been touched since is a liability, not an asset. Make documentation part of the commissioning process, not an afterthought. 

 Segmenting the network without coordinating the IP scheme. Your addressing and your VLAN design should be planned together. If you know you will have four VLANs, allocate four subnets from the start. Retrofitting an addressing scheme after the VLANs are already up is avoidable extra work. 

 

 Where This Leads 

 IP addressing is the foundation. The next layer is segmentation, deciding which devices go on which network and why. A well-planned address scheme makes the segmentation work easier, because the addressing tells you at a glance what is what. The next post covers VLAN segmentation specifically: what it does, how to design a scheme for a physical security deployment, and how to explain it to a client who does not understand why they need it. 

 One consideration that comes up on larger camera deployments: multicast. When multiple operator workstations are watching the same live streams, multicast sends the stream once from the Archiver and replicates it at the network layer rather than sending individual unicast streams to each client. It reduces bandwidth significantly at scale but requires proper IGMP snooping and PIM configuration on the switching infrastructure. Worth planning for if your design includes more than a handful of simultaneous viewer seats. If you have questions or want to talk through an addressing scheme for a specific project, reach out through the site.

================================================================

## Juniper EX Series Base Configuration for CCTV and Security Networks

URL: https://hans.study/standards-guidance/juniper-ex-base-configuration-for-cctv-and-security-networks/
Type: kb
Date: 2026-04-08
Description: Juniper EX series (Junos OS) configuration template: VLANs, SSH, AAA, Virtual Chassis, port security, BPDU guard, aggregated Ethernet, QoS, and syslog for physical security networks.

Juniper EX2300-24T, Front Panel and VLAN Port Allocation 
 

 
 
 CCTV · VLAN 101 (1-12) 
 Access · VLAN 102 (13-16) 
 Systems · VLAN 100 (17-22) 
 Unused · VLAN 666 (23-24) 
 LAG · xe-0/2/0-xe-0/2/1 
 
 

 Over the last 15+ years, when I get brought in to look at a CCTV or security network, it is almost a guarantee that the network devices are not configured correctly. Or just not configured at all. 

 Switches running factory defaults. No VLANs. No port security. Default credentials on everything. No redundancy between switches. Management interfaces sitting wide open on the same network as cameras. These are systems protecting physical assets, running on networks that nobody thought to protect. 

 Over the years I have built a set of configuration templates that provide initial setup, baseline hardening, and performance tuning for security network switches. This is one of them. It is focused on the Juniper EX series running Junos OS and covers VLAN segmentation, SSH access, AAA, port security, QoS, trunk hardening, and inter-switch connectivity. 

 This is not a one-size-fits-all configuration. Every environment is different. Review each section against your requirements and test before deploying into production. 

 A note on Junos syntax. Junos uses a hierarchical configuration model. All commands below are entered in configuration mode ( configure ) using set syntax. Changes take effect only after commit . Use commit confirmed 5 when making changes that affect remote access. This automatically rolls back after 5 minutes unless you confirm, protecting you from locking yourself out. 

 Change every placeholder before deploying. The double-hash placeholder ( ## ) appears throughout this template where site-specific values belong. Deploying a configuration with placeholder values intact is a misconfiguration waiting to cause problems. 

 

 Initial System Configuration 

```
set system host-name SWITCH_NAME
set system root-authentication encrypted-password "##CHANGEME##"
set system login user netadmin class super-user
set system login user netadmin authentication encrypted-password "##CHANGEME##"
```

 system host-name sets the device identity. Use a consistent naming convention across your environment. This matters for logging, monitoring, and troubleshooting. When you are looking at syslog entries from 40 switches, meaningful hostnames save time. 

 system root-authentication sets the root account password. In Junos, root is a privileged account used for emergency access. The password is stored as a hashed value. Never leave root without a password on a production device. 

 Junos stores all local passwords as hashed values in the configuration. Passwords are never stored in plain text, which is the correct behavior. Use request system set-encryption-keys to generate a proper hashed value for the encrypted-password field. 

 The login user section creates a named administrative account in the super-user class. Create individual named accounts rather than sharing credentials. Every person who manages the switch should have their own account. Shared credentials make audit trails meaningless. 

 

 VLAN Configuration and Segmentation 

```
set vlans DEFAULT vlan-id 1
set vlans MANAGEMENT vlan-id 99
set vlans SYSTEMS vlan-id 100
set vlans CCTV vlan-id 101
set vlans ACCESS_CONTROL vlan-id 102
set vlans BLACKHOLE vlan-id 666
```

 The VLAN IDs and names below are an example, not a standard. Use whatever VLAN scheme the customer already runs, or pick numbers appropriate to the deployment. The principle is what matters: one VLAN per device class, a dedicated management VLAN, a blackhole VLAN for unused ports, and consistency across every site in the same environment. 

 VLAN segmentation is one of the most important things you can do on a security network. By default, every port on a new switch sits in VLAN 1. Everything can talk to everything. That is not acceptable in a security environment. 

 VLAN 1 (DEFAULT): Keep it but do not use it. Default VLAN has well-known behaviors and is the target of certain VLAN-hopping attacks. Do not put production traffic on VLAN 1. 

 VLAN 99 (MANAGEMENT): Dedicated to switch management traffic. Management interfaces should be isolated from camera traffic, user traffic, and everything else. This is where your L3 interfaces for device management will live. 

 VLAN 100 (SYSTEMS): For servers, recording platforms, workstations, and other infrastructure that supports the security systems. 

 VLAN 101 (CCTV): Dedicated to cameras. Camera traffic is bandwidth-heavy and predictable. Isolating it simplifies QoS, troubleshooting, and security policy. 

 VLAN 102 (ACCESS_CONTROL): Dedicated to access control panels, controllers, and associated devices. These devices have different traffic patterns and security requirements than cameras. 

 VLAN 666 (BLACKHOLE): The dead-end VLAN. Every unused port gets assigned here. It is not routable and carries no traffic. Its purpose is to ensure that unused ports cannot be used as entry points. 

 The specific VLAN numbers are not magic. Use whatever numbering scheme makes sense for your environment. What matters is that services are separated, and unused ports are isolated. 

 

 Virtual Chassis (Multi-Switch Environments) 

 Juniper EX series supports Virtual Chassis, which combines multiple physical switches into a single logical unit. Virtual Chassis is the preferred approach for co-located switches. 

```
set virtual-chassis member 0 role routing-engine
set virtual-chassis member 1 role routing-engine
set virtual-chassis auto-sw-update
```

 Virtual Chassis creates a single management plane across all member switches. Configuration changes applied to the primary routing engine propagate to all members. This simplifies management significantly and reduces the number of independent devices to configure and monitor. 

 Junos does not use VTP for VLAN synchronization. In a Virtual Chassis configuration, VLANs are configured once and automatically synchronized across all members. In standalone multi-switch environments, VLANs must be configured consistently on each switch manually. 

 auto-sw-update enables automatic software version synchronization across Virtual Chassis members. When the primary member has a firmware update, other members will update automatically. In production environments, test firmware upgrades before enabling auto-update. 

 Virtual Chassis should be configured and validated before the switch goes into production. Adding a switch to a Virtual Chassis after cameras are live requires careful planning and a maintenance window. 

 

 Stacking vs Aggregated Ethernet (Inter-Switch Connectivity) 

 Before configuring inter-switch connectivity, decide whether your switches will use Virtual Chassis or standalone with aggregated Ethernet uplinks. 

 Virtual Chassis 

 Virtual Chassis combines multiple physical switches into a single logical unit managed as one device. It is the preferred approach when switches are co-located in the same rack or closet. 

 Benefits of Virtual Chassis: 

 
 Single management plane across all members 
 Single configuration to manage 
 Redundant control plane (if a member fails, the Virtual Chassis continues) 
 Cross-member aggregated Ethernet support 
 Simplified spanning tree topology 
 

 The tradeoff is that a Virtual Chassis shares a single control plane. A software defect or a bad upgrade can impact all members simultaneously. Plan firmware upgrades carefully, and always have a rollback plan. 

 Standalone Switches with Aggregated Ethernet/LACP 

 When switches cannot use Virtual Chassis, inter-switch links should use aggregated Ethernet with LACP rather than single links. 

 A single uplink between switches is a single point of failure. If that link goes down, everything behind the downstream switch is disconnected. Aggregated Ethernet bundles multiple physical links into a single logical interface. LACP negotiates and manages the bundle dynamically. 

 Benefits include redundancy (if one physical link fails, traffic continues on the remaining links), increased throughput (aggregate bandwidth of all member links), and automatic failover without spanning tree reconvergence. 

 For security networks specifically, this matters because camera systems generate constant, predictable traffic. Losing an inter-switch link means losing visibility from every camera on that switch. Aggregated Ethernet reduces that risk significantly. 

 

 Logging and AAA Configuration 

```
set system syslog host 10.254.99.10 any info
set system syslog host 10.254.99.10 authorization info
set system syslog host 10.254.99.10 interactive-commands info
set system syslog file messages any notice
set system syslog file authorization authorization info
set system syslog time-format millisecond
!
set system authentication-order password
set system login announcement "Unauthorized Access Prohibited"
!
set system accounting destination tacplus
set system accounting events login
set system accounting events interactive-commands
```

 syslog host sends log output to a centralized log server. Local switch logs are finite and get overwritten. A centralized syslog server retains logs for investigation, auditing, and compliance. 

 syslog any info captures authentication events, configuration changes, interface state changes, and other operationally significant events. 

 interactive-commands logging records every command entered on the CLI. This creates a full audit trail of administrative actions. This is the Junos equivalent of archive log config , and is one of the most important logging configurations on a managed switch. 

 authorization info captures authentication successes and failures. You should know who logged in, when, and from where. 

 AAA (Authentication, Authorization, and Accounting) is the framework that controls who can access the device and what they can do. system authentication-order password uses local authentication. This is appropriate for smaller environments or as a fallback. 

 For environments with more than a few switches, centralize AAA using TACACS+ or RADIUS. Junos supports both. TACACS+ provides per-command authorization, which is more granular than RADIUS. Local authentication should still exist as a fallback. 

```
set system tacplus-server 10.254.99.20 port 49
set system tacplus-server 10.254.99.20 secret ##CHANGEME##
set system authentication-order [tacplus password]
```

 The login announcement sets the legal warning banner. In regulated environments and government deployments, this banner is required. Have legal counsel review the text. The specifics matter by jurisdiction. 

 

 Spanning Tree Configuration 

```
set protocols rstp
set protocols rstp bridge-priority 4096
set protocols rstp interface all edge
set protocols rstp interface all no-root-port
```

 Spanning Tree Protocol prevents network loops. Without it, a single cable plugged into the wrong ports can take down an entire VLAN. 

 Junos supports RSTP (Rapid Spanning Tree), MSTP, and legacy STP. RSTP is the correct choice for most security network deployments. When a link fails or recovers, RSTP recalculates the topology in seconds rather than the 30 to 50 seconds that legacy STP requires. In a security environment where camera uptime matters, faster convergence means shorter outage windows during topology changes. 

 bridge-priority 4096 sets a lower priority value on this switch, making it more likely to be elected as the root bridge. In a predictable topology, you want to control which switch is root. Lower priority values win. Default is 32768. 

 BPDU Guard should be enabled on all access ports. If a switch or bridge device is connected to a port configured as an edge port, BPDU Guard will block that port rather than allowing it to participate in spanning tree. 

```
set protocols rstp interface ge-0/0/0 edge
set ethernet-switching-options bpdu-block interface ge-0/0/0
set ethernet-switching-options bpdu-block disable-timeout 300
```

 The disable-timeout 300 setting automatically re-enables a blocked port after 5 minutes following a BPDU Guard event, avoiding permanent lockout from a brief BPDU event. Adjust based on your operational requirements. 

 

 LLDP 

```
set protocols lldp interface all
```

 LLDP (Link Layer Discovery Protocol) allows devices to advertise their identity and capabilities to directly connected neighbors. This is useful in CCTV environments because it helps identify what is connected to each port, including camera model, IP address, and capabilities. 

 Many IP cameras support LLDP and will advertise their information to the switch. This makes inventory and troubleshooting significantly easier. You can see what device is connected to what port without tracing cables. 

 LLDP operates at Layer 2 and does not cross VLAN boundaries. It is informational only and does not affect traffic forwarding. 

 On ports facing untrusted segments, disable LLDP to limit topology disclosure: 

```
set protocols lldp interface ge-0/0/1 disable
```

 

 SSH Configuration 

```
set system services ssh root-login deny
set system services ssh protocol-version v2
set system services ssh max-sessions-per-connection 1
set system services ssh connection-limit 5
set system services ssh rate-limit 5
set system services ssh ciphers [ aes256-ctr aes192-ctr aes128-ctr ]
set system services ssh macs [ hmac-sha2-256 hmac-sha2-512 ]
!
set system login retry-options tries-before-disconnect 3
set system login retry-options minimum-time 30
set system login retry-options backoff-threshold 2
set system login retry-options backoff-factor 5
```

 root-login deny prevents the root account from logging in via SSH. Root access should require physical console access. This limits the blast radius of a compromised root password. 

 protocol-version v2 forces SSHv2 only. SSHv1 has known vulnerabilities and should never be used. 

 connection-limit 5 caps concurrent SSH sessions to prevent resource exhaustion from connection flooding. 

 rate-limit 5 limits new SSH connections to 5 per minute, slowing down automated brute force tools. 

 The cipher and MAC algorithm lists restrict SSH to strong, modern cryptographic algorithms. This removes older, weaker options that may be used by default in some SSH clients and tools. 

 retry-options limits failed login attempts and introduces delays after repeated failures. This slows down brute force attempts without permanently locking out legitimate users. 

 Telnet is not configured and is disabled by default on Junos. There is no legitimate reason to use Telnet for switch management. 

 To restrict SSH access to specific management stations: 

```
set firewall family inet filter PROTECT-RE term ALLOW-SSH from source-address 10.254.99.0/24
set firewall family inet filter PROTECT-RE term ALLOW-SSH from destination-port 22
set firewall family inet filter PROTECT-RE term ALLOW-SSH from protocol tcp
set firewall family inet filter PROTECT-RE term ALLOW-SSH then accept
set firewall family inet filter PROTECT-RE term DENY-ALL then discard
set interfaces lo0 unit 0 family inet filter input PROTECT-RE
```

 

 Management Interface Configuration 

```
set interfaces vme unit 0 family inet address 10.254.99.## /24
set routing-options static route 0.0.0.0/0 next-hop 10.254.99.1
```

 Juniper EX series switches use the vme interface (Virtual Management Ethernet) for out-of-band management. On platforms with a dedicated management port, this is me0 or em0 . Check your specific model documentation. 

 Management traffic on the vme interface is isolated from the switching fabric by default. This is the preferred management interface. Management access should not compete with camera or access control traffic. 

 Where in-band management is required, create an L3 interface on the management VLAN: 

```
set interfaces vlan unit 99 family inet address 10.254.99.## /24
set vlans MANAGEMENT l3-interface vlan.99
```

 Restrict access to the management interface using the Routing Engine protection filter shown in the SSH section. This is one of the most important hardening steps on Juniper devices, and significantly reduces the attack surface of the management plane. 

 

 Layer 3 Interfaces (Optional, Inter-VLAN Routing) 

```
set interfaces vlan unit 100 family inet address 10.254.100.## /24
set interfaces vlan unit 101 family inet address 10.254.101.## /24
set interfaces vlan unit 102 family inet address 10.254.102.## /24
set vlans SYSTEMS l3-interface vlan.100
set vlans CCTV l3-interface vlan.101
set vlans ACCESS_CONTROL l3-interface vlan.102
set routing-options router-id 10.254.99.##
```

 These L3 interfaces are only required if you intend to use this switch for inter-VLAN routing. Juniper EX switches support Layer 3 switching natively. 

 If your network design uses a dedicated router or firewall for inter-VLAN routing, you do not need these interfaces. Only the management interface is required for device management. 

 If you do enable inter-VLAN routing, implement firewall filters between VLANs to restrict traffic flow. Just because VLANs can route between each other does not mean they should do so without policy. 

 For example, cameras on VLAN 101 need to reach recording servers on VLAN 100, but they should not be able to reach management interfaces on VLAN 99, or access control systems on VLAN 102. 

 For QoS on camera traffic, Junos uses scheduler and forwarding class policies: 

```
set class-of-service interfaces vlan.101 unit 0 forwarding-class expedited-forwarding
set class-of-service interfaces vlan.101 unit 0 loss-priority low
```

 Apply classifier and scheduler policies as required for your traffic profile. 

 

 Trunk Port and Aggregated Ethernet Configuration 

 Inter-Switch Trunk (Aggregated Ethernet with LACP) 

```
set chassis aggregated-devices ethernet device-count 10
!
set interfaces ae0 description "Uplink to SWITCH_NAME"
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members [MANAGEMENT SYSTEMS CCTV ACCESS_CONTROL BLACKHOLE]
set interfaces ae0 unit 0 family ethernet-switching native-vlan-id 666
!
set interfaces xe-0/0/0 ether-options 802.3ad ae0
set interfaces xe-0/0/1 ether-options 802.3ad ae0
```

 chassis aggregated-devices ethernet device-count 10 reserves logical aggregated Ethernet interfaces. Set this to the number of LAG interfaces you need across the switch. 

 lacp active configures LACP in active mode. Both sides should be configured as active. LACP negotiates the bundle and detects link or configuration mismatches. 

 lacp periodic fast sends LACP PDUs every second rather than every 30 seconds. Failed links are detected and removed from the bundle much faster, reducing the traffic loss window during a link failure. 

 native-vlan-id 666 sets the native VLAN to the blackhole VLAN. The native VLAN carries untagged traffic. By setting it to an unused VLAN, any untagged traffic hitting this trunk goes nowhere. This is a security measure against VLAN hopping attacks that exploit the default native VLAN. 

 vlan members explicitly limits which VLANs are permitted on the trunk. Only permit the VLANs that need to traverse this link. 

 Junos does not have a DTP equivalent. Trunk configuration is always explicit in Junos. There is no dynamic trunking to disable. This is the correct behavior. 

 Server Aggregated Ethernet (Access Mode) 

```
set interfaces ae1 description "Recording Server"
set interfaces ae1 aggregated-ether-options lacp active
set interfaces ae1 unit 0 family ethernet-switching interface-mode access
set interfaces ae1 unit 0 family ethernet-switching vlan members SYSTEMS
!
set interfaces ge-0/0/2 ether-options 802.3ad ae1
set interfaces ge-0/0/3 ether-options 802.3ad ae1
```

 For servers connecting to the switch, an aggregated Ethernet interface can also be configured in access mode on a single VLAN. This provides redundancy and throughput without trunking. If the server is using NIC teaming or LACP bonding, the switch-side aggregated Ethernet configuration must match. Mismatched LACP settings between the server and switch are a common cause of connectivity issues. 

 

 Access Port Configuration (Camera Ports) 

```
set interfaces ge-0/0/0 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members CCTV
set interfaces ge-0/0/0 description "Camera Port"
set protocols rstp interface ge-0/0/0 edge
set ethernet-switching-options bpdu-block interface ge-0/0/0
!
set ethernet-switching-options secure-access-port interface ge-0/0/0 mac-limit 1
set ethernet-switching-options secure-access-port interface ge-0/0/0 mac-limit action drop
set ethernet-switching-options secure-access-port interface ge-0/0/0 allowed-mac ##:##:##:##:##:##
```

 This is where the cameras connect. Every camera port is configured with the same baseline settings. 

 interface-mode access sets the port to access mode on a single VLAN. Cameras do not need trunk access. 

 vlan members CCTV assigns the port to the CCTV VLAN. 

 protocols rstp edge is the Junos equivalent of PortFast. It skips the listening and learning states and brings the port up immediately. This is appropriate for ports connecting to end devices rather than other switches. 

 bpdu-block shuts the port down if a BPDU is received, preventing unauthorized switches from being connected to camera ports. 

 Port security is critical on camera ports. Cameras do not change. The same camera sits on the same port for years. Port security takes advantage of that predictability. 

 mac-limit 1 allows only one MAC address per port. If a camera is the only thing that should be connected, one is the right number. 

 mac-limit action drop drops traffic from any MAC address beyond the limit. The alternative action shutdown err-disables the port entirely, which is more disruptive but more secure. In a security environment, shutdown is the appropriate response. 

 allowed-mac pins a specific MAC address to the port. Once a camera's MAC is known, lock it in. This prevents any other device from communicating through that port regardless of the mac-limit setting. 

 When a port enters an err-disabled state due to a violation, it requires manual intervention to bring it back up. This is intentional. You want to know why a camera port had an unauthorized device connected before re-enabling it. 

 

 Unused Port Handling 

```
set interfaces ge-0/0/45 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/45 unit 0 family ethernet-switching vlan members BLACKHOLE
set interfaces ge-0/0/45 description UNUSED
set interfaces ge-0/0/45 disable
```

 Any port not connected to a device should be assigned to the blackhole VLAN and disabled. Unused ports are entry points. Putting them on the blackhole VLAN and disabling them ensures they cannot be used to access any production VLAN. 

 The description "UNUSED" makes it immediately clear during troubleshooting or auditing which ports are intentionally disabled. 

 When a port is needed in the future, remove it from the blackhole VLAN, assign it to the correct VLAN, apply appropriate port security, and enable it. 

 

 HTTP and NTP Configuration 

```
delete system services web-management
delete system services xnm-clear-text
!
set system ntp server ##.##.##.## version 4
set system ntp source-address 10.254.99.##
```

 delete system services web-management removes the HTTPS management interface. If you manage the switch exclusively through SSH and CLI, the web interface is an unnecessary attack surface. Remove it. 

 delete system services xnm-clear-text removes the unencrypted Junos XML management interface. This should never be running on a production device. 

 If web management is required for your environment, configure it to listen only on the management interface: 

```
set system services web-management https interface vme.0
set system services web-management https port 443
```

 NTP (Network Time Protocol) is critical. Without accurate time, your logs, your camera timestamps, and your access control events cannot be correlated reliably. Time is evidence. If systems are out of sync, the timeline of any investigation becomes unreliable. 

 ntp source-address binds NTP queries to the management interface IP address. This keeps NTP traffic on the management plane rather than mixing it with production traffic, and ensures NTP responses are returned to the correct interface. 

 Point all switches to a reliable NTP source. If the network is isolated, use a GPS-based NTP server. If the network has controlled internet access, use a trusted public NTP source such as the National Research Council of Canada's NTP service. Every device on the security network should use the same time source. 

 

 What This Template Does Not Cover 

 This is a baseline. It gets you to a reasonable starting point for a CCTV and security network. There are additional configurations that should be considered depending on the environment: 

 
 DHCP snooping and Dynamic ARP Inspection (DAI) for additional Layer 2 security 
 802.1x for network access control beyond port security 
 SNMPv3 configuration for secure monitoring 
 TACACS+ or RADIUS for centralized AAA 
 Firewall filters between VLANs for traffic policy enforcement 
 DHCP relay configuration if using centralized DHCP 
 Firmware update and lifecycle management 
 Configuration backup and change management 
 

 Each of these deserves its own discussion and should be implemented based on the specific requirements of your environment. 

 

 Final Thoughts 

 A switch out of the box is designed to forward traffic. It is not designed to be secure. Security comes from configuration. 

 The controls in this template are not advanced. They are fundamentals. VLAN segmentation, port security, SSH-only access, AAA, trunk hardening, and NTP. These are the baseline that every CCTV and security network should have before a single camera goes live. 

 If your current network does not have these in place, it is worth a review. The systems protecting your organization deserve a network that is configured with the same level of care.

================================================================

## Multicast for CCTV Networks: IGMP Snooping, Queriers, and the Outage That Follows Skipping Them

URL: https://hans.study/standards-guidance/multicast-for-cctv-networks/
Type: kb
Date: 2026-08-30
Description: When multicast video makes sense, why IGMP snooping without a querier floods or starves the VLAN, where to place the querier, and the configuration on Cisco, Aruba CX, and Juniper.

Multicast video is one of those things that works perfectly in the lab, works perfectly at commissioning, and then takes the video wall down four minutes after the network team makes a change that had nothing to do with video. Every one of those incidents I have investigated came back to the same two items: IGMP snooping was on, and there was no querier. This page is about why that combination fails, and how to build multicast so it does not. 
 

 When multicast is worth it 
 A camera stream sent by unicast goes once to every consumer. Ten operators watching the same camera at 8 Mbps costs 80 Mbps at the source and along every shared link. Multicast sends it once and the network replicates it where the paths diverge. The saving is real when the same streams are watched in many places at once: video walls, control rooms, federated monitoring, and any site where operators habitually pull the same feeds. 
 It is not worth it when most viewing is one operator, one camera, for a short time. Then it adds a control-plane dependency for no bandwidth benefit, and the dependency is the part that fails. Most sites under a hundred cameras with a handful of operators are better served by unicast and a properly sized network. Most sites with a video wall are not. 
 In Security Center, the Media Router role makes the choice per stream. It will use multicast from a camera that supports it to any client on a multicast-capable path, and fall back to unicast otherwise. The default multicast base address is 239.0.0.1 and the default port is 47806 ; the Media Router allocates addresses upward from there. Milestone and Avigilon offer the same choice with different names. The network requirement is identical in every case. 
 

 What IGMP snooping actually does 
 A switch without IGMP snooping treats multicast like broadcast. Every multicast frame goes to every port in the VLAN. On a camera VLAN carrying two hundred multicast streams that is a full-time flood into every port, including the ports that connect to cameras, which promptly drop everything that is not addressed to them and get on with life, but only after the switch has spent the bandwidth delivering it. 
 IGMP snooping fixes this by listening to the IGMP conversation between hosts and routers. When a client wants a group it sends an IGMP membership report. The switch sees the report, notes which port it came from, and forwards that group only to ports where someone asked for it. Cameras that nobody is watching send to nobody. The mechanism is described in RFC 4541 and implemented on every managed switch built this century. 
 The subtlety is in the word conversation . IGMP membership is not permanent. The router in the VLAN sends a general query at intervals, hosts respond with reports for the groups they still want, and the switch refreshes its table. Membership that is not refreshed ages out, typically after two query intervals plus a margin, which on default timers is around 260 seconds. 
 

 The querier, and why its absence is an outage 
 That query has to come from somewhere. In a routed network it comes from the multicast router on the VLAN. On a CCTV VLAN there is often no multicast router at all. Video is layer two, the VLAN has a gateway that does not run PIM, and nothing is sending queries. 
 Now the timeline. The system is commissioned. Operators open the video wall; clients send reports; the switch learns the ports; video flows. Nothing sends a query, so nothing refreshes the table. Around four minutes later the entries age out. On most switches the result is that the multicast groups are now unknown, and unknown multicast is either flooded to every port or dropped, depending on the platform and on whether the snooping implementation floods or prunes unknown groups. Either the VLAN floods and the cameras start missing frames, or the video wall goes black. 
 The fix is a querier. Any device that sends IGMP general queries on the VLAN keeps the snooping tables alive. The switch itself can do it, and on a video VLAN with no multicast router, it should. 
 The four-minute rule. If multicast video works at commissioning and fails a few minutes after clients connect, then recovers when a client reconnects, then fails again, there is no querier on the VLAN. I have seen this diagnosed as a camera fault, a Media Router fault, a driver fault, and a cabling fault, in that order, over three weeks. It was a missing line of switch configuration. 
 

 Where the querier lives 
 One querier per VLAN is the goal. If several switches are configured as queriers on the same VLAN, IGMP elects the one with the lowest IP address and the rest go quiet. That is safe, and it is why the normal pattern is to enable the querier on every switch in the video VLAN and let election sort it out. The alternative, enabling it on one switch and hoping that switch never reboots, is a single point of failure that will find you during a firmware upgrade. 
 The querier needs an IP address in the VLAN. On a switch that is a pure layer two device in that VLAN, that means a switched virtual interface with an address whose only job is to source queries. Reserve an address for it in the VLAN plan; a querier with no address does not query. 
 Where the VLAN is routed and the gateway runs PIM, the router is the querier and the switch queriers should still be enabled, because they yield to it and take over if it goes. 
 

 Configuration 
 These are the multicast lines that belong in the video VLAN on each platform. They are extracted from the full switch templates linked at the end, which carry the rest of the baseline. VLAN 20 is the camera VLAN in every example. 

 Cisco Catalyst (IOS-XE) 
```
ip igmp snooping
ip igmp snooping vlan 20
ip igmp snooping vlan 20 querier
ip igmp snooping vlan 20 querier address 10.20.0.2
!
interface Vlan20
 description CAMERA-VLAN-QUERIER
 ip address 10.20.0.2 255.255.0.0
!
! If unknown multicast must not flood the camera ports:
ip igmp snooping vlan 20 immediate-leave
```
 Snooping is on by default on Catalyst; the querier is not. The querier address form lets the querier source from an address even where the SVI is not the gateway. Immediate-leave, also called fast-leave, prunes a port as soon as the client sends a leave rather than waiting a query interval, which suits video wall ports with one client each and does not suit ports with a hub or an unmanaged switch behind them. 

 Aruba CX (AOS-CX) 
```
vlan 20
 name CAMERAS
 ip igmp snooping
 ip igmp snooping querier
 ip igmp snooping fastleave
interface vlan 20
 ip address 10.20.0.2/16
```
 AOS-CX enables snooping per VLAN. The querier sources from the VLAN interface address, so the interface needs one. 

 Juniper EX (Junos) 
```
set protocols igmp-snooping vlan CAMERAS
set protocols igmp-snooping vlan CAMERAS immediate-leave
set protocols igmp-snooping vlan CAMERAS l2-querier source-address 10.20.0.2
set interfaces irb unit 20 family inet address 10.20.0.2/16
set vlans CAMERAS l3-interface irb.20
```
 Junos calls the switch-based querier an l2-querier , which is the accurate name for what it is. 
 

 Group addressing 
 Keep video multicast inside the administratively scoped range, 239.0.0.0/8 , which is what the platforms default to. Within it, avoid groups that map to the same layer two MAC address as something else. Multicast IP maps to Ethernet MAC by taking the low 23 bits, so 32 different IPv4 groups share every MAC, and 239.0.0.x collides at layer two with 224.0.0.x , which is the range reserved for local control protocols like OSPF and VRRP. A camera group that lands on the same MAC as OSPF hello traffic works, mostly, and then produces the strangest fault you will see all year. 
 Set the platform's multicast base to something like 239.192.0.0 and let it allocate from there. The change is one field in the Media Router or the equivalent, and it removes an entire category of intermittent problem. 
 Set the TTL on multicast streams to what the topology needs and no more. A TTL of 1 stays on the VLAN, which is right for a layer two video network and wrong the moment federation or a remote operator needs the stream across a router. 
 

 Things that fight multicast 
 
 Storm control. A multicast storm threshold set low enough to protect against a loop will drop legitimate video on a busy VLAN. Set the multicast threshold with the actual stream load in mind, or apply storm control to broadcast only on video ports. 
 Unmanaged switches at the edge. A desktop switch under a console does not snoop. Every multicast group any client behind it joins floods to every port on it. Replace it, or accept that those ports see everything. 
 Unknown multicast flooding. Some platforms flood groups with no known members; others drop them. Know which yours does, because it decides whether a querier failure looks like a flood or a blackout. 
 Trunk pruning and VLAN mismatches. A trunk that does not carry the video VLAN, or a port in the wrong VLAN, produces a client that can see the camera's configuration but never receives its multicast. The unicast fallback in the VMS hides this until someone looks at the bandwidth graphs and asks why multicast is not saving anything. 
 IGMP version mismatches. IGMPv3 clients and an IGMPv2 querier interoperate, but source-specific joins do not. Most video platforms use any-source multicast, so this rarely matters, and when it does, the symptom is a client that joins and receives nothing. 
 
 

 Verification 
 On the switch, look at the snooping table and confirm the querier is present and that groups have members on the ports you expect: 
```
! Cisco
show ip igmp snooping querier vlan 20
show ip igmp snooping groups vlan 20

# Aruba CX
show ip igmp snooping vlan 20
show ip igmp snooping groups vlan 20

# Junos
show igmp snooping membership vlan CAMERAS
show igmp snooping statistics
```
 Then wait ten minutes with the video wall up and check again. If the groups are still there, the querier is doing its job. If they have gone and the wall is still showing video, the VMS has quietly fallen back to unicast and the exercise was pointless. If they have gone and the wall is black, you have reproduced the outage under controlled conditions, which is the best possible time to find it. 
 The full switch baselines for each platform, including the rest of the camera VLAN configuration, are in the Cisco Catalyst , Aruba CX , and Juniper EX templates.

================================================================

## PoE Budgets for Camera and Access Control Switches: Classes, Power Supplies, and the Ports That Go Dark

URL: https://hans.study/standards-guidance/poe-budgets-for-camera-and-access-control-switches/
Type: kb
Date: 2026-09-01
Description: What the 802.3af, at, and bt classes actually deliver at the device, why the switch's power supply rather than its port rating sets the budget, how to count a load that includes PTZs and heaters, and what happens when the budget runs out.

A 48-port PoE+ switch does not have 48 PoE+ ports. It has 48 ports that can each negotiate PoE+, and a power supply that decides how many of them get it. On the ones I see specified for camera networks, the supply is sized for somewhere between a third and half of the ports at full draw, and the other half get whatever is left. That is fine if someone did the arithmetic. It is a slow-motion outage if nobody did, because the switch will happily bring up every camera at commissioning, and then start dropping the ones at the bottom of its priority list on the first cold night when the heaters come on. 
 This page is the arithmetic, and the failure modes that follow skipping it. 
 

 What the standards actually deliver 
 The number on the datasheet is power at the switch port. The number that matters is power at the device, after the cable has taken its share. The standards define both. 
 
 
 Standard Type / class At the port (PSE) At the device (PD) Pairs Typical loads 
 
 802.3af Type 1, classes 0 to 3 15.4 W 12.95 W 2 Fixed cameras, readers, small panels 
 802.3at Type 2, class 4 30 W 25.5 W 2 PTZ, multi-sensor, cameras with IR 
 802.3bt Type 3, classes 5 and 6 60 W 51 W 4 PTZ with heater, large multi-sensor, door controllers 
 802.3bt Type 4, classes 7 and 8 90 W 71.3 W 4 Heated speed domes, thin clients, lighting 
 
 
 
 The gap between the two columns is cable loss at the standard's worst-case 100 metre channel. On a 30 metre run the device sees more than the table says; on a run near the limit it sees exactly the table and no more. A camera rated for 24 W on a 95 metre run of marginal Category 5e is a camera that reboots when its IR turns on. 
 Class matters for budgeting because the switch reserves power by class at negotiation, not by what the device actually draws. A class 4 device that draws 14 W in practice still reserves 30 W at the port until LLDP or the vendor's proprietary negotiation trims it. Some switches trim; many do not by default. 
 

 The power supply sets the budget 
 The switch's total PoE budget is what its power supply can deliver to the ports after the switch itself has taken what it needs to run. That figure is on the datasheet, usually somewhere below the headline port count, and it is the only number that decides how many devices the switch can actually power. 
 
48-port "PoE+" access switch, single 370 W supply
 48 ports × 30 W reserved at class 4 = 1,440 W required
 Budget available = 370 W
 Ports that get full PoE+ = 12
 
 Twelve. The other thirty-six negotiate down, get lower classes, or get nothing, depending on the priority configuration. The same chassis with a 740 W supply powers 24. With dual 740 W supplies in a combined mode, closer to 48, and with dual supplies in a redundant mode, back to 24, because the second supply is there for when the first fails, not to add budget. 
 This is the point that gets missed on drawings: the quantity and size of the power supplies installed decides the PoE capacity, not the model number of the switch. A switch specified by model with the supply left to "as standard" has a budget nobody chose. Specify the supply, specify whether the second supply is for redundancy or for capacity, and write the resulting budget on the drawing next to the switch. 
 

 Counting the load 
 Add up the devices by class, at the class they will negotiate, not at their idle draw. Then apply the things the class table does not show. 
 
 Heaters and blowers. A camera that is class 4 in summer is class 6 in winter when the housing heater runs. The datasheet will say so in the small print. Budget for the winter figure. 
 Infrared. IR illuminators draw at night. A camera's peak draw is at 02:00 in January with IR on and the heater running, which is precisely when you most want it recording. 
 PTZ motion. A dome drawing 12 W at rest draws considerably more during a pan. Budget the peak. 
 Access control. A reader is small. A PoE door controller running a maglock and a REX from its own PoE budget is not, and a class 6 controller is now common. Locks on the controller's PoE are also locks that release when the switch reboots, which is a design decision, not an accident. 
 Growth. Every camera network I have audited has more cameras than the drawing it was built from. Leave 20 percent of the budget unallocated at commissioning. 
 Cable. Runs over 70 metres, runs on Category 5e, and runs through patch panels with more than two connections between switch and device all lose more power. The standard already assumes worst case; the device's own rating may not. 
 
 
Worked example, one IDF:
 22 fixed cameras, class 3 22 × 15.4 W = 339 W
 6 multi-sensor with IR, class 4 6 × 30 W = 180 W
 4 PTZ with heater, class 6 4 × 60 W = 240 W
 8 door controllers, class 4 8 × 30 W = 240 W
 Reserve for growth, 20 percent = 200 W
 --------
 Budget required 1,199 W
 Two 740 W supplies, combined mode 1,480 W fits
 Two 740 W supplies, redundant mode 740 W does not
 
 

 LLDP and what the switch reserves 
 The physical-layer classification at power-up is coarse. LLDP-MED, and vendor extensions such as Cisco's CDP power negotiation, let the device tell the switch precisely what it needs, and let the switch reserve that rather than the class maximum. On a switch with a tight budget this is the difference between powering 30 cameras and powering 22. 
 Enable LLDP on every camera port and confirm the cameras speak it; most current models do. Then check what the switch is reserving against what the devices are drawing: 
```
! Cisco Catalyst
show power inline
show power inline interface GigabitEthernet1/0/12 detail

# Aruba CX
show power-over-ethernet brief
show power-over-ethernet interface 1/1/12

! Alcatel-Lucent OmniSwitch
show lanpower slot 1/1
```
 A port showing 30 W allocated for a device drawing 8 W is a device that is not negotiating. Either LLDP is off on one end, or the device only classifies at the physical layer, or the switch is configured to ignore negotiation and allocate by class. All three are fixable and the budget you recover is real. 
 

 Priority, and what goes dark first 
 When the budget runs out the switch sheds load. Which ports it sheds is set by the per-port PoE priority, and the default on most platforms is that every port is the same priority and the highest-numbered ports lose first. Nobody plans their camera layout around port numbering, so the cameras that go dark are whichever ones the installer patched last. 
 Set priority deliberately. Critical on the perimeter and the door controllers, high on the cameras covering egress and cash, low on the ones covering the staff car park. Then when the budget is short, the loss is the one you chose. 
```
! Cisco Catalyst: critical, high, low
interface GigabitEthernet1/0/1
 power inline port priority critical

# Aruba CX
interface 1/1/1
 power-over-ethernet priority critical
```
 And configure the switch to alert when the budget is over a threshold. Most platforms will raise a trap or a syslog message at a configurable percentage of budget. Route it to whoever watches the network, because a switch at 95 percent of its PoE budget is one heater away from shedding a camera, and a shed camera on a healthy network link looks, to the VMS, like a camera that broke. 
 

 Failure modes 
 
 What is reported What is usually wrong 
 
 Cameras drop at night in winter, fine by day Budget exceeded when IR and heaters come on. Check the PoE log for the time of the drops. 
 One camera reboots when it pans or when IR triggers Long or poor cable; device sees less than its rating at peak. Move it to a bt port, shorten the run, or accept a lower class. 
 New cameras come up, older ones start dropping Budget was full; priority is default; highest-numbered ports lost. 
 Half the switch loses PoE at once One of two supplies failed and the pair was in combined mode. The budget halved. 
 Doors fail open or fail secure during a switch reboot Locks on the door controller's PoE. Decide whether that is intended; if not, locks need a supervised power supply of their own. 
 Camera draws more than the port allows and the port shuts down Device class above port capability, usually a bt camera on an at port. Match the port to the device. 
 
 
 

 Design checklist 
 
 Load counted by class at winter peak, with IR, heaters, PTZ motion, and door controllers included. 
 20 percent of budget reserved at commissioning. 
 Power supplies specified by quantity and size, and the mode, combined or redundant, decided and written on the drawing. 
 Budget available compared to budget required, per switch, on the drawing. 
 LLDP enabled on camera ports; switch allocating by negotiation rather than by class. 
 Port priority set by what the camera covers, not by port number. 
 PoE budget threshold alert configured and routed. 
 Cable runs over 70 metres and any Category 5e runs flagged against the device's rating at the device. 
 Locks on PoE door controllers identified, and the behaviour on switch power loss decided. 
 
 The rest of the camera VLAN configuration, including the PoE lines in context, is in the Cisco , Aruba CX , and OmniSwitch templates.

================================================================

## Security Controls for CCTV and Access Control Networks

URL: https://hans.study/standards-guidance/security-controls-cctv-access-control-networks/
Type: kb
Date: 2025-02-25
Description: Ten practical security controls every physical security network needs. Hardening, VPN, segmentation, logging, credentials, MFA, and more.

Security Controls Assessment, Physical Security Network 
 
 ⚡ Harden all devices Apply vendor hardening guides before production. Genetec, Axis, Bosch, Milestone all publish them. 
 🔥 Firewall and VPN No exposed management ports. Remote access via VPN with MFA only. 
 ⚠ Default credentials Change every default password on every device before it goes into production. 
 📋 Centralized logging Authentication events, connection logs, admin actions. Forward to a centralized service. 
 ✓ Network segmentation Cameras, access control, systems, management on separate VLANs. 
 🔐 Multi-factor auth VPN, VMS, management interfaces. Not optional. 
 ✓ Central AAA (AD + RADIUS) Active Directory with 802.1X and RADIUS for network access control. 
 ⚠ Patch schedule Firmware, OS, application. End-of-support systems need compensating controls. 
 💾 Tested backups 3-2-1 rule. Encrypted offsite. Actually tested, not just assumed to work. 
 ✓ Endpoint protection Behaviour-based EDR on servers and workstations. Host firewall enabled. 
 
 Orange = common gap. Red = critical gap. Green = typically in place. 
 
 Your organization probably spent a significant amount of money on cameras, access control, and monitoring systems to protect people and assets. There is a good chance the network those systems run on is one of the least secure networks you have. 
 Over the past 15 years, I have worked on thousands of CCTV and access control networks across government, law enforcement, healthcare, transportation, and enterprise environments. The common trait across all of them? These networks are consistently under-secured. The systems we invest in to protect physical assets are often the most exposed to digital threats. 
 This is not a failure of intent. It happens for predictable reasons. 
 Security integrators specialize in cameras, panels, and software. Many are excellent at what they do. But they are often not equipped to design or secure the underlying network infrastructure. IT and cybersecurity are not their core competency, and the industry has been slow to close that gap. 
 Clients also play a role. There is often reluctance to invest in firewalls, VPN services, or proper segmentation because it adds cost and perceived complexity. Many organizations want their systems to work without involving IT, and that preference for convenience creates exposure. 
 Open management interfaces, exposed remote access ports, default credentials, flat networks with no segmentation. These are still common. They should not be. 
 The good news is that most of this risk can be reduced without massive investment. The controls below are practical, implementable on existing infrastructure, and applicable across any physical security platform. 
 
 Harden Servers and Network Devices 
 Every camera, server, switch, panel, and controller should be hardened before going into production. Most quality manufacturers publish hardening guides for their platforms. Genetec, Milestone, Axis, Bosch, and others all provide documentation on how to reduce the attack surface of their products. Follow those guides. If your integrator is not applying them, ask why. 
 Hardening includes disabling unnecessary services, restricting management access to specific IP ranges, applying proper authentication, removing default configurations, and changing all default credentials. These steps take time during deployment. They prevent problems later that take significantly more time to resolve. 
 For network devices specifically: disable Telnet, enable SSHv2, restrict SNMP to read-only if SNMP is required at all, disable CDP/LLDP on access ports, configure console and VTY timeouts, and require authentication for all management access. These are baseline items. They belong in your standard switch configuration template, not as an afterthought. 
 For servers running VMS or access control software: apply OS hardening as covered separately in the Windows Server hardening series on this site. Disable unnecessary services, remove unneeded features, configure the Windows Firewall, and apply patching on a defined schedule. 
 
 Use Firewalls and VPNs for Remote Access 
 Security networks should be isolated from corporate networks and from the internet. Firewalls and gateway technologies provide that separation. 
 Remote access should go through a VPN. Not an exposed RDP session on port 3389. Not a camera with a port forward that lets the integration vendor connect to it directly from the internet. A VPN with MFA, where the session is authenticated and logged, and where the vendor's access is scoped to what they actually need. 
 Limit internet access from the security network to a whitelist methodology. Only systems that explicitly require outbound connectivity should have it. For update management, deploy a central WSUS or update server with controlled internet access rather than giving every device direct outbound access. Your cameras and access control panels do not need to reach arbitrary internet destinations. Control what communicates externally. 
 Port forwards to cameras and VMS servers are one of the most common gaps I see documented in security audits. Every open port is an attack surface. Camera firmware vulnerabilities are real and discovered regularly. Vendors push firmware updates precisely because these vulnerabilities get found and exploited. If you have deployments with cameras or VMS servers exposed directly via port forwarding, it is worth having that conversation with the client and documenting the risk in writing if they choose not to remediate. 
 Exposed remote access is the most common initial access vector for attacks on physical security networks. An RDP port exposed to the internet will be scanned and attacked within hours of going live. VPN is not an optional enhancement. It is the minimum standard for any system that requires remote management. 
 
 Change Default Credentials 
 Every new device and every new installation should mean new credentials. No exceptions. 
 Default usernames and passwords are publicly documented. They are in manufacturer documentation, on vendor support sites, and in searchable databases used by automated scanning tools. These tools scan the internet continuously. A camera with a default password that is accessible from the internet will be found and compromised, typically within the same day it goes online. 
 This is not a theoretical risk. Default credentials are the most commonly exploited vulnerability in physical security deployments. The Mirai botnet, which took down significant internet infrastructure in 2016, was built almost entirely from compromised cameras and DVRs running default credentials. 
 Use a password manager to track credentials across devices and installations. Require integrators and vendors to update their passwords regularly. Better yet, only activate vendor accounts when access is needed and disable or delete them when the work is complete. Shared passwords between sites or between staff create risk that compounds over time. One leaked credential should not mean every system you have commissioned is accessible to someone you did not authorize. 
 On Genetec environments specifically: disable the default admin account after creating named administrator accounts tied to individual users. Every action in Genetec is logged with the account that performed it. If everyone uses a shared admin account, your audit trail is useless. 
 
 Enable Logging 
 Configure logging for authentication events and connections across servers, switches, cameras, and access control systems. Forward events to a centralized logging service. 
 This is both a security control and a troubleshooting asset. When something goes wrong, whether it is a security event or an operational failure, having a clear record of what happened and when is critical. Without centralized logging, investigations are slow, incomplete, and often inconclusive. With it, you can reconstruct the full sequence of events. 
 The 5 Ws of any security event: who, what, when, where, and why. Good logging gives you all five. Logging that lives only on the device that was compromised gives you nothing after the attacker covers their tracks. 
 At minimum, log authentication successes and failures, configuration changes, administrative actions, and network connection events from infrastructure devices. On Windows Server systems, use Advanced Audit Policy Configuration rather than basic audit policies, it provides significantly more granularity and is covered in detail in the audit logging post in this series. 
 A SIEM is not required for meaningful logging. Even forwarding events to a syslog server that stores them for 90 days is substantially better than no centralized logging. Start somewhere. The logs that exist when something happens are infinitely more useful than the logs you wished you had configured. 
 
 Isolate and Segment Networks 
 Security systems should not share the same unrestricted network as corporate workstations, printers, and guest Wi-Fi. 
 Network segmentation creates separation between systems based on function. CCTV, access control, corporate, and guest traffic should be isolated into distinct network segments using VLANs or physical switch separation. If one system becomes compromised on a flat network, the attacker can reach everything. Segmentation contains that movement and limits the scope of any incident. 
 This does not require expensive infrastructure changes. Most modern managed switches and firewalls support VLAN configuration and access policies at entry-level price points. The cost of segmentation at commissioning is a small fraction of the cost of a breach that propagates across a flat network. 
 A practical segmentation scheme for a physical security deployment on a single site using 10.42.67.0/24 as an example network: 
```
VLAN 99 Management: 10.42.67.x Switch SVIs, firewall interfaces
VLAN 100 Systems: 10.42.67.x VMS servers (.11, .12), workstations (.20-.50)
VLAN 101 CCTV: 10.42.67.x Cameras (.100-.200)
VLAN 102 Access Control: 10.42.67.x Panels, controllers (.100-.180)
VLAN 666 Blackhole: No routing Unused ports, no services
```
 For multi-site deployments, use a site-based addressing scheme: 10.<site>.<vlan>.<host> . The VLAN identifier embedded in the address means you can identify what a device is and where it is from the address alone, which matters during troubleshooting at 3 AM. 
 Segmentation is one of the most consistently skipped steps in physical security deployments. It adds time during commissioning. Clients cannot see what they are getting. The value only becomes visible when something goes wrong and the impact is contained rather than total. The conversation is worth having every time. 
 
 Implement Multi-Factor Authentication 
 Use MFA wherever it can be deployed. On VMS platforms, on management interfaces, on VPN access, on anything that controls or provides access to critical systems. 
 MFA prevents unauthorized access even when passwords are compromised. It is one of the most effective individual controls available and should be treated as a requirement, not an enhancement. 
 This applies to Active Directory environments, to Genetec Security Center operator accounts, to C-CURE 9000 administrative access, to Milestone Management Client, and to any system where an operator login controls physical security functions. Enabling MFA on these systems is straightforward on modern platforms. The friction for legitimate users is minimal. The friction for an attacker with a compromised password is total. 
 MFA on privileged accounts and externally-facing services is no longer optional in environments that take security seriously. Many insurance providers and compliance frameworks have reached the same conclusion. 
 
 Deploy Central Authentication (AAA) 
 Deploy, integrate, and use Active Directory where possible to centralize management of users and access. This provides a significant increase in security posture over local accounts scattered across dozens of devices with inconsistent password policies and no central oversight. 
 In larger deployments, especially multi-server Genetec environments, AD provides centralized authentication, consistent security policy enforcement, and reliable time synchronization across the environment. Kerberos authentication requires synchronized clocks. A 5-minute time difference between a Genetec server and the domain controller will cause authentication failures. Time synchronization is not optional in AD-integrated environments. 
 Use 802.1X and RADIUS for network access control where possible. This ensures that devices connecting to the network are authenticated before they are allowed to communicate. An unrecognized device connecting to a camera port on a properly configured switch with 802.1X will not get network access. That is exactly the behavior you want. 
 Central AAA means accountability. Every access event is logged with who performed it, from which system, at what time. When something needs to be investigated, that accountability chain is what makes the investigation conclusive. 
 
 Harden Active Directory 
 If you deploy Active Directory, you need to secure it properly. AD serves as the central authority for authentication and authorization on most enterprise networks. When it is compromised, the attacker effectively owns everything that AD controls. 
 The low-hanging fruit that must be removed: implement tiered administration, deploy LAPS for local administrator passwords, enforce strong password policies with a length requirement rather than just complexity, disable legacy authentication protocols (NTLMv1, LM hash), and properly configure audit policies. AD should be connected to your centralized logging so that a compromise does not go undetected. 
 A dedicated Windows Server hardening guide is available in this series. Active Directory hardening goes beyond OS hardening and is covered in the Group Policy hardening post specifically. 
 
 Patch and Update Everything 
 Patching is not limited to Windows Updates. Cameras, access control panels, switches, firewalls, and even UPS units receive firmware updates that address security vulnerabilities. Stay current on updates. When software reaches end of support, it is time to upgrade or implement compensating controls. 
 For environments where cameras and access control systems run on Windows Server, consider Windows Enterprise LTSC (Long-Term Servicing Channel). LTSC provides security updates without the constant feature changes that can cause compatibility issues with security platforms that have strict OS version requirements. Several VMS platforms and access control systems have explicit LTSC support for exactly this reason. 
 WSUS for centralized Windows update management. A scheduled firmware review and update process for network infrastructure and cameras. Documented end-of-support dates for every major component. These are the building blocks of a patching program that actually functions. 
 
 Back Up Critical Systems and Configurations 
 Think about your environment. What systems would be painful to rebuild from scratch? Could you actually restore them if you needed to? 
 Losing an entire cardholder database, a credential management system, or camera configurations is not theoretical. It happens. Ransomware has encrypted physical security systems. Hardware has failed in ways that were not covered by vendor support agreements. And when it does happen, the recovery process is either fast and controlled or slow and chaotic depending on whether tested backups exist. 
 Switch configurations should be backed up after every change and stored in a version-controlled system. Server configurations and databases should be backed up on a scheduled basis. Those backups should be tested by actually restoring them to a test environment. A backup that completes successfully every night but has never been tested is an assumption, not a safety net. 
 Follow the 3-2-1 rule: three copies of the data, two different storage media types, one offsite. Encrypt backups, especially offsite copies. Test restores on a quarterly schedule minimum. Document the restore procedure and keep it somewhere other than the system you might need to restore from. 
 
 Deploy Endpoint Protection and Monitoring 
 Workstations and servers should have endpoint protection deployed. Traditional signature-based antivirus is not sufficient on its own. Modern threats require behavior-based detection. 
 EDR, MDR, or XDR platforms provide visibility and response capabilities that go beyond what legacy antivirus tools offer. Whether you deploy a full managed solution or a centrally managed platform with behavioral detection, make sure it is properly configured, tuned with appropriate exclusions for the security software it is protecting, and actually tested. 
 For Genetec Security Center servers specifically: antivirus exclusions are critical and must be configured correctly. Incorrect exclusions cause Genetec performance problems that look like hardware or software issues. Genetec publishes specific exclusion lists for their server roles, databases, and media storage paths. Apply them. StreamVault appliances ship with Aurora Protect pre-configured with the correct exclusions, if you replace it with a different product, all exclusions must be configured manually. 
 Host-based firewall policies should remain enabled and properly configured. Disabling the Windows Firewall to resolve application connectivity issues is a shortcut that introduces significant risk. Identify the specific ports that need to be open and add explicit rules. The firewall log will tell you what is being blocked. 
 Early detection can be the difference between a contained event and a full-scale incident. Visibility into what is running on your endpoints is the foundation of that early detection. 
 
 Putting It Together 
 Security systems exist to protect people, assets, and operations. The networks they run on deserve the same level of attention. 
 These controls are not complex and they do not require massive budgets. Most of them can be implemented with existing infrastructure and standard operational discipline. What they require is intent. Someone has to decide that the security network is worth securing. 
 If you are unsure where your environment stands, start with a review. Identify the gaps. Prioritize based on risk and feasibility. Address them systematically. The checklist at the top of this post gives you a starting framework. None of those items should be permanently red. 
 The systems that protect your organization should not be the weakest point in your network.

================================================================

## Security System Hardening Guide

URL: https://hans.study/standards-guidance/security-system-hardening-guide/
Type: kb
Date: 2026-05-11
Description: End-to-end hardening reference for physical security network infrastructure. Switches, servers, workstations, cameras, access control panels, RADIUS via NPS, vulnerability assessment, and checklists.

An end-to-end hardening reference for the infrastructure that physical security systems run on. Switches, servers, workstations, cameras, access control panels, centralized authentication, and the vulnerability assessment workflow that proves the work happened. Procedures use Windows-native tools where possible (Active Directory, Network Policy Server, Group Policy) so the controls are accessible to any organization with Windows Server licenses already on the shelf. 

 
 // VERIFY BEFORE DEPLOYING 
 CLI syntax varies by firmware version. Examples below are based on Cisco IOS-XE 17.x, Aruba AOS-CX 10.13+, Juniper Junos 21+, and ALE AOS R8. Always verify commands against the official documentation for your specific hardware and firmware version before deploying in production. Test in a lab environment first. 
 

 
 // STANDING ORDER 
 A device out of the box is designed to work. It is not designed to be secure. Security comes from configuration. 
 

 Contents 

 
 Introduction 
 Documentation 
 Part I, Network Architecture 
 Part II, Switch Hardening 
 Part III, Windows Domain and AAA 
 Part IV, Server Hardening 
 Part V, Workstation Hardening 
 Part VI, Cameras and IoT Hardening 
 Part VII, Access Control Panel Hardening 
 Part VIII, Vulnerability Assessment 
 Hardening Checklists 
 Vendor Hardening Resources 
 

 Introduction 

 Over 15 years of walking into physical security deployments, the infrastructure supporting the system is almost always in worse shape than anyone expects. 

 Switches running factory defaults. Servers with local admin accounts unchanged since installation. Workstations with passwords on sticky notes. Cameras with admin / admin credentials. No endpoint protection beyond whatever came with Windows. USB ports wide open. No screen lock policy. Systems that have not been patched in months. 

 These are systems protecting physical assets, running on infrastructure that nobody thought to protect. 

 About this guide 

 The procedures here use tools you already have or can get at no additional cost. Where possible the guide uses Windows-native solutions: Active Directory for centralized authentication, Network Policy Server (NPS) for RADIUS, Group Policy for configuration management. These ship with Windows Server and are sufficient for the vast majority of physical security deployments. 

 Commercial solutions like Cisco ISE, Aruba ClearPass, or dedicated TACACS+ servers are excellent when available. A domain controller running NPS is infinitely better than no centralized authentication at all. 

 Documentation 

 Documentation is not paperwork. It is operational intelligence. When something breaks at 2 AM, documentation tells you what should be there. When you inherit a system, documentation tells you what someone else built. When an incident occurs, documentation provides the baseline to understand what changed. 

 Why documentation matters 

 
 Accountability. Without documentation there is no proof of what was configured or when. 
 Troubleshooting. You cannot fix what you do not understand. Documentation provides context. 
 Continuity. People leave. Documentation stays. The next person should not have to reverse-engineer your work. 
 Compliance. Most frameworks require documented configurations and change management. 
 Baseline comparison. You cannot detect drift if you do not know what the baseline was. 
 

 What to document 

 
 
 Category Document Update frequency 
 
 
 Network VLAN assignments, IP schemes, topology diagrams After changes 
 Devices Asset inventory with make, model, serial, firmware, IP After changes 
 Configurations Switch configs, server settings, GPO exports After changes 
 Credentials Account list (not passwords), password vault location After changes 
 Procedures Backup procedures, recovery steps, escalation contacts Annually 
 Baseline scans Port scans, vulnerability scans, before / after comparisons After hardening 
 
 

 Configuration snapshots 

 Switch configurations 

```
# Cisco: export running config to TFTP
copy running-config tftp://10.99.0.50/configs/SW01.cfg

# Save running config to startup
copy running-config startup-config
```

 Windows Server baseline export 

```powershell
# Export installed roles and features
Get-WindowsFeature | Where-Object Installed | Export-Csv C:\Baseline\Features.csv

# Export local security policy
secedit /export /cfg C:\Baseline\SecurityPolicy.inf

# Export audit policy
auditpol /backup /file:C:\Baseline\AuditPolicy.csv

# Export GPO (on domain controller)
Backup-GPO -All -Path C:\Baseline\GPO
```

 Part I, Network Architecture 

 A flat network means every device can reach every other device. A compromised camera sits on the same broadcast domain as a workstation. An unplugged camera and a connected laptop have Layer 2 access to everything. Responder runs and credentials drop. Lateral movement to servers takes minutes. 

 VLANs change that. Devices in the same VLAN talk directly at Layer 2. Devices in different VLANs route through a Layer 3 device that can enforce access control. A compromised camera cannot directly reach a workstation. Bandwidth on one segment does not affect another. The blast radius of a compromise is contained. 

 Recommended VLAN structure 

 
 
 VLAN Name Purpose Example subnet 
 
 
 99 Management Switch mgmt, server BMC, admin access 10.99.0.0/24 
 100 Servers VMS servers, access control servers 10.100.0.0/24 
 101 CCTV IP cameras, encoders 10.101.0.0/23 
 102 Access_Control Door controllers, readers 10.102.0.0/24 
 103 Workstations Operator consoles 10.103.0.0/24 
 666 Blackhole Trunk native VLAN (never assign to ports) None 
 
 

 
 // SEE ALSO 
 For the full VLAN segmentation rationale, the conversation-with-the-client framing, and inter-VLAN routing examples, see VLAN Segmentation for Physical Security Networks . For the IP addressing scheme behind the VLAN layout, see IP Addressing for Security Integrators . 
 

 Part II, Switch Hardening 

 The universal controls below apply to every platform. Vendor syntax differs. The concepts do not. 

 
 Change default credentials before connecting to the network. 
 Enable AAA (RADIUS via NPS, or TACACS+ if available). 
 Disable Telnet. Enable SSH version 2 only. 
 Disable HTTP. Enable HTTPS, or disable web management entirely. 
 Configure port security on access ports (one MAC max, shutdown on violation). 
 Harden trunk ports (native VLAN 666, explicit allowed VLANs, no DTP). 
 Enable PortFast / edge ports and BPDU Guard on access ports. 
 Configure NTP from a trusted source. 
 Configure syslog to a centralized collector. 
 Save and back up the configuration. 
 

 Port security: why it matters 

 Cameras do not move. The same camera sits on the same port for years. Port security takes advantage of that predictability. The switch learns the camera's MAC on first connection. If someone unplugs the camera and connects their own device, the switch detects the new MAC and shuts down the port. The attack stops at the physical layer before it can begin. 

 Sticky MAC learning saves the learned MAC into the running configuration automatically. You do not enter MAC addresses by hand for every camera. Save the config after the cameras are commissioned and the MAC bindings persist. 

 
 // STANDING ORDER 
 Enable port security on every access port. One MAC address maximum for camera ports. Violation action: shutdown. 
 

 Vendor-specific configurations 

 Full base configurations including SSH, AAA, port security, BPDU Guard, NTP, syslog, and trunk hardening are documented per platform: 

 
 Cisco Catalyst 9200 / 9300 base configuration (IOS-XE) 
 Aruba CX base configuration (AOS-CX) 
 ALE OmniSwitch base configuration (AOS R8) 
 Juniper EX base configuration (Junos) 
 

 The Switch Configuration Generator produces a starting template for any of those four platforms from a VLAN scheme and management addressing. 

 Part III, Windows Domain and AAA 

 Network device administration depends on accounts. Local switch accounts work for a single switch. They do not scale. When someone leaves the team, you change 40 passwords on 40 switches. When you cannot remember which administrator touched what, the audit log on the switch shows only the username, with no centralized record. A centralized authentication source fixes both problems. 

 Why use a domain 

 If the deployment has more than a handful of systems (multiple servers, multiple workstations), a Windows domain provides centralized management that standalone systems cannot match: 

 
 Centralized authentication. One set of credentials for all systems. Disable a user in one place, disabled everywhere. 
 Group Policy. Push security settings from one console. No manual configuration of each machine. 
 LAPS. Automatic local administrator password management stored in Active Directory. 
 Audit logging. Centralized event collection. See who logged in where and when. 
 Certificate Services. Internal CA for issuing certificates to servers, cameras, and services. 
 NPS / RADIUS. Network devices authenticate against Active Directory accounts. 
 

 
 // WHEN TO USE A DOMAIN 
 Two servers and two workstations? Consider a domain. The overhead is minimal and the benefits compound as you grow. One server and one workstation? Standalone is fine, but document local accounts carefully. 
 

 Network Policy Server (NPS) for RADIUS 

 NPS is the Windows implementation of RADIUS. It ships with Windows Server. It lets network devices (switches, wireless APs, VPN concentrators) authenticate users and devices against Active Directory. 

 For switch management, NPS lets administrators log into switches using their AD credentials instead of local switch accounts. When someone leaves, you disable the AD account once. No password changes on 40 switches. 

 Step 1: install the NPS role 

```powershell
Install-WindowsFeature NPAS -IncludeManagementTools
```

 Step 2: register NPS in Active Directory 

```powershell
# Run on the NPS server
netsh ras add registeredserver
```

 Or in the NPS console: right-click NPS (Local) and choose Register Server in Active Directory . 

 Step 3: add RADIUS clients (the switches) 

 In the NPS console: RADIUS Clients and Servers, RADIUS Clients, New . 

 
 Friendly name: SEC-SW-01 
 Address: 10.99.0.21 (the switch management IP) 
 Shared secret: generate a strong secret; configure the same value on the switch. 
 

 Step 4: create the network policy 

 In the NPS console: Policies, Network Policies, New . 

 
 Policy name: Switch-Admin-Access 
 Condition: Windows Groups = Network-Admins (your AD group) 
 Condition: NAS Port Type = Ethernet 
 Constraint: authentication methods = PAP, CHAP, MS-CHAPv2 
 Setting: Standard RADIUS attribute Service-Type = Administrative 
 

 Switch-side RADIUS configuration 

 The matching switch configuration (Cisco example, NPS at 10.100.0.10): 

```
aaa new-model

radius server NPS-PRIMARY
 address ipv4 10.100.0.10 auth-port 1812 acct-port 1813
 key 0 <RADIUS-SECRET>

aaa group server radius NPS_GROUP
 server name NPS-PRIMARY

aaa authentication login default group NPS_GROUP local
aaa authorization exec default group NPS_GROUP local
aaa accounting exec default start-stop group NPS_GROUP
```

 Equivalent commands for Aruba CX, ALE OmniSwitch, and Juniper EX appear in the per-platform base configuration KB entries linked above. 

 Group Policy for centralized hardening 

 Group Policy pushes configuration to domain members automatically. Create a GPO for security hardening, link it to the appropriate Organizational Unit, and every system in that OU gets the settings. No manual configuration. No missed systems. 

```powershell
# Create a hardening GPO
New-GPO -Name "Security-Hardening-Servers" -Comment "Server hardening baseline"

# Link to OU
New-GPLink -Name "Security-Hardening-Servers" -Target "OU=Servers,DC=security,DC=local"

# Export the GPO for documentation and version control
Backup-GPO -Name "Security-Hardening-Servers" -Path "C:\GPO-Backups"
```

 
 // SEE ALSO 
 For the full GPO settings catalogue (account policies, screen lock, LLMNR, command-line logging, Defender, and Copilot/Recall controls) see Hardening Windows Server: Group Policy Baseline . For the audit policy that the GPO enforces, see Hardening Windows Server: Audit Logging . 
 

 Part IV, Server Hardening 

 The VMS server is the most critical system in the deployment. It stores video, manages cameras, and handles client connections. Compromise the VMS server and the attacker owns the entire system. 

 Account management 

 
 Disable the built-in Administrator account; use named accounts. 
 Deploy LAPS for local admin password management. 
 Account lockout: 5 attempts, 15 minute duration. 
 Password policy: 14 characters minimum. 
 

 Protocol hardening 

 
 Disable SMBv1 (EternalBlue, WannaCry). 
 Disable TLS 1.0 and 1.1 (POODLE, BEAST). 
 Disable LLMNR (Responder attacks). 
 Disable NetBIOS over TCP/IP (NBT-NS poisoning). 
 

 Credential protection 

 
 Enable Credential Guard (requires TPM 2.0, UEFI, Secure Boot). 
 Enable LSA Protection (RunAsPPL). 
 

 VMS-specific 

 
 Configure Defender exclusions for VMS paths (live recording directories). 
 Use service accounts with minimum privileges. 
 Use gMSA where supported for automatic password rotation. 
 

 
 // SEE ALSO 
 Full procedures are documented in the four-part Windows Server hardening series: Getting Started , Group Policy Baseline , Audit Logging , and Other Considerations (TLS, RDP, SMB signing, LAPS, PKI). 
 

 Part V, Workstation Hardening 

 
 Screen lock at 15 minutes. 
 AutoRun and AutoPlay disabled. 
 ASR rules enabled (block Office macros, script launching, credential stealing). 
 Copilot and Recall disabled (Windows 11). 
 Power plan: High Performance (no sleep or hibernate on operator consoles). 
 Domain joined where a domain is available, or LAPS-managed local admin. 
 

 
 // USE THE TOOL 
 The Workstation Hardening Config Generator produces a SHA-256 fingerprinted PowerShell script that applies the controls above plus 27 verified AppX debloat targets. Every control is sourced to DISA STIG, CIS Benchmark L1, NSA/CISA, or CSE/CCCS guidance. 
 

 Part VI, Cameras and IoT Hardening 

 Cameras are computers running embedded operating systems. Most ship with default credentials, default services enabled, and firmware that has not been updated since the camera was manufactured. They face the most exposure on a security network and get the least attention. 

 Camera baseline 

 
 Change default credentials before connecting the camera to the network. 
 Disable Telnet, FTP, UPnP, Bonjour, mDNS, and SNMP v1 / v2. 
 Enable HTTPS. Disable HTTP. 
 Set the camera time source to the same NTP server the rest of the system uses. 
 Update firmware on commissioning and quarterly thereafter. 
 Isolate cameras on a dedicated VLAN with no route to the internet. 
 Block outbound connections at the firewall; cameras do not need to call home. 
 Enable ONVIF authentication; never run ONVIF in anonymous mode. 
 

 Common default credentials to eliminate 

 
 Manufacturer Defaults to clear 
 
 Axis root / pass, root / root (older firmware ships unset and requires first-boot setup; verify) 
 Hikvision admin / 12345 
 Dahua admin / admin 
 Bosch service / service 
 Hanwha admin / 4321 
 
 

 VMS integration considerations 

 
 Use a dedicated service account on each camera for VMS connections. Do not use the admin account. 
 Restrict the service account to view, PTZ control, and event subscription. No firmware update rights. 
 Use TLS for the RTSP stream if the camera and VMS support it. Genetec, Milestone, Avigilon, and Hanwha all support TLS-encrypted streams on current versions. 
 Verify the VMS server is the only system in the camera's allow-list for management access. 
 

 
 // STANDING ORDER 
 A camera reaching out to the internet is a finding. There is no legitimate reason for a CCTV camera to talk to anything outside the building. Egress filtering on the camera VLAN catches this and proves it. 
 

 Part VII, Access Control Panel Hardening 

 Access control panels run firmware. They have web interfaces. They have default credentials. They are network-attached computers that happen to drive door locks. They get hardened the same way. 

 Panel baseline 

 
 Change default controller credentials immediately. 
 Disable any web interface that does not enforce HTTPS. 
 Enable OSDP v2 with Secure Channel on all readers. Disable legacy Wiegand wherever the hardware supports OSDP. 
 Isolate panels on a dedicated VLAN; access from the access-control server only. 
 Enable tamper detection on the panel enclosure. Supervised input. 
 Supervise every input with DEOL (1k + 1k on Mercury hardware, or per the panel vendor's spec). 
 Update firmware on commissioning and at every vendor security advisory. 
 Configure the panel to log to the central syslog collector. 
 

 OSDP v2 specifics 

 
 Enable Secure Channel on every reader; install per-reader keys. 
 Disable OSDP install mode after commissioning so an attacker cannot swap a reader and re-pair. 
 Address each reader explicitly; never run with the default broadcast address. 
 Verify the reader supports OSDP v2.2. The earlier OSDP v1 had a key-derivation weakness. 
 

 Supervised inputs 

 End-of-line (EOL) resistors at the device end give the panel four-state input detection: normal, alarm, cut, and short. Wiring at the panel defeats this. Mercury hardware (Genetec Synergis, Lenel S2, Avigilon ACM, S2 NetBox, Mercury MR subpanels and MP, LP, or EP controllers) defaults to 1k + 1k Dual EOL. Other panels use different values; verify against the panel documentation. 

 
 // SEE ALSO 
 The Conductor Calculator generates the BOM for a door including the EOL resistor count and value matched to the panel hardware. For the head-end and door hardware standards behind the cable list, see Canadian Security Install Reference , chapters 12 (head-end) and 13 (at the door). 
 

 Part VIII, Vulnerability Assessment 

 Before and after. That is the discipline. Before hardening, document what is there. After hardening, verify what changed. This creates accountability and demonstrates the value of the work. 

 Baseline scanning 

 When walking into an existing network, start with discovery. What devices are there? What ports are open? What services are running? 

```bash
# Discover live hosts on a subnet
nmap -sn 10.101.0.0/24 -oN baseline-discovery.txt

# Service scan of discovered hosts
nmap -sV -sC 10.101.0.0/24 -oN baseline-services.txt

# Targeted scan of a switch's management ports
nmap -sV -p 22,23,80,443,161 10.99.0.21 -oN switch-baseline.txt
```

 Windows security baseline checks 

```powershell
# SMBv1 status
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol

# Account lockout policy
net accounts

# Audit policy
auditpol /get /category:*

# Windows Firewall status
Get-NetFirewallProfile | Select-Object Name, Enabled

# LLMNR status
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMulticast -ErrorAction SilentlyContinue
```

 After hardening, verify 

 Re-run the same scans. Compare. Telnet should now be closed. HTTP should be gone. SMBv1 should be disabled. SSH should remain open. Document the before and after. 

```bash
# Compare switch before / after
diff switch-baseline.txt switch-hardened.txt

# Expected changes:
# Port 23 (Telnet) open -> closed
# Port 80 (HTTP) open -> closed
# Port 22 (SSH) open (unchanged)
```

 
 // STANDING ORDER 
 Save baseline scans. Save post-hardening scans. Store both with the project documentation. When someone asks what you did, show them. 
 

 Hardening Checklists 

 Network infrastructure 

 
 Default credentials changed on all devices. 
 AAA configured (NPS / RADIUS or TACACS+). 
 Telnet disabled. SSH enabled. 
 HTTP disabled. 
 VLANs implemented per design. 
 Port security enabled on access ports. 
 PortFast / edge ports and BPDU Guard on access ports. 
 Trunk native VLAN set to 666 (or other unused VLAN). 
 DTP disabled on all ports (Cisco). 
 NTP configured against a trusted source. 
 Syslog configured to a central collector. 
 Configuration saved and backed up off-device. 
 Baseline port scan saved. 
 

 Windows Server 

 
 Domain joined where deployment has more than one server. 
 Built-in Administrator disabled. 
 LAPS deployed. 
 Account lockout policy configured. 
 Advanced Audit Policy enabled. 
 Command-line logging enabled. 
 SMBv1 disabled. 
 TLS 1.2 / 1.3 only. 
 LLMNR disabled. 
 NetBIOS over TCP/IP disabled. 
 Credential Guard enabled. 
 Windows Firewall enabled on all profiles. 
 VMS Defender exclusions configured per the VMS vendor's documentation. 
 

 Workstations 

 
 Domain joined or LAPS-managed local admin. 
 Screen lock at 15 minutes. 
 AutoRun / AutoPlay disabled. 
 ASR rules enabled. 
 Copilot / Recall disabled. 
 Power plan: High Performance. 
 

 Cameras 

 
 Default password changed. 
 Firmware current. 
 Telnet, FTP, UPnP, mDNS disabled. 
 HTTPS enabled. HTTP disabled. 
 On the dedicated CCTV VLAN. 
 Outbound internet blocked. 
 VMS service account in use (not admin). 
 

 Access control panels 

 
 Default credentials changed. 
 OSDP v2 with Secure Channel enabled. 
 OSDP install mode disabled after commissioning. 
 Tamper detection wired and supervised. 
 Inputs supervised with DEOL at the device end. 
 Firmware current. 
 Logging to central syslog collector. 
 

 Documentation 

 
 Network diagram current. 
 VLAN assignments documented. 
 IP scheme documented. 
 Asset inventory complete (make, model, serial, firmware, IP). 
 Switch configs backed up off-device. 
 GPO backups exported. 
 Baseline scans saved. 
 Post-hardening scans saved. 
 Credential vault location documented. 
 

 Vendor Hardening Resources 

 Video management systems 

 
 Genetec: resources.genetec.com (search for hardening guides per Security Center version). 
 Milestone: doc.milestonesys.com (search for "hardening"). 
 Avigilon: partner portal documentation. 
 Hanwha: hanwhavision.com/cybersecurity. 
 

 Camera manufacturers 

 
 Axis: help.axis.com (AXIS OS Hardening Guide). 
 Bosch: boschsecurity.com (product security advisories). 
 

 Network infrastructure 

 
 Cisco: sec.cloudapps.cisco.com (security advisories). 
 Aruba: arubanetworks.com (security bulletins). 
 Juniper: supportportal.juniper.net (security advisories). 
 Alcatel-Lucent Enterprise: al-enterprise.com (security advisories and AOS release notes). 
 

 Standards and frameworks 

 
 CIS Benchmarks: cisecurity.org/cis-benchmarks. 
 NIST Cybersecurity Framework: nist.gov/cyberframework. 
 Microsoft Security Baselines: learn.microsoft.com (search for "Security Configuration Framework"). 
 DISA STIG Library: public.cyber.mil (search for Windows or Cisco STIG).

================================================================

## Switch Configuration Audit Checklist for CCTV and Access Control Networks

URL: https://hans.study/standards-guidance/switch-configuration-audit-checklist-for-security-networks/
Type: kb
Date: 2026-09-03
Description: The checklist behind the switch config audit tool: management plane, control plane, edge protection, VLAN hygiene, PoE, multicast, QoS, logging, and the evidence to collect for each, with the show commands that prove it on Cisco, Aruba CX, and Junos.

The switch config audit tool on this site reads a running configuration and flags what is missing against a security-network baseline. This is the checklist it works from, written out so that it can be applied by hand on a platform the tool does not parse, handed to an integrator as an acceptance test, or used to read a config the way I read one on a network assessment . 
 The order is deliberate. Management plane first, because a switch anyone can log into makes every other control optional. Then the control plane, then the edge, then the things that are specific to carrying video and doors. 
 Each item has the evidence to collect. An audit finding without the command output behind it is an opinion. 
 

 1. Management plane 
 
 Check Pass condition Evidence 
 
 Telnet and HTTP disabled Only SSHv2 and HTTPS accept management sessions show ip ssh , show run | i transport|ip http 
 Management restricted by ACL VTY and web sessions accepted only from the management subnet show run | s line vty , ACL contents 
 Centralised authentication AAA against RADIUS or TACACS+, local account as fallback only, no shared local accounts show aaa servers , show run | s aaa|username 
 Local fallback account One, with a unique per-switch password that is stored somewhere other than the config Username count; password type is 8 or 9, never 7 
 Privilege levels Operators cannot reach configuration mode; enable secret set and hashed show run | i enable|privilege 
 SNMP SNMPv3 only, authPriv; v1 and v2c communities absent show snmp user , show run | i snmp-server community 
 Management VLAN Dedicated, not VLAN 1, not the camera VLAN, not routed to the user network show ip interface brief , VLAN plan 
 Session timeout Idle sessions close within ten minutes show run | s line , exec-timeout 
 Login banner Present; states authorised use only show banner 
 Firmware Current recommended release from the vendor, or a documented reason show version against the vendor's advisory list 
 
 
 

 2. Services and time 
 
 Check Pass condition Evidence 
 
 NTP Two or more sources, authenticated where the platform supports it, and the switch is actually synchronised show ntp status , show ntp associations 
 Logging Syslog to at least one collector on the management VLAN; timestamps with millisecond precision and timezone; buffered log sized show logging 
 Unused services CDP and LLDP off on camera-facing ports unless PoE negotiation needs LLDP; no finger, no small servers, no source routing show run | i cdp|lldp|service 
 Configuration backup Running config archived to a server on change; last archive within the change window show archive or equivalent; backup server listing 
 
 
 

 3. Control plane 
 
 Check Pass condition Evidence 
 
 Spanning tree mode Rapid PVST or MSTP; the root bridge is the core, set by explicit priority, not by lowest MAC show spanning-tree root , show spanning-tree summary 
 Edge ports PortFast or edge on every camera and door controller port; BPDU Guard on every edge port show spanning-tree interface ... detail , show run | i portfast|bpduguard 
 Uplink protection Root Guard on ports facing access switches from the distribution; Loop Guard on uplinks show spanning-tree inconsistentports 
 Storm control Broadcast limited on every edge port; multicast threshold set with the video load in mind or not applied to video ports show storm-control 
 Control plane policing Present on platforms that support it show policy-map control-plane 
 
 
 

 4. Edge and access 
 
 Check Pass condition Evidence 
 
 Unused ports Administratively down and in an unused black-hole VLAN, not VLAN 1 show interfaces status ; count of notconnect ports in an active VLAN 
 Port security or 802.1X Camera and door ports authenticate the device: 802.1X with MAB fallback, or at minimum port security with a sticky MAC and a violation action show authentication sessions , show port-security 
 DHCP snooping Enabled on camera and access VLANs; trust only on uplinks and the DHCP server port show ip dhcp snooping 
 Dynamic ARP inspection Enabled on the same VLANs, with the same trust show ip arp inspection 
 IP Source Guard Enabled on edge ports where the platform supports it with the DHCP snooping binding table show ip verify source 
 Port descriptions Every port describes what is on it: camera name, door name, uplink target show interfaces description ; blank descriptions counted 
 Speed and duplex Auto on both ends, or forced on both ends; never mixed show interfaces for duplex mismatches and late collisions 
 
 
 

 5. VLAN hygiene 
 
 Check Pass condition Evidence 
 
 Segmentation Cameras, access control, servers, management, and operator workstations in separate VLANs, per the segmentation guide show vlan brief against the VLAN plan 
 VLAN 1 No ports assigned; not the native VLAN on any trunk; not the management VLAN show vlan id 1 , show interfaces trunk 
 Native VLAN An unused, dedicated VLAN on every trunk; tagged where the platform allows show interfaces trunk 
 Trunk pruning Trunks carry only the VLANs the far end needs; no allowed vlan all show interfaces trunk 
 Trunk negotiation DTP off; trunks configured statically; access ports set to nonegotiate show interfaces switchport ; Negotiation of Trunking: Off 
 Inter-VLAN routing Only where the design says so, through the firewall or an ACL on the SVI, with the camera VLAN unable to initiate to anything but the Archivers SVI ACLs; firewall policy 
 
 
 

 6. Video and access control specifics 
 
 Check Pass condition Evidence 
 
 PoE budget Allocated power below the supply's budget with 20 percent headroom at winter peak; priority set by what the port covers; budget alert configured. Details in the PoE guide show power inline ; supply model and mode 
 LLDP for PoE Enabled on camera ports; allocation by negotiation rather than by class show power inline ... detail ; allocated versus drawn 
 IGMP snooping and querier Snooping on the video VLAN; a querier on every switch in it. Details in the multicast guide show ip igmp snooping querier 
 Jumbo frames Consistent end to end on any iSCSI storage path; not enabled on camera VLANs without a reason show system mtu , interface MTU 
 QoS DSCP trusted from cameras and Archivers; video marked and queued ahead of best-effort; access control marked ahead of video show mls qos or show policy-map interface 
 Uplink capacity Aggregate camera bitrate per switch below 60 percent of uplink capacity; uplinks in a port channel where two exist Interface utilisation over a week; show etherchannel summary 
 Redundant power Dual supplies on distribution and on any access switch feeding doors; mode documented show environment power 
 
 
 

 The platform commands 
 The evidence column above is Cisco IOS-XE syntax. The equivalents on the other platforms this site carries templates for: 
```
 Cisco IOS-XE Aruba AOS-CX Junos
Running config show running-config show running-config show configuration
Interface status show interfaces status show interface brief show interfaces terse
Trunks show interfaces trunk show vlan port show vlans
Spanning tree show spanning-tree summary show spanning-tree summary show spanning-tree bridge
Port security / 802.1X show authentication sessions show port-access clients show dot1x interface
DHCP snooping show ip dhcp snooping show dhcpv4-snooping show dhcp-security binding
PoE show power inline show power-over-ethernet brief show poe interface
IGMP querier show ip igmp snooping querier show ip igmp snooping vlan show igmp snooping membership
NTP show ntp status show ntp status show ntp status
Logging show logging show logging show log messages | last 50
```
 

 Scoring and what to do with the result 
 Not every failed check is the same finding. I score them in three bands. 
 
 Fix before anything else. Telnet or HTTP management, SNMPv2 communities, VLAN 1 in use, no AAA, missing BPDU Guard on edge ports, unused ports live in an active VLAN. Any one of these means the switch can be taken by whoever plugs into a lobby port. 
 Fix in the next change window. No querier, no PoE headroom, no port security, trunks unpruned, no DHCP snooping, storm control absent, logging local only. These are the outages waiting to happen and the gaps an incident investigation will find. 
 Fix as the estate is touched. Descriptions, banner, QoS refinement, config archive cadence. Real, but not the reason to open a window. 
 
 The point of running the checklist is the delta between what the config says and what the drawing says. On a network I have not seen before, that delta is the fastest possible description of how the system has been maintained, and it tells me most of what the rest of the assessment is going to find. 
 The full baselines that pass every item above are the Cisco Catalyst , Aruba CX , Juniper EX , and OmniSwitch templates.

================================================================

## TIA-568 Structured Cabling: Reference for Security Networks

URL: https://hans.study/standards-guidance/tia-568-structured-cabling-reference/
Type: kb
Date: 2026-05-09
Description: What TIA-568 actually requires for the cabling that physical security systems run on, and where integrators commonly fall short of it.

TIA-568 is the structured cabling standard that governs the cable, connectors, and topology of the network most physical security systems run on. The standard itself is a set of documents (TIA-568.0 through TIA-568.5) maintained by the Telecommunications Industry Association. The current revision is TIA-568-E, published in 2020 and amended through 2024. 

 This entry is a working reference. It is not a substitute for the standards themselves. If you are designing or specifying cabling that will be commissioned and tested against TIA-568, the actual standard is what the test report will be measured against. 

 

 What the standard covers 

 
 TIA-568.0: Generic cabling for customer premises. Defines the overall topology and the role of horizontal and backbone cabling. 
 TIA-568.1: Commercial building telecommunications cabling. The "what goes in a building" document. 
 TIA-568.2: Balanced twisted-pair (copper) components. Cat6, Cat6A, Cat8 specifications. 
 TIA-568.3: Optical fibre cabling components. OM3, OM4, OM5, OS2 specifications. 
 TIA-568.4: Broadband coaxial cabling. 
 TIA-568.5: Single-pair Ethernet. Newer, relevant for some IoT and OT scenarios. 
 

 What this means for security networks 

 For most physical security deployments, the cabling work falls under TIA-568.1 (building cabling) and TIA-568.2 (copper) or TIA-568.3 (fibre). The relevant decisions are: 

 
 Category selection: Cat6A is the right choice for new IP camera and access control runs. Cat6 is acceptable for shorter runs, but Cat6A is required for sustained 10GBASE-T at 100 metres and handles PoE++ better. 
 Channel length: 90 metres of horizontal cable plus 10 metres of patch cords, total 100 metres end to end. Camera runs that exceed this need fibre or an intermediate switch. 
 Test reports: Permanent link or channel testing per TIA-568 must be part of the commissioning package. Without it, you have no objective evidence the cabling meets spec. 
 Pathway separation: Power and data separation is referenced through TIA-569 (pathways and spaces), not TIA-568 directly. Many integrators conflate the two. 
 

 Common gaps in the field 

 Where deployments fall short of TIA-568 in practice: 

 
 No test reports delivered at commissioning, or test reports that show only continuity rather than the full Permanent Link or Channel parameter set. 
 Cable runs that exceed 100 metres without an intermediate switch or fibre handoff. 
 Cat5e specified in environments that should have been Cat6A from the start. 
 Incorrect bend radius or excessive cable tension during install. 
 Missing or incorrect grounding on shielded (F/UTP, S/FTP) cabling. 
 

 What to ask for in an RFP or scope of work 

 
 Cable category and minimum performance class (e.g., "Cat6A meeting TIA-568.2-E Class EA"). 
 Permanent Link or Channel testing per TIA-568 with results provided in machine-readable format (commonly .flw or .pdf from Fluke or similar testers). 
 Labelling per TIA-606 (the labelling and administration standard, often paired with TIA-568 in scopes). 
 Conduit and pathway specifications per TIA-569 if pathway is in scope. 
 

 

 This entry is a starting reference. Specific projects may need additional analysis around fibre type selection (OM3 vs OM4 vs OM5), single-pair Ethernet considerations for building automation, or labelling and administration. The Knowledge Base will expand to cover these as the source material is worked through.

================================================================

## vlan-segmentation-physical-security-networks

URL: https://hans.study/standards-guidance/vlan-segmentation-physical-security-networks/
Type: kb
Date: 
Description: 

The segmentation conversation is one I have had hundreds of times. Usually after something has already gone wrong. A workstation on the same network as the cameras gets compromised and someone starts wondering why the VMS server is behaving strangely. Or an access control system stops responding and the root cause turns out to be bandwidth saturation from a camera on the same flat network. Or someone connects an unauthorized device to a switch and it ends up with full access to everything because there was nothing stopping it. 

 Segmentation is not a complicated concept. It is one of the most consistently skipped steps in physical security deployments, usually because it adds time and the client cannot see what they are getting. This post covers what VLANs actually do, how to build a practical segmentation scheme for a security deployment, and how to have the conversation with a client who does not understand why it matters. 

 

 What a VLAN Actually Does 

 A VLAN, Virtual Local Area Network, creates logically separate network segments on the same physical infrastructure. Devices in different VLANs cannot communicate with each other unless traffic is explicitly routed between them by a Layer 3 device (a firewall or a Layer 3 switch). 

 Without VLANs, every device on the same switch can reach every other device. A camera can reach a workstation. A door controller can reach a server. An unknown device plugged into an unused port has access to the entire network. That is a flat network, and it is the default state of every unmanaged or improperly configured switch. 

 With VLANs, you decide which devices can reach which other devices. Cameras live in the camera VLAN. Access control panels live in the access control VLAN. Servers live in the systems VLAN. Each segment is isolated. A compromise on one segment does not automatically spread to the others. 

 
 
 Network Architecture: Before and After Segmentation 

 
 

 
 ⚠ Before: Flat Network 
 ✓ After: Segmented 
 

 

 
 
 
 VLAN 1 (DEFAULT), ALL DEVICES CAN REACH ALL OTHER DEVICES 
 RISK 
 
 
 
 
 Every device can reach every other device. The unknown device has full access. 
 

 
 
 
 
 ✓ 
 VLAN 101 
 CCTV 
 
 Camera ×8 
 NVR 
 
 
 
 ✓ 
 VLAN 102 
 Access Control 
 
 AC Panel ×4 
 Controller 
 
 
 
 ✓ 
 VLAN 100 
 Systems 
 
 VMS Server 
 Workstation ×2 
 
 
 
 ✓ 
 VLAN 99 
 Management 
 
 Switch Mgmt 
 Firewall 
 
 
 
 Segments are isolated. An unknown device on VLAN 101 cannot reach access control or workstations. 
 

 
 
 

 The toggle above shows the difference. On the flat network, the animated lines represent traffic that can flow between any pair of devices, and does, whether you want it to or not. On the segmented network, each function lives in its own box. Traffic stays where it belongs. An unknown device that gets physically connected to a camera port can only reach other cameras, not servers, not workstations, not access control panels. 

 

 Why Default VLAN 1 Is a Problem 

 Every managed switch ships with all ports in VLAN 1. That is the default. If you deploy a switch and do not configure VLANs, every device connected to every port is on the same flat network. This is the state of a large percentage of physical security deployments. 

 VLAN 1 has a specific additional problem beyond just being flat: it is the target of several well-documented Layer 2 attack techniques, including VLAN hopping via Double Tagging. The short version is that if you put traffic on VLAN 1 and an attacker can connect a device to a trunk port or an improperly configured access port, they may be able to send traffic across to VLANs you thought were isolated. 

 The defensive practice is straightforward: do not put production traffic on VLAN 1. Keep it around (you cannot easily remove it) but do not assign any device to it. Every real device goes on a defined VLAN. Unused ports go in a blackhole VLAN with no routing and no services. 

 

 A Practical VLAN Scheme for Security Deployments 

 
 
 
 VLAN 
 Name 
 Purpose 
 Devices 
 
 
 
 
 1 
 DEFAULT 
 Unused, native VLAN kept for compatibility 
 No devices 
 
 
 99 
 MANAGEMENT 
 Switch management interfaces, out-of-band access 
 Switches, UPS network cards, IPMI interfaces 
 
 
 100 
 SYSTEMS 
 Security system servers and workstations 
 VMS servers, workstations, NVR systems 
 
 
 101 
 CCTV 
 IP camera traffic 
 Cameras, perimeter detection devices 
 
 
 102 
 ACCESS CTRL 
 Access control system traffic 
 Door controllers, panels, intercoms 
 
 
 666 
 BLACKHOLE 
 Unused ports, not routed, no services 
 No devices assigned, all unused ports 
 
 
 

 These VLAN numbers are not magic. The specific numbers do not matter as much as the consistency. What matters is that every device type has its own segment, unused ports have a dead-end VLAN, and the management plane is completely isolated from production traffic. 

 If your deployment includes VoIP, add a dedicated VOIP VLAN. If there are business workstations on the same infrastructure, add a USERS VLAN. Each function with different security requirements or different traffic characteristics gets its own segment. 

 
 If business systems share the network: Any deployment where corporate workstations, printers, or general-purpose user devices share the same physical network as security systems requires segmentation between those user devices and the security infrastructure. A compromised workstation on a flat network has direct access to cameras, access control panels, and VMS servers. If the client understands this and still does not want segmentation, document it in writing. 
 

 

 The Routing Question 

 Segmented VLANs cannot talk to each other unless you explicitly route between them. This is a feature, not a problem. But it does require planning, because some communication between VLANs is necessary. Cameras on VLAN 101 need to reach the VMS server on VLAN 100 to send their video streams. The workstations on VLAN 100 need to reach the access control server, also on VLAN 100 in this scheme, to administer the system. 

 Inter-VLAN routing happens at a Layer 3 device, either a managed switch with Layer 3 capabilities or a firewall. The firewall is the better choice for physical security environments because it lets you define explicit rules: cameras can reach servers on specific ports, servers can reach cameras on specific ports, and nothing else is permitted unless you say so. 

 A common setup: all VLANs route through the firewall. The firewall has a policy that allows cameras to talk to VMS servers on the ports VMS requires (usually TCP 554 for RTSP, TCP 443 for HTTPS management, and whatever your platform uses). Everything else, cameras trying to reach workstations, cameras trying to reach the internet, anything trying to reach the management VLAN from cameras, is denied. 

 If you do not have a firewall in the design, a Layer 3 switch with ACLs between VLANs achieves similar isolation. It is slightly less granular than a firewall ruleset but considerably better than no segmentation at all. 

 

 Trunk Ports and Access Ports 

 Two port types on a managed switch handle VLANs differently. 

 Access ports carry traffic for a single VLAN. Cameras plug into access ports. Door controllers plug into access ports. The device on the other end does not need to know anything about VLANs, the switch handles the VLAN tagging. A camera plugged into a port configured as a VLAN 101 access port is simply on VLAN 101. It does not know about any other VLAN. 

 Trunk ports carry traffic for multiple VLANs using 802.1Q tagging. Trunk ports connect switches to each other and connect switches to firewalls. The uplink from your access layer switch to your core switch or firewall is a trunk. Every VLAN that needs to pass between those two devices is allowed on that trunk. 

 A trunk port that allows all VLANs by default is a security gap. Define which VLANs are permitted on each trunk and allow only what is needed. If the camera switch only needs VLANs 99, 100, and 101, the trunk to that switch should only carry 99, 100, and 101. 

 

 The Client Conversation 

 Most clients do not ask for VLAN segmentation. They ask for cameras and access control. Your job is to explain why the network design affects the security outcome they are paying for. 

 The version that works in practice: "We're going to put the cameras and the access control panels on separate network segments. That means if something goes wrong with the camera network, a device gets compromised, someone plugs in something they shouldn't, it can't reach your access control system or the workstations the operators use. The systems stay isolated from each other." Most clients understand that immediately. They are spending money on physical security. The idea that the network those systems run on is secure by default is an assumption they have not tested. 

 
 Document the segmentation design as part of the project deliverables. Which VLAN each device is assigned to, which VLANs are permitted on each trunk, and what routing policy exists between VLANs should all be in your as-built documentation. When something breaks eighteen months later, that documentation is how you figure out why. 
 

 

 What Comes Next 

 VLAN segmentation is part of the design. The implementation is a separate topic: switch configuration, port assignments, trunk setup, and routing policy are covered in the post on building a network for CCTV and access control . The IP addressing reference covers the addressing scheme that makes the VLAN design readable and maintainable. If you have not read that one, it is worth going through before you sit down to design the segmentation. 

 Questions about a specific deployment or platform, reach out directly.

================================================================

## Windows Event Forwarding for Security Systems: Collector Design, Subscriptions, and What to Forward From VMS and Access Control Hosts

URL: https://hans.study/standards-guidance/windows-event-forwarding-for-security-systems/
Type: kb
Date: 2026-09-02
Description: Where the logs go after audit policy is set: collector sizing, source-initiated subscriptions by Group Policy, the query XML that pulls the right events from VMS and access control hosts, and the checks that prove forwarding is alive.

The audit logging guide ends with logs that are correctly generated, correctly sized, and sitting on the server that produced them. That is where most security systems stop, and it is not far enough. A log on the host that was compromised is a log the attacker can clear, and event 1102 will tell you it happened, right up to the moment they clear that too. The logs have to leave the host, and on a Windows estate the free, supported, built-in way to make that happen is Windows Event Forwarding. 
 This page is the design and the configuration for a security system estate: the video servers, the access control servers, the domain controllers they authenticate against, and the operator workstations. It assumes the audit policy from the earlier guide is in place. Forwarding an event that was never generated is not a thing. 
 

 Why WEF and not an agent 
 Every SIEM vendor sells an agent, and on a general IT estate the agent is often the right call. On a security system estate there are reasons to prefer WEF as the first hop, with the SIEM reading from the collector: 
 
 No third-party software on the video and access control hosts. Vendors qualify their platforms against a Windows build, not against a Windows build plus whatever agent the security team chose. WEF is part of Windows. 
 The transport is WinRM over HTTPS with Kerberos, which the hosts already speak. 
 Source-initiated subscriptions mean the hosts push to the collector. Nothing on the collector needs credentials to reach into a VMS server, which is the correct direction for trust to flow. 
 When the SIEM contract changes, the collector stays and only the last hop changes. 
 
 The trade-off is that WEF is Windows-only and it is not real-time in the sense an agent can be; a few seconds to a minute of delay is normal. For a security system that is acceptable. For a trading floor it might not be. 
 

 Collector design 
 The collector is a Windows Server with the Windows Event Collector service running, a large ForwardedEvents log on its own volume, and nothing else on it. It is not the SIEM, it is not a domain controller, and it is not the VMS management server. It is a log target, and it should be hardened like one, because it is where the evidence goes. 
 Sizing. A VMS or access control host with the recommended audit policy produces on the order of tens of megabytes of security events a day; a domain controller produces far more; a workstation produces less. Add up the estate, multiply by the retention you want on the collector (30 days is a sensible minimum, with the SIEM holding the long tail), and size the ForwardedEvents log and its volume to that with headroom. Put the log on a volume separate from the OS so that a burst of events cannot fill the system drive. 
```
# On the collector: enable the collector service and size the forwarded log
wecutil qc /q
wevtutil sl ForwardedEvents /ms:34359738368
wevtutil sl ForwardedEvents /lfn:"L:\Logs\ForwardedEvents.evtx"
```
 That is a 32 GB ForwardedEvents log on a dedicated volume. Adjust to the estate. 
 Redundancy. Two collectors, with each source subscribed to both, is the simplest resilient design. WEF has no built-in collector failover, so the redundancy is at the subscription level: the source forwards to both, and the SIEM reads from both and de-duplicates. For a security system that must produce logs for an investigation, two collectors is not excessive. 
 

 Source-initiated subscriptions by Group Policy 
 Source-initiated is the mode to use. The collector defines the subscription; Group Policy tells the sources where the collector is; the sources connect out and ask what to send. Adding a host to the estate is adding it to the right OU. 
 On the sources, two policy settings under Computer Configuration, Administrative Templates, Windows Components, Event Forwarding : 
 
 Configure target Subscription Manager , with the value Server=https://collector.example.local:5986/wsman/SubscriptionManager/WEC,Refresh=60 . HTTPS on 5986 requires a certificate on the collector; HTTP on 5985 is supported and encrypts with Kerberos, and HTTPS is what an auditor will expect to see. 
 Configure forwarder resource usage , which caps how much bandwidth a source will spend on forwarding. Leave it default unless a host is on a constrained link. 
 
 Also on the sources, the WinRM service must be running and configured to listen, and the Network Service account must be able to read the Security log. The second is the one everyone misses; without it, the subscription connects, reports healthy, and forwards nothing from the Security log. 
```
# On each source (or by GPO Preferences): let Network Service read the Security log
wevtutil gl Security
# Append (A;;0x1;;;NS) to the channelAccess SDDL shown, then:
wevtutil sl Security /ca:"O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)"
```
 Applying that string by Group Policy Preferences registry item to HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Security\CustomSD is the maintainable way to do it across the estate. 
 On the collector, create the subscription. The GUI in Event Viewer works; the XML is what goes in source control. The parts that matter are the target log, the source computer groups, and the query. 
```
<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
 <SubscriptionId>SecuritySystems-Core</SubscriptionId>
 <SubscriptionType>SourceInitiated</SubscriptionType>
 <Enabled>true</Enabled>
 <ConfigurationMode>Custom</ConfigurationMode>
 <Delivery Mode="Push">
 <Batching><MaxItems>50</MaxItems><MaxLatencyTime>30000</MaxLatencyTime></Batching>
 <PushSettings><Heartbeat Interval="60000"/></PushSettings>
 </Delivery>
 <Query><![CDATA[
 (query list goes here, see below)
 ]]></Query>
 <ReadExistingEvents>false</ReadExistingEvents>
 <TransportName>HTTPS</TransportName>
 <ContentFormat>RenderedText</ContentFormat>
 <Locale Language="en-CA"/>
 <LogFile>ForwardedEvents</LogFile>
 <AllowedSourceNonDomainComputers/>
 <AllowedSourceDomainComputers>O:NSG:NSD:(A;;GA;;;DC)(A;;GA;;;DD)</AllowedSourceDomainComputers>
</Subscription>
```
 The AllowedSourceDomainComputers SDDL above allows Domain Computers and Domain Controllers. Replace it with a dedicated group for the security system hosts once the estate is defined; a subscription that accepts every computer in the domain will also accept the one an attacker joined. 
 

 What to forward from a security system host 
 Forward what an investigation would need and nothing that a video server produces by the thousand for no reason. The set below is the one I deploy on VMS and access control hosts. It is deliberately not everything. 
```
<QueryList>
 <!-- Authentication and privilege -->
 <Query Id="0" Path="Security">
 *[System[(EventID=4624 or EventID=4625 or EventID=4634
 or EventID=4648 or EventID=4672 or EventID=4768 or EventID=4769 or EventID=4771 or EventID=4776)]] 
 <!-- drop the machine-account noise that a video server generates constantly -->
 <Suppress Path="Security">*[EventData[Data[@Name='TargetUserName'] and (Data='ANONYMOUS LOGON' or Data='SYSTEM')]]</Suppress>
 </Query>
 <!-- Account and group changes -->
 <Query Id="1" Path="Security">
 *[System[(EventID=4720 or EventID=4722 or EventID=4724 or EventID=4725 or EventID=4726
 or EventID=4728 or EventID=4732 or EventID=4756 or EventID=4738 or EventID=4740 or EventID=4767)]] 
 </Query>
 <!-- Process, service, task, and log tampering -->
 <Query Id="2" Path="Security">
 *[System[(EventID=4688 or EventID=4697 or EventID=4698 or EventID=4702 or EventID=1102 or EventID=4719)]] 
 </Query>
 <Query Id="3" Path="System">
 *[System[(EventID=7045 or EventID=7034 or EventID=7031 or EventID=7036 or EventID=104 or EventID=6005 or EventID=6006 or EventID=1074)]] 
 </Query>
 <!-- Application crashes: the VMS falling over is a security event on this estate -->
 <Query Id="4" Path="Application">
 *[System[(EventID=1000 or EventID=1001 or EventID=1026)]] 
 </Query>
 <!-- Sysmon, where deployed -->
 <Query Id="5" Path="Microsoft-Windows-Sysmon/Operational">
 * 
 </Query>
 <!-- PowerShell -->
 <Query Id="6" Path="Microsoft-Windows-PowerShell/Operational">
 *[System[(EventID=4103 or EventID=4104)]] 
 </Query>
</QueryList>
```
 A few notes on why those and not others. Event 7036, a service changing state, is noisy on general servers and essential here: it is how you know the Archiver service stopped at 02:14. Event 1074, a shutdown with its reason and the account that requested it, matters because an unexpected reboot of a video server is exactly the kind of thing an investigation asks about. Event 4688 with command-line auditing enabled is the single most useful event in the set, and it is also the most voluminous, which is why the audit policy guide told you to enable command-line logging and size the Security log for it. 
 Run domain controllers on their own subscription with the full directory service and Kerberos set. Run workstations on a lighter one: logons, process creation, and removable storage. 
 

 The last hop 
 The collector is the aggregation point, not the destination. Point the SIEM's Windows connector at the collector's ForwardedEvents log, and only that log. One connection instead of forty, and the video servers never see a SIEM credential. 
 If there is no SIEM, and on a good share of security systems there is not, the collector is still worth having: it is a copy of the logs that a compromised host cannot reach, and it is searchable with Event Viewer and PowerShell. Add a scheduled export of ForwardedEvents to an immutable store, and the estate has met the intent of the retention and integrity controls in 800-171 without buying anything. 
 

 Proving it is alive 
 A subscription that shows every source as active and forwards nothing is the standard failure, and it will pass a casual glance. Check three things, on a schedule. 
```
# On the collector: source status per subscription
wecutil gr SecuritySystems-Core

# Any source whose LastHeartbeatTime is older than the heartbeat interval × 3 has stopped

# Events actually arriving, by source, in the last hour
Get-WinEvent -LogName ForwardedEvents -MaxEvents 5000 |
 Where-Object TimeCreated -gt (Get-Date).AddHours(-1) |
 Group-Object MachineName | Sort-Object Count | Format-Table Count, Name
```
 Every host in the estate should appear in that table. A video server that is not there has either lost its WinRM listener, lost the Network Service read on the Security log, or been moved out of the OU that carries the policy. On the source side, the Eventlog-ForwardingPlugin operational log says which. 
 Then alert on absence. A host that stops forwarding is a host whose logs are now only on the host, and a scheduled task on the collector that compares the source list against the last hour's arrivals and emails the difference is ten lines of PowerShell and closes the gap that most log designs leave open.

================================================================