Security integrators spend a lot of time spec’ing controllers, readers, and panels. The server often gets picked last — a leftover budget line, a repurposed workstation, or whatever the IT department had on the shelf. That’s the wrong approach, and the field proves it repeatedly: slow door grant times under concurrent operator load, event queues backing up during alarm storms, SQL databases choking on overnight reporting jobs.
This post breaks down server hardware requirements across seven major access control manager platforms, identifies which specs actually drive performance, and explains why the gap between a minimum-spec and a right-spec server shows up in the field — not on the quote.
If you’re deploying Lenel OnGuard, Genetec Security Center, Milestone XProtect with access control, Software House C•CURE 9000, Avigilon ACM, ICT Protege GX, or AMAG Symmetry, this applies to your next project.
What the Vendors Actually Specify
Every major ACM platform publishes hardware requirements. The minimums are survivable. They are not recommended.
Lenel OnGuard 8.x lists an Intel Core i3 at 2.5 GHz and 16 GB RAM as the current minimum server spec. Their enterprise deployment documentation scales that to Xeon-class processors with 15 MB+ cache and 16 GB RAM per communication server VM — with an explicit rule of thumb of 100 access panels per communication server. Latency between application server, communication server, and database must stay between 5 and 40 milliseconds; 5 ms is the preferred end of that range. That latency requirement tells you more about the architecture than the CPU spec does.
Genetec Security Center 5.13 (February 2025) publishes a tiered server profile table. The recommended enterprise profile specifies dual Intel Xeon Gold 5416S processors, 64 GB RAM, a hardware RAID controller with SAS drives, and a 10 GbE NIC. That is the recommended configuration — not the high-performance outlier. Their enterprise tuning documentation notes that NIC receive buffers default to 256, which is insufficient for servers handling significant event throughput, and that SQL Server will consume all available RAM by default and must be explicitly capped when sharing resources with other roles.
Milestone XProtect Corporate 2024 R2 lists an Intel Xeon E5 class processor and 8 GB RAM as the management server baseline. The recording server workload scales with camera count rather than a fixed spec, and Milestone’s own engineering community has documented that disk I/O is the consistent real-world bottleneck — not CPU. A server running a modest i7 at 12% CPU utilization can still generate missed recordings if the storage subsystem is saturated.
Software House C•CURE 9000 is the most explicit of the group about memory requirements. Their VM guidance specifies a minimum of 32 GB RAM per instance, with dedicated (non-shared) CPU cores — and states directly that more CPU means better performance in a linear relationship. Their documentation also flags a specific failure mode: heavy disk contention during server startup, which becomes a real problem when multiple C•CURE instances share a host. Minimum storage is 15,000 RPM HDD; SSD is recommended.
ICT Protege GX 4.3 scales hardware requirements by controller count. A system with 1 to 29 controllers requires a 64-bit quad-core processor at 3.3 GHz with 8 threads. Systems with 30 or more controllers step up to a 6-core, 12-thread processor at 2.5 GHz — lower clock speed, more cores. ICT’s documentation also states explicitly: install additional RAM wherever possible, and use SSD over HDD. There is no upper RAM limit given because the guidance is simply more is better.
Avigilon ACM is primarily an appliance-based platform, which limits published server specs for software installs. The ACC / ACM unified architecture requires a 64-bit OS, Intel quad-core 2.0 GHz recommended, with a 1 Gbps NIC and enterprise-class SATA drives at minimum.
AMAG Symmetry Enterprise v9 requires a dedicated SQL Server instance and supports 64-bit OS only. Enterprise configurations support clustered servers and virtualization. The SQL Server dependency places it in the same resource profile as the other SQL-backed platforms above.
The Three Hardware Specs That Determine ACM Performance
Pulling from all seven platforms — their published minimums, recommended configs, enterprise tuning guides, and real-world deployment documentation — three hardware variables consistently separate a functioning ACM server from a high-performing one.
- RAM: The Primary Bottleneck at Scale
Every ACM platform covered here runs on a SQL Server database. SQL Server’s performance is directly tied to how much of the working dataset it can hold in buffer pool memory. When RAM is insufficient, SQL begins disk reads for queries it should be serving from memory — and at that point latency increases and throughput drops, regardless of what your CPU is doing.
The floor has moved. Legacy minimums of 4–8 GB are no longer viable for modern deployments. Current published minimums range from 16 GB (Lenel OnGuard 8.x, C•CURE SiteServer) to 32 GB (C•CURE VM guidance) to 64 GB (Genetec Security Center recommended enterprise profile). ICT puts no ceiling on it and simply says more is better.
For a 50 to 500 reader deployment with multiple concurrent operator sessions and daily reporting — the workload profile of most commercial integrator projects — 32 GB is the practical starting point for a well-sized server. Below that, you are building in headroom problems that show up during high-event periods: alarm storms, morning ingress surges, or overnight database maintenance jobs running concurrent with early operators logging in.
RAM is also the variable most affected by co-hosting. If SQL Server shares resources with IIS (web client), report services, or any third-party integration middleware, the buffer pool gets compressed further. Genetec and C•CURE both recommend dedicated RAM per role and explicit SQL Server max memory caps.
- Storage I/O: The Most Commonly Underspecified Variable
ACM event logging is a continuous, high-frequency SQL write workload. Every badge read, door state change, alarm, operator action, and panel communication generates a database write. At 300 active readers during peak, this can mean thousands of writes per minute.
A 7,200 RPM HDD delivers roughly 80 to 150 random IOPS under sustained load. A mid-range enterprise SSD delivers 50,000 to 200,000 IOPS. The gap is not a marginal improvement — it is two to three orders of magnitude. This is why ICT Protege GX explicitly recommends SSD over HDD, why C•CURE specifies 15,000 RPM as the minimum, and why Milestone’s engineering community consistently identifies disk I/O as the primary failure point in under-specced deployments.
Three storage configuration rules that appear consistently across vendor documentation:
Hardware RAID is mandatory for production deployments. Genetec explicitly requires it. Software RAID uses CPU cycles for parity computation — under sustained write load this creates CPU contention that compounds storage latency. A hardware RAID controller with battery-backed cache writes to cache first and flushes to disk asynchronously, protecting both performance and data integrity.
The SQL database drive must be separate from the OS drive. This is stated in Genetec, Lenel enterprise, and C•CURE documentation. When the OS and database compete for the same volume, both suffer. The separation is frequently skipped on low-budget builds and is consistently the first thing to cause a performance support call.
Backup and log volumes should be on a third separate volume where retention requirements or audit logging creates significant write volume.
For the 50 to 500 reader commercial deployment, a mirrored pair of enterprise SSDs dedicated to SQL — separate from the OS — covers all three rules in a clean, supportable configuration. The Arxys VideoX Access Control server ships with exactly this layout: dedicated hardware-mirrored SSDs for the SQL database on a separate volume from the OS, aligned with the configuration Genetec, C•CURE, and Lenel all specify as best practice.
- CPU Core Count: The Variable That Scales With Concurrency
Clock speed (GHz) matters most for serial workloads — a single report running on a quiet server, or a small system with one operator session. It is not the meaningful variable for ACM servers running at production load.
ACM software runs multiple concurrent services simultaneously: the database engine, the communication server polling panels, the application server managing client sessions, web services, integration middleware, and the event processing engine. SQL Server in particular is highly multi-threaded and will use every available core for concurrent query execution, index maintenance, and backup jobs.
ICT Protege GX’s tiered specification makes this explicit: they reduce clock speed (from 3.3 GHz to 2.5 GHz) and increase core count (from 4 cores to 6 cores) as the system scales past 30 controllers. The trade is intentional — more threads handling concurrent workloads outperforms fewer threads at higher clock speed once the system reaches operational scale.
C•CURE’s VM guidance states that cores should be dedicated per instance and that the relationship between core count and performance is approximately linear. Genetec’s tuning documentation recommends maximizing RSS processor count to distribute network receive processing across CPU cores — a documented failure mode on high-event-volume systems when left at defaults.
For the 50 to 500 reader commercial deployment, a modern 6 to 8 core processor at 3.0 GHz or better handles concurrent service load without contention. Below 4 cores, SQL Server, the communication engine, and concurrent operator sessions begin competing for the same threads during peak periods.
What This Means for Server Selection
The three variables above — RAM, storage I/O, and CPU core count — are the specifications that separate a minimum-viable ACM server from one that holds up at operational load, through alarm storms, during overnight database jobs, and as the system scales.
Network bandwidth is not on this list. For a pure ACM deployment, 1 GbE is non-constraining through very large systems. ACM event data — badge reads, panel polling, door state changes — is low-bandwidth traffic measured in kilobytes per transaction. Bandwidth only becomes a constraint when video is co-hosted on the same server, at which point it is a VMS architecture problem, not an ACM hardware problem.
Clock speed in isolation is also not on this list. A higher GHz processor with fewer cores will underperform a lower GHz processor with more cores under production ACM load. ICT Protege GX reduces GHz and increases core count as scale increases. That is the correct direction.
The integrators who spec ACM servers correctly are building around 16-32 GB RAM minimum, dedicated enterprise SSD with hardware RAID for the SQL volume, and a processor with 6 or more cores and at lest 4Ghz. Everything else is secondary.
The Arxys VideoX Access Control server platform is built on AMD EPYC architecture — chiplet-based design with significantly higher L3 cache per core than comparable Intel Xeon configurations (up to 128 MB on current EPYC 9005 series). Higher per-core cache means more of the SQL Server working dataset stays in CPU-side memory before touching RAM, compounding the performance benefit of adequate RAM. Combined with dedicated hardware-mirrored SSD storage for the database volume and validated compatibility across the major ACM platforms, it is purpose-built for the commercial and mid-enterprise access control deployment tier.
The Bottom Line for Integrators
When scoping hardware for an ACM deployment, the right questions are:
How much RAM does the SQL Server instance need to hold the active working dataset without disk reads? Size from there, not from the minimum spec sheet. Quick Answer: 16-32GB is the right RAM target for most projects.
Is the database on its own dedicated SSD volume with a hardware RAID controller? If not, the I/O configuration is the first thing that will cause a performance call.
Does the processor have enough cores to run the communication engine, SQL Server, client sessions, and any integration middleware concurrently without thread contention? Six cores is a reasonable floor for any deployment above 50 readers.
Base Configuration for these ACM vendors in the sub 500 door projects:
- AMD EPYC CPU with 6 Cores/ 12 Threads is base, 16/32 is larger installs
- 16GB RAM is base, 32GB for middle and larger installs
- Dedicated hardware RAID mirrored SSDs optimized for mixed use and at least 480GBs
- Dual 1GbE or 10GbE ports for segmenting
- Microsoft Windows Server 2022 or 2025 for uptime, management and performance
- Avoid desktop OS’s
The vendors covered here — Lenel, Genetec, Milestone, C•CURE, Avigilon, ICT Protege GX, and AMAG Symmetry — all arrive at the same architecture through different documentation. RAM first. Storage I/O second. Core count third. Get those three right and the server will perform.
For access control server hardware built to these specs, see the Arxys VideoX Access Control platform.
Arxys VideoX Access Control Servers
Arxys manufactures purpose-built access control server hardware designed for Lenel OnGuard, Genetec Security Center, Milestone XProtect, Software House C•CURE 9000, Avigilon ACM, ICT Protege GX, and AMAG Symmetry deployments. The VideoX Access Control platform uses AMD EPYC processors with chiplet-based architecture, providing significantly higher L3 cache per core (up to 256 MB on EPYC 9005 series) compared to comparable Intel Xeon configurations. This architecture keeps more of the SQL Server working dataset in CPU-side memory before touching RAM, compounding the performance benefit of adequate system memory. The platform ships with dedicated hardware-mirrored SSD storage for SQL database workloads on a volume separate from the OS — the configuration explicitly recommended by Genetec, Software House C•CURE, and Lenel enterprise documentation. Arxys access control servers are validated against the hardware requirements of the major ACM platforms and purpose-built for commercial and mid-enterprise deployments in the 50 to 500 reader range.
