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. Hardening Checklists
12. 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

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.

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.

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 and EP series) 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)

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