LenelS2 is the enterprise access line behind OnGuard and NetBox, with Mercury controllers at the doors and a software layer above them. It suits campuses and institutions that need granular permissions, durable reporting and integration with other building systems rather than a simple door schedule.
Enterprise access control is less about opening doors than about deciding who may open which door, when, and under whose authority. LenelS2 exists in that space: OnGuard for institutions with layered departments and integrations, NetBox for a single building that needs the same rigor without a full server stack. The software is only half of it; the other half is how the institution rules are expressed as data.
The hardware underneath matters as much as the software above, because a site that standardizes on Mercury controllers keeps options for the future. That combination of an open controller layer and a deep permission model is what a hospital, university or corporate campus is really buying. OnGuard depth is its advantage and its cost: every module is another thing to license, configure and test.
How OnGuard and NetBox divide the work
OnGuard is the full platform: a server, a database and add-on modules for video, visitor management, elevator control and intrusion. NetBox packages a subset of that capability into a dedicated appliance for a single building or a smaller campus, which is cheaper to run and simpler to support than a full server deployment. Both run on the same controller family, and a site can grow from one to the other without discarding the hardware at the doors. The appliance and the server share a data model, so reports and schedules look familiar on either platform.
The choice between them is about scale and administration rather than capability in the abstract. A multi-building institution with its own IT staff and a directory service will usually want OnGuard, while a single property with a modest door count may never use the modules that justify it. We size the system to the organization and leave a documented path for growth. Modules are licensed, so the quote has to reflect what the site will actually use.
Mercury controllers and the open hardware layer
Mercury controllers are the hardware that makes this platform portable, and it is the detail worth understanding. They are open controllers that many access platforms can drive, so a site that standardizes on them keeps an exit route if the software layer ever changes. They also hold their own door decisions, so an opening works when the server is unavailable. That openness is a hedge against a platform decision aging badly, and a controller swap stays a maintenance task rather than a project.
Behind the controller is the door itself. Readers on OSDP, lock hardware with the correct fail mode, request-to-exit devices and door position switches decide whether an access decision becomes a working door. The door schedule is reviewed before installation, because a controller cannot fix an electric strike that was never adjusted to the frame. Door hardware is where enterprise plans meet ordinary maintenance.
Permissions, integrations and migration
Enterprise access lives or dies on the permission model. OnGuard supports fine-grained operator roles, area-based control and directory-linked identities, which is what a hospital, a university or a corporate campus needs when many people must each see only their own slice. We design that model with the client and then write it down. A permission model nobody can explain is a finding waiting to be written.
Integration extends to video, intrusion and visitor management, and access events can drive those systems or be driven by them. Migration from a legacy platform starts with an inventory of controllers, readers and card technology, then stages cutover by building. The parallel period is shorter than most clients expect when the credential plan is settled first. Every module adds a test, and every test adds a day.
Frequently asked questions
Is OnGuard required to use Mercury controllers?
No. Mercury controllers are open hardware that several platforms can drive, which is part of their appeal. OnGuard is one software layer that uses them, and a site standardizing on the hardware keeps more options for whatever comes next.
Can OnGuard connect to our existing cameras?
It integrates with a range of video systems, though the depth of that integration varies by platform and license. We confirm the handoff for the video system actually in place rather than assuming every camera event will appear in the access client.
What does a NetBox deployment replace?
It replaces a separate server and database for a smaller building by bundling the access application into a dedicated appliance. Larger campuses outgrow it, so we confirm door count, reporting needs and the integration list before recommending one over OnGuard.
Last reviewed: