Security System Hardening Guide

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.

Contents

1. Introduction
2. Documentation
3. Part I, Network Architecture
4. Part II, Switch Hardening
5. Part III, Windows Domain and AAA
6. Part IV, Server Hardening
7. Part V, Workstation Hardening
8. Part VI, Cameras and IoT Hardening
9. Part VII, Access Control Panel Hardening
10. Part VIII, Vulnerability Assessment
11. Backups and Recovery
12. Hardening Checklists
13. 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

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

# 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

Remote access and the internet edge

The security network sits behind a firewall, separated from the corporate network and from the internet. Remote access goes through a VPN with MFA, where every session is authenticated and logged and each vendor’s access is scoped to the systems they support.

• No RDP exposed on 3389. No port forwards to cameras or VMS servers so an integration vendor can connect straight from the internet.
• Outbound internet access is allow-list only. A system that does not need to reach the internet does not get to.
• Windows updates come from a central WSUS or update server with controlled internet access, not from every device going out on its own.
• Vendor remote accounts stay disabled until the work needs them and get disabled again when it is done.

Port forwards to cameras and VMS servers are one of the most common findings in security audits. Camera firmware vulnerabilities are found regularly, and every open port is attack surface. Where a client chooses to keep a forward in place, document the risk in writing.

Part II, Switch Hardening

The universal controls below apply to every platform. Vendor syntax differs. The concepts do not.

1. Change default credentials before connecting to the network.
2. Enable AAA (RADIUS via NPS, or TACACS+ if available).
3. Disable Telnet. Enable SSH version 2 only.
4. Disable HTTP. Enable HTTPS, or disable web management entirely.
5. Configure port security on access ports (one MAC max, shutdown on violation).
6. Harden trunk ports (native VLAN 666, explicit allowed VLANs, no DTP).
7. Enable PortFast / edge ports and BPDU Guard on access ports.
8. Configure NTP from a trusted source.
9. Configure syslog to a centralized collector.
10. 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.

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.

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

Install-WindowsFeature NPAS -IncludeManagementTools

Step 2: register NPS in Active Directory

# 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.

Multi-factor authentication

Put MFA on everything that controls or grants access to the security system: the VPN, Active Directory privileged accounts, management interfaces, and operator logins on the VMS and access control platforms (Genetec Security Center, C-CURE 9000 administration, Milestone Management Client, and their equivalents). MFA stops a stolen password from becoming a working login. On current platforms it is a configuration task, and the friction for a legitimate operator is small. Treat it as a requirement on privileged and externally facing accounts. Many insurers and compliance frameworks already do.

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.

# 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"

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.
• Disable the VMS default admin account once named administrator accounts exist. Genetec, for example, logs every action against the account that performed it, so a shared admin account leaves the audit trail useless.

Patching and endpoint protection

Patching covers more than Windows Update. Cameras, panels, switches, firewalls, and UPS units all get firmware fixes for security flaws. Run WSUS for Windows, keep a scheduled firmware review for network gear and cameras, and record the end-of-support date for every major component. When a component reaches end of support, upgrade it or put compensating controls around it.

For VMS and access control servers, consider Windows Enterprise LTSC. It delivers security updates without the feature churn that breaks platforms with strict OS version requirements, and several VMS and access control vendors support it for that reason.

• Run behaviour-based endpoint protection (EDR, MDR, or XDR) on servers and workstations. Signature-only antivirus is not enough on its own.
• Apply the VMS vendor’s published exclusion list for server roles, databases, and media storage paths. Wrong exclusions cause performance problems that look like hardware or software faults. If you replace the endpoint product that shipped on an appliance (StreamVault ships with Aurora Protect configured), set every exclusion again by hand.
• Leave the Windows Firewall on. When an application cannot connect, find the port in the firewall log and add an explicit rule rather than turning the firewall off.

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.

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

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.

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.

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?

# 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

# 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.

# 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)

Backups and Recovery

Ask which systems would hurt to rebuild from nothing, then ask whether you could restore them. Cardholder databases, credential management systems, and camera configurations get lost. Ransomware has encrypted physical security systems, and hardware fails in ways the support agreement does not cover. Recovery is fast and controlled or slow and chaotic depending on whether a tested backup exists.

• Back up switch configurations after every change and keep them under version control.
• Back up server configurations and databases on a schedule.
• Follow 3-2-1: three copies, two storage media types, one offsite. Encrypt the backups, offsite copies above all.
• Test restores into a test environment at least quarterly. A backup that completes every night and has never been restored is an assumption.
• Write down the restore procedure and keep it somewhere other than the system you may need to restore.

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.
• Remote access through VPN with MFA only. No port forwards to cameras or servers.
• Outbound internet access allow-listed.
• 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.
• Behaviour-based endpoint protection deployed.
• MFA on administrator and VMS operator accounts.
• Patches current, with end-of-support dates recorded.
• Database and configuration backups running, encrypted, and restore-tested.

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.
• Restore procedure documented and stored off the system it restores.

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).