HID Aero vs. Mercury: Choosing the Right Access Controller in 2026

aero vs mercury

The retirement of legacy HID VertX and Edge hardware, combined with the well-documented vulnerabilities of the Wiegand protocol, has pushed security teams into a decisive hardware transition. But the replacement decision is not as simple as picking the newest panel on the shelf. HID Global now offers two distinct controller platforms — HID Aero and Mercury — and understanding the difference between them is critical before you commit to hardware.

These are not competing products in the usual sense. They share the same corporate parent (HID Global acquired Mercury Security in 2017) and the same underlying protocol technology. But they are designed for different markets, supported by different software ecosystems, and positioned at different price points. Choosing the wrong one will cost you — either in capability you don’t need, or in software compatibility you assumed you had.

This guide explains the real differences, based on publicly available manufacturer specifications, and describes how CredoID supports both platforms to give you a single management interface regardless of which controller you deploy.


The Relationship: Aero Is Built on Mercury Technology

This is the first thing to understand, because it is the source of most confusion in the market.

HID positions Aero as being based on its Mercury panel technology — the same platform that supports more than five million controllers installed globally since the early 1990s. Aero is not a separate, competing architecture. It is Mercury-based technology adapted for a smaller, simpler market segment. The SCP communication protocol and core Mercury architecture are shared, though firmware implementation and product capabilities differ. This is why CredoID’s device drivers for Aero and Mercury share the same core SCP protocol layer.

The practical difference is in how HID positions them:

Mercury HID Aero
Target market Enterprise, large-scale, high-security Small to medium-sized organisations
Software ecosystem Open platform — supported by dozens of OEM software vendors Smaller partner ecosystem — do not assume compatibility
Product evolution EP (discontinued) → LP (current) → MP (next generation, with MercOS firmware) X1100 intelligent controller with X-series IO modules

This positioning matters. If a software vendor supports Mercury, it does not automatically mean they support Aero. Always verify before specifying hardware. CredoID supports both — but not every platform does.


Moving Beyond Wiegand: OSDP Is Non-Negotiable

The Wiegand protocol transmits credential data unencrypted over dedicated signal wires. In 2026, this is an unacceptable liability. Inexpensive interception tools can clone credentials from a Wiegand bus in minutes.

OSDP (Open Supervised Device Protocol), standardised as IEC 60839-11-5, is the mandatory replacement for any facility that takes cybersecurity seriously. Both Aero and Mercury controllers support OSDP natively, including Secure Channel with AES-128 encryption, bidirectional reader supervision, and RS-485 multi-drop wiring.

CredoID provides full OSDP reader configuration for both platforms, including per-reader secure channel activation, address and baud rate assignment, and tamper status monitoring.


Offline Operation and Network Resilience

Both Aero and Mercury controllers store credentials locally and make access decisions on-board — they do not depend on a live server connection to grant or deny access. This is a fundamental property of panel-based access control, and it is the reason this architecture remains dominant over cloud-only alternatives: if the network goes down, every door keeps working.

The real question is not whether a controller can operate offline — every panel on the market can — but how cleanly your management software handles the synchronisation lifecycle: pushing permission changes to controllers, operating correctly during network interruptions, and reconciling events when connectivity resumes.

CredoID manages this explicitly. When a cardholder’s access rights change, the update is synchronised to every relevant controller. If the network drops, decisions are made against the last-known-good permission set cached on the panel. When connectivity resumes, buffered events are uploaded to the server — no manual reconciliation is required.


Mercury: The Enterprise Standard

Mercury Security does not sell end-user software. Its controllers are an OEM platform adopted by dozens of access control software vendors — CredoID among them. This makes Mercury hardware the industry benchmark for multi-vendor interoperability and the default choice for enterprise-scale deployments.

Current Product Lines

Mercury MP Series (Latest Generation)

Controller Cardholders I/O Capacity Key Features
MP4502 2,000,000 1024 in / 1024 out TLS 1.3, Secure Boot, ARM TrustZone, FIPS 140-3, BACnet/IP, embedded application environment
MP2500 600,000 1024 in / 1024 out Mid-range MP controller
MP1502 240,000 520 in / 516 out (with expansion modules) TLS 1.3, Secure Boot, ARM TrustZone, FIPS 140-3, embedded application environment
MP1501 single-door (edge controller) PoE+ single-door edge controller

MP controllers are designed for MercOS, Mercury’s next-generation firmware platform (availability depends on firmware release and deployment mode). They include an embedded application environment — a containerized framework that allows custom applications to run directly on the controller with hardware-enforced isolation via ARM TrustZone. This capability is currently limited to the MP series and not available on Aero or LP hardware. MP controllers also operate in legacy mode for backward compatibility with existing LP deployments.

Mercury LP Series (3rd Generation, actively supported through at least 2028)

Controller Cardholders Key Features
LP4502 2,000,000 Linux OS, embedded crypto memory chip, data-at-rest encryption, enterprise-grade
LP2500 Mid-range LP controller
LP1502 240,000 Linux OS, embedded crypto memory chip, data-at-rest encryption
LP1501 PoE/PoE+ single-door edge controller

LP controllers run on a hardened Linux OS. They do not include ARM TrustZone and advanced Secure Boot capabilities introduced in the MP series.

Mercury EP Series (Discontinued)

The EP (Embedded Platform) line — EP1501, EP1502, EP2500, EP4502 — was discontinued by Mercury (EOL early 2019). These controllers are no longer manufactured or receiving firmware updates. CredoID retains full driver support for the EP range to serve legacy installations that have not yet migrated.

CredoID supports the complete Mercury range: EP, LP, MP (all models), plus legacy Pro-series controllers (Pro4200, Pro32IC, PW6K1IC) and all downstream modules including MR50, MR52, MR52B, MR51e, MR62e, MR16In, MR16Out, Aperio hubs (wired and IP), and Pro42r2/PW6K1r2 reader interfaces.

Why Choose Mercury

  • Software freedom. Mercury’s open-platform model means you can switch or supplement your management software without replacing field hardware. This is the single biggest differentiator.
  • Enterprise scale. The MP4502 supports 2 million cardholders with 1024 inputs/outputs — capacity that Aero cannot match.
  • Edge application development. MP controllers allow custom applications to run on the controller itself via a secure, containerized environment, enabling advanced integrations at the edge.
  • Cybersecurity depth. The MP series provides Secure Boot with ARM TrustZone, TLS 1.3, and FIPS 140-3 support (validation status depends on specific module and certification scope) — a meaningful step beyond what Aero and LP offer.

HID Aero: The VertX Successor for Smaller Deployments

HID positions Aero as a practical, cost-effective solution for small and medium-sized sites that don’t need enterprise-scale Mercury infrastructure. It is specifically designed as the successor to the discontinued VertX EVO line, providing a clean upgrade path for existing VertX installations.

Aero is built on the same SCP protocol and Mercury technology foundation, but with a simpler product line, a smaller software partner ecosystem, and a lower price point.

Controller Lineup

Controller Role Key Specifications
X1100 Intelligent controller TLS 1.2, FIPS 140-2, dedicated crypto chips, 250K credentials, 50K transaction buffer
X100 Two-door reader interface module RS-485 downstream module
X200 Input expansion module (16 inputs) RS-485 downstream module
X300 Output expansion module (12 outputs) RS-485 downstream module

The X1100 supports up to approximately 64 readers and access points (depending on configuration) through daisy-chained reader interface modules, with a local credential database of 250,000 cardholders. It accepts legacy VertX V100, V200, and V300 interface boards as downstream modules — existing boards can be reused during migration.

The X1100 is designed as a form-and-fit replacement for both the VertX EVO V1000 and V2000 controllers — consolidating both legacy models into a single modern SKU while matching physical dimensions and mounting points.

CredoID supports the full Aero family: X1100, X100, X200, X300, along with legacy VertX V100/V200/V300 modules running under Aero controllers, and Aperio IP hub integration. For legacy single-door deployments, CredoID also supports the Edge EVO EH400 through its dedicated VertX driver.

Note: The CredoID codebase also includes support for an X1100C hardware variant. As HID has not published separate public specifications for this variant, we do not detail it here. Contact HID Global or Midpoint Security for current availability.

Why Choose HID Aero

  • VertX migration. Aero is the only current-generation controller designed as a physical drop-in for both the VertX V1000 and V2000, reusing existing enclosures, mounting points, and downstream V-series modules. No other platform offers this.
  • Cost-effective for smaller sites. If you’re deploying 2–64 doors and don’t need enterprise-scale capacity, Aero provides solid security at a lower price point than Mercury.
  • Hardware security. The X1100 includes dedicated crypto chips protecting encryption keys and passwords, AES-based encryption for IO module communication (implementation varies by configuration), OSDP Secure Channel, and operates within a FIPS 140-2 approved environment.

What Aero Does NOT Offer

Being honest about limitations is what separates a trusted guide from a marketing brochure:

  • No embedded application environment — you cannot run custom apps on Aero hardware. This is an MP-series exclusive.
  • No FIPS 140-3 — Aero operates in a FIPS 140-2 environment; the MP series uses the newer FIPS 140-3 standard.
  • No Secure Boot or ARM TrustZone — these hardware-level protections are exclusive to the Mercury MP series.
  • No TLS 1.3 — Aero supports TLS 1.2; TLS 1.3 is available on Mercury MP controllers.
  • Smaller cardholder capacity — 250K vs Mercury’s 240K–2M range. For very large credential databases, Mercury is the only option.
  • Smaller software ecosystem — fewer OEM partners support Aero than Mercury. Verify compatibility before specifying hardware.

Direct Comparison

Criterion Mercury LP Mercury MP HID Aero X1100
Target market Enterprise Enterprise / high-security SMB / everyday
Software compatibility Open — dozens of vendors Open — dozens of vendors Smaller ecosystem
OSDP support Full Full Full
TLS 1.2 1.3 1.2
Secure Boot / ARM TrustZone
AES encryption AES-256/128 AES-256/128 AES-256 (IO), AES-128 (OSDP)
Cardholder capacity 240K – 2M 240K – 2M 250,000
Transaction buffer 50,000 500,000 (MP4502) 50,000
FIPS compliance FIPS 140-2 FIPS 140-3 FIPS 140-2
Edge applications
Firmware platform Linux / MercOS MercOS Aero firmware
Data-at-rest encryption Crypto chips
Legacy module reuse EP-series boards EP-series boards VertX V100/V200/V300
Drop-in replacement for EP-series panels EP-series panels VertX V1000/V2000
CredoID support ✅ Full ✅ Full ✅ Full

When to Choose Mercury

  • You are building an enterprise-scale system with hundreds or thousands of doors.
  • You require Secure Boot, ARM TrustZone, or FIPS 140-3 for compliance (MP series).
  • You operate a multi-vendor software environment or anticipate changing your management platform.
  • You need edge application development capabilities on the controller (MP series).
  • You need 2 million cardholder capacity (MP4502/LP4502).

When to Choose HID Aero

  • You are deploying a small to medium-sized access control system (2–64 doors).
  • You are performing a VertX-to-modern migration and want to reuse existing enclosures, wiring, and downstream V-series modules.
  • Cost is a significant factor and you don’t need enterprise-scale features.
  • Your chosen access control software explicitly supports Aero — verify this first.

When to Deploy Both

Many organisations find that a mixed fleet is the pragmatic answer. Mercury at headquarters and high-security facilities (where enterprise capacity and edge applications matter), Aero at satellite offices and smaller sites (where VertX migration convenience and cost-effectiveness are priorities). CredoID manages both from a single interface with unified cardholder management, consolidated event reporting, and consistent access rule enforcement.


Migration from Legacy Hardware

VertX / Edge EVO → HID Aero

The Aero X1100 is the sanctioned replacement for both the discontinued VertX V1000 and V2000 — consolidating both legacy controllers into a single modern SKU. It uses the same mounting footprint, which eliminates the need to re-drill enclosures or re-run conduit. Existing VertX V100, V200, and V300 downstream modules can remain in place — Aero supports them natively alongside the newer X-series boards. Reader wiring can be reused if the existing readers support OSDP; if not, this is the right time to upgrade readers as well.

CredoID handles the transition at the software level. Legacy VertX panels (including Edge EVO EH400 single-door controllers) and new Aero panels coexist in the same CredoID instance during a phased rollout. Access rules, cardholders, and schedules do not need to be recreated — the migration is purely a hardware swap.

Mercury EP / Pro-series → Mercury LP/MP

The LP series replaces the discontinued EP (Embedded Platform) line with a Linux-based architecture. The physical form factor and downstream module compatibility (MR52, MR50) are preserved, making the upgrade straightforward. CredoID also supports legacy Pro-series controllers (Pro4200, Pro32IC, PW6K1IC), so mixed-generation Mercury deployments are fully managed.

The MP series is the next evolution, adding TLS 1.3, Secure Boot with ARM TrustZone, FIPS 140-3 validated cryptography, and an embedded application environment for custom edge processing. MP controllers operate in legacy mode for seamless backward compatibility with existing LP deployments. CredoID supports all generations simultaneously, allowing a staged upgrade.


How CredoID Bridges Both Platforms

This is where the value proposition becomes concrete. Because Aero and Mercury share the same underlying SCP protocol, CredoID’s device driver architecture can treat them as members of the same controller family — while maintaining separate drivers for their hardware-specific differences.

This means:

  • One cardholder database pushed to all controllers, whether they are Aero X1100, Mercury LP1502, or Mercury MP4502.
  • One set of access rules — schedules, anti-passback zones, elevator control, global I/O linkages — applied uniformly across both platforms.
  • One event stream — alarms, access grants, denials, and tamper alerts from Aero and Mercury panels appear in the same monitoring dashboard and report engine.
  • One OSDP configuration interface — secure channel activation, baud rate, reader address, and tamper monitoring are configured identically whether the downstream reader is connected to an Aero X100 or a Mercury MR52.

CredoID’s production codebase includes dedicated device drivers for HID VertX, HID Aero, Mercury (EP, LP, MP, and Pro-series), and multiple other controller families — actively maintained across production installations. This makes CredoID one of the few platforms that spans the full spectrum from legacy VertX hardware through to the latest Mercury MP controllers.


Conclusion

The HID Aero vs. Mercury decision is not about which controller is “better.” It is about which platform matches your scale, budget, compliance requirements, and software ecosystem.

Choose Mercury if you need enterprise-grade capacity, the widest possible software compatibility, or the advanced cybersecurity and edge computing capabilities of the MP series. Choose HID Aero if you are migrating from VertX, deploying at a smaller scale, and your access control software explicitly supports it. Choose both if your organisation spans multiple security profiles — and let CredoID manage the complexity.

The worst decision is indecision. Legacy Wiegand and VertX hardware is a compounding security risk. The right time to migrate is now; the right software ensures the next migration is a hardware swap — not a system replacement.


CredoID is developed by Midpoint Security. For technical documentation and integration guides, visit credoid.com.

Leave a Reply

Your email address will not be published. Required fields are marked *