// LENEL ONGUARD HEALTH CHECK · HANS STUDY · ONTARIO, CANADA

Lenel OnGuard health check

OnGuard estates tend to be old, large, and load-bearing. They were installed when the organisation was smaller, they have absorbed every acquisition and expansion since, and upgrading them is difficult enough that many run several versions behind while everyone hopes nothing changes.

What the health check covers

The defining characteristic of OnGuard environments is accumulation. Modules bought for one project, integrations added by successive integrators, cardholder data that has never been cleaned, and a database carrying fifteen years of history. The review follows that shape.

LNL-01

Version and support position

Where the installed version sits against current and against support, and what the upgrade path realistically costs. On this platform that answer is frequently the single most important finding.

LNL-02

Licensing and modules

OnGuard licenses by module and by count. Which modules are licensed, which are actually used, and where the estate has grown past what was bought.

LNL-03

SQL Server and database health

Database sizing, maintenance plans, index and event history growth, archiving strategy, and backup and restore that has been tested. Long-lived OnGuard databases are rarely maintained proportionally to their age.

LNL-04

Controller and panel estate

Firmware consistency across the field, memory and cardholder capacity against the population loaded, downstream device health, and offline behaviour when the server is unreachable.

LNL-05

Cardholder and access levels

Data hygiene at scale, stale records, access level sprawl, and whether the permission model can still be explained by anybody currently employed.

LNL-06

Integrations

Video, intrusion, elevator, visitor management, HR and directory synchronisation. Each one is a dependency, and on older estates several were built by people who have moved on.

LNL-07

Redundancy and continuity

What actually survives a server failure, whether failover has been tested rather than assumed, and what the field does while the head end is unavailable.

LNL-08

Security and hardening

Operator privilege model, service accounts, encryption and certificate posture, audit trail retention against policy, and patch discipline on a system that is often treated as untouchable.

Where OnGuard estates commonly sit

  • Several versions behind, because the upgrade is hard and the system is critical, so it keeps getting deferred.
  • A database nobody has maintained relative to its age, carrying more history than anyone has a policy for.
  • Access levels accumulated over a decade, where removing one is riskier than leaving it because nobody knows what it grants.
  • Integrations built by departed integrators, undocumented, and only understood by whether they are currently working.
  • Redundancy assumed rather than demonstrated, often because testing it would mean taking access control down.
  • Treated as untouchable, which is how a critical system ends up unpatched and unexamined for years at a time.

Who this is for

Large organisations where OnGuard controls access to something that matters and where the institutional knowledge about it has thinned out. Healthcare, education, government, critical infrastructure, and enterprise campuses.

Most useful before an upgrade decision, ahead of a budget cycle, after the person who knew the system has left, or when a merger has brought two estates together.

What you receive

The deliverable is a prioritized remediation plan, not a pile of observations you have to triage yourself.

  • A findings report organized by severity and by system layer, readable by both the security team and the IT team.
  • A clear position on version, licensing and upgrade cost, which on this platform is usually the decision driving everything else.
  • Specific, configuration-level recommendations tied to published guidance.
  • A working session to walk through the findings and answer what the report raises.

Recommendations do not change based on who is selling. There is no product being steered toward at the end of this.

Delivery and scope

Remote delivery via the DHD, a remote access device, where the system cannot be reached over the network.

How the work is delivered

Remote

Screen share, supplied configuration exports, logs and documentation. Most of what a health check examines is visible without anyone travelling, and this is how the majority of engagements run.

DHD

The DHD, a pre-configured remote access device, ships to the site. Somebody on site plugs it into power and network, which takes minutes and needs no technical skill. It provides the access needed to examine the system properly, then ships back. Covers configuration, shipping both directions, and retrieval.

Cheaper and faster than travel for a single site, and it is what makes distance stop mattering. A site in another province costs the same to review as one an hour away.

On site

For work that needs someone in the room: physical inspection, cabling and rack conditions, commissioning witness, or an environment that cannot be reached remotely. Travel and on-site time are added to the written quote before work starts.

What a health check does not include

Listed because an unstated exclusion is what turns an agreed scope into an argument at invoice time, and that is the exact failure this practice exists to review other people for.

  • Remediation. The report says what to fix; fixing it is a separate engagement or your own team.
  • Configuration changes. Nothing is altered on a live system during a review.
  • Licence, hardware or software costs, which are yours and are bought direct.
  • Vendor support cases, escalations, or dealings with your integrator on your behalf.
  • On-site attendance, unless added explicitly.
  • Ongoing monitoring or a retainer. A health check is a point-in-time assessment.

Health checks for other platforms

Same structure and the same fixed pricing across every platform. The layers reviewed differ, because the ways these systems fail differ.

HC-02

C-CURE 9000 →

CrossFire, iSTAR estate, SQL dependency and integrations.

Find out where it actually stands

A system nobody wants to touch is not stable. It is unexamined, and the difference only becomes visible on the day it matters.