Lenel OnGuard (via OpenAccess REST)
Lenel (HID Global / Carrier)·AE_HSc_LenelOpenAccessConnectorGuide
Overview
The Lenel OpenAccess connector integrates AlertEnterprise Guardian with Lenel OnGuard via Lenel's modern OpenAccess REST API. This is the connector to use for new Lenel deployments — it replaces the obsolete DataConduIT (DCOM-based) integration path that the original lenel connector documents for legacy reference.
OnGuard is one of the most widely deployed enterprise PACS — particularly common in financial services, federal, and Fortune 500 corporate. Pair this connector with ccure9000-victor and genetec for the "big three enterprise PACS" coverage almost every enterprise RFP expects.
The connector supports both PIAM and VIM PACS object families (Cardholder + Badge + Access for employees; Visitor + Visitor Badge + Visitor Access). It also supports SOC Insights integration — incremental reconciliation of Readers, Panels, badge swipe Events, and Alarms — which most PACS connectors don't expose.
Deployment topology supports both on-prem and SaaS Guardian: - On-Premise: ACF + Lenel OpenAccess Connector run in the customer environment, calling OpenAccess REST over HTTPS internally. - SaaS: Alert Enterprise Agent runs on-prem, hosts the connector, and the cloud Guardian application communicates with the Agent via outbound HTTPS only — no inbound firewall holes into the customer network.
Architecture
Composed from this connector's actors + edges. Trust zones are color-coded; trust crossings render as thicker lines.
Authentication
1 method supported
The OpenAccess API uses OAuth 2.0. The Alert OpenAccess Connector exchanges OnGuard operator credentials for a bearer token at the OpenAccess token endpoint, then includes Authorization: Bearer <token> on subsequent calls. Token TTL is OnGuard-side and the connector refreshes on expiration. All traffic over TLS.
Prerequisites
Everything that must be in place for this connector to work, with the owner who's responsible.
OnGuard OpenAccess API enabled
customerThe OpenAccess REST API must be enabled and reachable from the AE application server (on-prem deployment) or from the Alert Enterprise Agent (SaaS deployment).
OnGuard operator account with API privileges
customerDedicated OnGuard operator with privileges for cardholder + badge + access-level operations, visitor operations (if VIM is in scope), and SOC Insights data reads (if Readers/Panels/Events/Alarms reconciliation is in scope).
Alert Enterprise Agent (SaaS deployment only)
aeFor SaaS Guardian, an Alert Enterprise Agent must be deployed on-prem with reachability to OnGuard's OpenAccess endpoint. The Agent hosts the OpenAccess Connector and provides the cloud-to-on-prem bridge — OnGuard is never exposed to the cloud.
Known limitations
Documented constraints to set customer expectations before deployment.
Badge PINs not reconcilable (encrypted in OnGuard)
informationalBadge PIN codes are encrypted in OnGuard and cannot be read back through the OpenAccess API. Reconciliation reads everything *except* PINs — provisioning writes PINs through but reconciliation can't verify them.
OnGuard Cloud not supported
importantThis connector is designed for on-premises OnGuard deployments only. Supporting OnGuard Cloud would require additional development from AE. Customers planning OnGuard Cloud should engage AE Product to scope the work.
Data fields
7 fields mapped between AE Guardian and the vendor system.
| AE field | Vendor field | Description | Direction | Required |
|---|---|---|---|---|
| userId | Cardholder.PERSONID | OnGuard Cardholder primary key. | bidirectional | yes |
| firstName | Cardholder.FIRSTNAME | — | bidirectional | no |
| lastName | Cardholder.LASTNAME | — | bidirectional | no |
| middleName | Cardholder.MIDNAME | — | bidirectional | no |
| badgeId | Badge.BADGEKEY | OnGuard badge identifier. | bidirectional | yes |
| cardNumber | Badge.CARDNUMBER | — | bidirectional | no |
| BadgeAccessLevel | BadgeAccessLevel | Cardholder Access Levels (OnGuard term for what Guardian calls Access Areas). | bidirectional | no |
PACS specifics
OnGuard models a Cardholder as the principal identity (PERSONID, FIRSTNAME, LASTNAME, MIDNAME, custom attributes). Each Cardholder has one or more Badges (BADGEKEY, CARDNUMBER, status flags, validity window, PIN). Visitors are a parallel object family — VIM (Visitor Identity Management) provides Visitor + Visitor Badge + Visitor Access. Both PIAM and VIM are supported by this connector.
Access is granted by assigning Cardholder Access Levels to badges. OnGuard's term "Cardholder Access Level" maps to Guardian's "Access Area" concept. Supports Change Badge Access Levels operation to modify assignments.
OnGuard Enterprise supports federated deployments with multiple regional OnGuard instances. The connector supports both standalone OnGuard (on-prem) and OnGuard Enterprise. OnGuard Cloud is not supported — see limitation above.
- Topology
- on-prem
- Event model
- both
- Anti-passback
- unknown
- Holiday schedules
- unknown
- src/connectors/lenel-open-access/source.pdf — Full connector guide — 31 pages, updated 2026-05-14
- src/connectors/lenel-open-access/source.pdf — p6 — Supported Versions & Features
- src/connectors/lenel-open-access/source.pdf — p5 — DataConduIT definition