Access control head-end

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

Enterprise unified (Genetec Synergis): 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.
Traditional institutional (Software House C-CURE 9000): 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).
High-security / federal (Hirsch Velocity): 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.
Hardware-first integrator (HID Aero, HID-direct deployments): 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.

Other platforms in the market

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

Field note

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

// HEAD-END SERVER SIZING

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

Field note

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 CONFIGURATION

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

Field note

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

// IDENTITY INTEGRATION

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

Field note

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

// HEAD-END TO FIELD COMMUNICATION

IP backhaul from every Mercury EP-series or HID Aero controller to the head-end server on the access control VLAN
TLS encryption on the IP connection (Mercury EP and HID Aero both support TLS 1.2 minimum)
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

Field note

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

// MONITORING AND AUDIT

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 PRACTITIONER POSITION

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.