Application server and services
CrossFire service health, memory behaviour under sustained load, service dependencies and start order, and the faults that surface as intermittent client disconnects rather than as an obvious failure.
// C-CURE 9000 HEALTH CHECK · HANS STUDY · ONTARIO, CANADA
C-CURE 9000 health check
Access control fails differently from video. When a recorder struggles you lose footage you might never have needed. When C-CURE struggles, a door does not open for somebody standing in front of it, or it opens for somebody who should not be there. The system carries on reporting itself healthy either way.
What the health check covers
C-CURE 9000 problems rarely stay in one layer either. A door that behaves oddly can be a controller firmware mismatch, a CrossFire service under memory pressure, a SQL bottleneck, a journal that has never been maintained, or a third-party integration doing something the integrator did not document. Reviewing one layer in isolation is how these systems stay half-broken for years.
SQL Server
C-CURE lives on its database more than most platforms. Memory configuration, maintenance plans, index and journal growth, backup and restore that has actually been tested, and version support against the C-CURE release.
iSTAR controller estate
Firmware consistency across controllers, cluster and encryption configuration, memory and cardholder capacity against the population actually loaded, and offline behaviour when the server is unreachable.
Redundancy and failover
Whether the design has real redundancy or a single instance carrying an entire estate. Failover behaviour tested rather than assumed, and what happens to in-flight events during a switch.
Personnel and credentials
Data hygiene at scale, clearance and access level structure, stale cardholders, credential technology and migration exposure, and whether the permission model can still be explained by anyone.
Integrations
Elevator control, video, intrusion, visitor management and directory sync. The highest-risk surface in most C-CURE deployments and the first thing blamed when something else is wrong.
Doors and field hardware
Supervision configuration, held and forced door handling, request to exit behaviour, lock power and battery calculations, and whether alarms mean anything or are routinely cleared unread.
Security and lifecycle
Operator privilege model, audit trail and journal retention against policy, certificate and encryption posture, patch discipline, and version currency against support.
Common issues identified
The pattern in C-CURE estates is different from video platforms. One application server carrying access control for buildings that were never meant to share a single point of failure. Controller firmware that drifted apart over successive service visits. A database nobody has maintained since commissioning, with a journal that has grown for years. Access levels that accumulated until nobody can say who can go where. Lock power calculated once, at handover, before half the doors were added.
The one worth calling out specifically: elevator integration takes the blame for a great many faults that are not the elevator interface at all. On a multi-tower estate I worked through, the failures traced to software faults and configuration inside C-CURE, not to the interface everyone had been arguing about. That distinction matters, because one of those is a support case and the other is a re-architecture.
The full engagement: access control stabilisation and a core network rebuild across a multi-tower complex.
Who this is for
Organisations where C-CURE 9000 controls access to something that matters, and where nobody can currently say with confidence how it would behave under failure. Commercial real estate, healthcare, education, government, and enterprise campuses.
It is most useful when the system has grown past its original design, when it changed hands between integrators, when an upgrade or expansion is coming, or when doors have started behaving in ways nobody can explain.
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.
- Specific, configuration-level recommendations tied to published guidance and real operational practice.
- A prioritized action list separating what to fix now, what to schedule, and what to design around.
- 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.
Related advisory areas
Access control design →
Door schedules, hardware selection, panel layout, power calculations, egress and code.
Security network design →
The network under the controllers. A surprising share of access control faults live there.
Expert opinion →
When the system has already failed and there is a disagreement about why.
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.
Genetec Security Center →
Architecture, roles and sizing under real load.
Milestone XProtect →
Edition, Device Pack currency and support entitlement.
Avigilon Unity and Alta →
Which product family you are in, and what that decides.
AXIS Camera Station →
Edge analytics, and the device estate that limits them.
Lenel OnGuard →
Version position, database age, and access level sprawl.
Kantech EntraPass →
Edition ceiling, gateway topology, and controller firmware.
Find out how it behaves before it has to
Access control is judged on the day it fails. Everything that decides that outcome was configured, sized or skipped long beforehand.
Independent of Software House, Johnson Controls, and every integrator involved. See the independence policy.