Case Studies

Anonymized Service Records

Six accounts of enterprise security system faults, written so that a technician recognizes the failure mode and nobody can identify the building.

Request Technical Service

Systems We Support

Why these accounts are anonymized

Skyfal Security does not publish customer names, facility names or system details without written authorization. The accounts below are deliberately stripped of anything that identifies a site.

That means no organization names, no locations or city names, no addresses, no network or IP information, no controller addressing, no device counts tied to a recognizable property, no floor plans or door identifiers, and no description of any weakness in a system as it stands today. Every condition described here was corrected before the account was written.

This is not a formality. A detailed public description of how a specific building’s security system is arranged is useful to exactly one audience, and it is not the audience this site is written for. If you need references, they can be provided privately and with the customer’s consent through Contact.

How to read these

Method, not marketing

Each record follows the same structure: what broke, what was involved, how it was diagnosed, what was done, how it was verified and what the customer was left with.

The systems described are enterprise platforms of the kind used in institutional and high-security environments: enterprise access control with networked door controllers, enterprise video management with separate directory and recording roles, and the server, database and storage infrastructure underneath both. Where a platform generation matters to the fault it is described generically, for example iSTAR-class controllers on a C•CURE 9000 head-end, rather than named throughout.

The diagnostic sections are the point of these records. In most of these cases the fault had already survived at least one round of parts replacement. What resolved them was event correlation, measurement at the device, and reading the system as an interconnected whole rather than treating the symptom as the problem.

Verification is described in the same detail as the repair, because a fix that has not been proven under the condition that caused the failure is not a fix.

Access control communication and door faults

Two faults that presented as software problems and were not.

Restoring access-control communication in a healthcare facility

Client sector
Healthcare. An acute-care property with continuous occupancy and restricted clinical zones.
Operational challenge
A group of doors in one wing intermittently dropped offline from the head-end. Cards kept working locally for a period and then reverted to a default state, after which staff propped doors and requested manual overrides. The drops cleared before anyone could attend, so three previous visits had ended with a controller swap and no change in behaviour. Clinical staff had lost confidence in the system and security management had lost the audit trail for a restricted area.
Systems involved
An enterprise access-control platform with networked door controllers and downstream reader interface modules on an RS-485 multidrop bus, addressable readers, and a shared low-voltage power distribution cabinet with battery backup serving locks and field devices for the wing.
Diagnostic approach
Pulled controller-level event history and host communication logs for a two-week window and plotted the drop events against time of day. The drops clustered around periods of heavy door traffic and mechanical plant activity rather than around any host or database event, which moved the investigation off the software. Measured the supply rail at the furthest device on the loop under load and watched it sag below controller tolerance whenever several locks energized together. Battery capacity in the distribution cabinet tested at a fraction of rating, so the cabinet had no ability to ride through the sag. Physical trace of the reader bus found a spur added during an earlier renovation and termination fitted at the wrong end of the run, producing reflections that made marginal signalling worse under electrical noise. Firmware across the wing was also mixed, with two modules several revisions behind the host.
Solution
Rebalanced the power distribution so lock loads and field device loads no longer shared a marginal rail, replaced the exhausted batteries, removed the unsupported spur and re-terminated the bus correctly, corrected module addressing that had been duplicated during the renovation, aligned firmware across the affected devices to a revision matched to the host, then reloaded door configuration from the head-end so every device held a known-good database.
Testing and verification
Seventy-two hour soak with continuous communication logging on every affected device. Deliberate simultaneous lock energizing while measuring the rail at the worst-case device. Card read tests at every door in the wing in normal operation and again with the host connection deliberately interrupted, to confirm offline decisions and event buffering. Door-forced, door-held and tamper points verified at the monitoring workstation. Buffered events confirmed to reconcile after each simulated outage.
Result
The communication faults stopped and did not return. Doors held their configuration through simulated host outages and reported buffered events cleanly on reconnection. Manual override procedures were withdrawn and the audit trail for the restricted zone was restored. The findings were written into a deficiency report with a recommended replacement interval for standby batteries and a note that the earlier controller replacements had not been necessary.

Resolving an intermittent door alarm at a financial data centre

Client sector
Financial services. A data centre operation with secured equipment aisles and a monitored alarm point on every aisle door.
Operational challenge
One aisle door generated door-forced and door-held alarms several times a week with no corresponding badge activity. Operations had begun acknowledging that point without investigating it, which was the more serious problem: a monitored point that everyone ignores provides no security at all, and the alarm history was no longer defensible for audit.
Systems involved
An enterprise access-control platform with supervised monitored inputs on the door controller, an electric locking device, a recessed door position switch, a request-to-exit device, and a door closer on a leaf subject to a sustained pressure differential from the room air handling.
Diagnostic approach
First established whether the alarms were real input transitions or head-end artifacts by comparing controller input history against alarms displayed at the workstation. They matched, so the fault was in the field. Attached monitoring to the door contact circuit and logged every state change over several days. The contact was operating at the outer edge of its rated gap, and the pressure differential plus a closer adjusted heavier than necessary was allowing the leaf to rest a few millimetres out of alignment after each closing cycle. Some closings latched the contact, some did not. Review of the input configuration also found end-of-line supervision values that no longer matched the resistors actually fitted, and a request-to-exit shunt time shorter than the real door swing, which produced door-forced events on legitimate exits.
Solution
Coordinated with the facility door hardware contractor to correct leaf alignment and closer tension. Replaced the door position switch with a wide-gap contact set and mounted it where alignment tolerance was greatest. Corrected the end-of-line supervision configuration to match the installed resistors so open, short and normal states report correctly. Retimed the request-to-exit shunt and the door-held pre-alarm to the measured door cycle.
Testing and verification
Repeated open and close cycles at varied speeds and force, including cycles run with the room at working pressure differential. Supervision verified for normal, open-circuit and short-circuit conditions with the alarm confirmed at the workstation for each. Legitimate exits tested repeatedly to confirm no door-forced events. The point was then left under observation for two weeks with alarm history reviewed at the end.
Result
No nuisance alarms during the observation period. The point was returned to enforced monitoring and the alarm history became usable for audit again. The same failure pattern was checked against the other doors on the aisle and two were corrected before they started producing alarms of their own.

Servers, recording and workstations

Two failures in the infrastructure layer, where the security system depends on things a security technician is not always asked to look at.

Recovering recording services after a server and storage failure

Client sector
Institutional. A multi-building campus with a large camera population and a retention policy tied to internal investigation requirements.
Operational challenge
Recording stopped on a large portion of the camera population while live video continued to display normally, so the failure went unnoticed at the console for some time. By the time it was reported there was a growing retention gap and an open investigation that depended on footage from the affected period.
Systems involved
An enterprise video management system with separate directory and recording server roles, several recording servers, a direct-attached storage array, and the archive database that indexes recorded video.
Diagnostic approach
Began at the recording service rather than the cameras, because live video proving healthy indicated cameras, network path and directory role were all functioning. Service logs showed the recording process repeatedly restarting after failing to write. Storage controller logs showed the array had been running in a degraded state for weeks after a drive failure that had never been alerted, then lost a second drive during an unattended rebuild attempt. The archive volume was intermittently unavailable, and the archive database on that volume was inconsistent as a result of the repeated interruptions. No health monitoring existed for array state, and nothing tied storage condition to an alarm anyone would see.
Solution
Stabilized the array before touching anything else, bringing the volume up read-only first so existing recorded video could be protected rather than risked in another rebuild. Copied recoverable archives to separate storage, then replaced the failed drives and rebuilt the volume. Re-pointed recording to verified healthy storage so recording could resume while the rebuild completed. Rebuilt the archive database and re-indexed the preserved footage so it was searchable rather than merely present. Restored camera-to-server assignments, recording schedules and retention settings from the management configuration. Configured array and service health reporting so a degraded volume raises an alarm at the console.
Testing and verification
Verified recording on every camera against its configured frame rate, resolution and schedule rather than sampling. Confirmed retention was accumulating to policy. Restarted recording services and forced role failover to confirm recording resumed without manual intervention. Exported test clips from multiple servers and confirmed playback, timestamp accuracy and time synchronization across servers. Triggered a simulated storage fault to confirm the new health alerting reached the console.
Result
Recording was restored across the camera population and the recoverable footage from before the failure was preserved and made searchable, which allowed the open investigation to proceed. Retention returned to policy. The customer left with array health monitoring, a documented recovery procedure and a maintenance schedule that includes storage condition, which is what would have prevented the original failure.

Restoring security workstations after a network and software change

Client sector
Government. A secured office property with a staffed monitoring console and a guard force dependent on it.
Operational challenge
After a scheduled infrastructure change, the monitoring workstations could no longer connect to the security head-end. Operators lost alarm display, badge lookup and camera call-up at the same moment and fell back to manual procedures. The change window had closed and the change itself had been signed off as successful, because nobody had tested the security clients.
Systems involved
Enterprise access-control client software and video management client software on operator workstations, the application and database servers behind them, certificate-based authentication between client and service, and directory and name-resolution services.
Diagnostic approach
Established the blast radius first. Field controllers were still making access decisions and buffering events, and the servers were healthy, so the fault was in the client tier only and no doors were at risk. Client logs showed the secure connection failing at authentication rather than at the network layer. Two causes were present at once: the change had altered name resolution so clients were resolving the service to the wrong endpoint, and a service certificate had expired during the same period, so even a corrected endpoint would have failed. A third issue surfaced during review: unmanaged operating system updates had left client software versions inconsistent across the workstations, with two machines a release ahead of the server.
Solution
Re-issued and installed the service certificates and confirmed the renewal date was recorded where it would be seen. Corrected name resolution for the security services in coordination with the IT group. Aligned client software versions to the server release across every workstation. Restored operator profiles, alarm views, camera layouts, badge templates and report definitions from configuration backup. Documented the approved client build and, with IT, moved the security workstations out of the unmanaged update policy into a controlled one.
Testing and verification
Logged in under each operator role and confirmed the permissions each role is supposed to have. Triggered a live door input and followed the alarm end to end from field device to annunciation to acknowledgement. Verified camera call-up on alarm, badge lookup, credential edit and report generation. Confirmed that events buffered at the controllers during the outage flowed into the database on reconnection with no gap in the audit trail.
Result
Operators were back on console the same day with the full event history intact, including everything that had happened while the clients were down. The lasting change was procedural: security system testing was added to the change-approval process, so network, certificate and update changes are now verified against the security clients before a window is signed off.

Migrations and integrated subsystems

Two projects where the constraint was that the building could not stop.

Migrating legacy access-control hardware in an active facility

Client sector
Industrial. A continuously operating plant with controlled areas that cannot be left unsecured for any part of a shift.
Operational challenge
The installed controller generation was past support, spares were no longer obtainable, and a failed panel would have meant an area with no electronic access control and no audit trail. A planned head-end software upgrade was also blocked, because the legacy panel firmware would not run against the newer version. Production could not stop and no door could be left insecure, so a conventional weekend cutover was not available.
Systems involved
Legacy access-control panels and reader interface boards, current-generation controllers from the same enterprise platform family, existing field wiring and readers of mixed vintage, monitored inputs and controlled outputs tied to plant equipment, and a head-end database carrying many years of cardholder records and access-level history.
Diagnostic approach
Inventoried every panel, door, reader type and every input and output actually in use, because the drawings had not matched the plant for years and several outputs were wired to equipment nobody had documented. Verified whether existing field wiring could be reused by checking conductor count, gauge and run length against the requirements of the replacement hardware, which decided reader-by-reader whether a change of reader communication protocol was possible. Exported and audited the cardholder database and found duplicate credentials, credentials for departed staff still active, and orphaned access levels that no longer mapped to any real group. Built a mapping document from every legacy address to its new controller and door before any hardware was ordered.
Solution
Phased the cutover area by area, one panel per window, during low-traffic periods agreed with plant operations. New controllers were staged and configured off site so each window was an install-and-verify exercise rather than a build. Readers were migrated to supervised, encrypted communication wherever existing wiring supported it, and left on the legacy protocol where it did not, with each exception recorded so it can be revisited when the cabling is next accessible. Access levels were rebuilt against a cleaned structure and mapped deliberately rather than copied forward with their existing errors. A written manual security procedure was agreed with the plant for each window, covering the specific doors offline and for how long.
Testing and verification
A per-door checklist completed before each window was allowed to close: card read, grant, deny, door position reporting, request-to-exit, door-forced, door-held, lock release on fire alarm interface where applicable, and every monitored input and controlled output confirmed against its documented function. Test credentials exercised against every access level. Anti-passback and interlock behaviour retested per area. Offline mode tested per panel by interrupting host communication. Head-end alarm routing confirmed for each migrated point.
Result
Every door migrated with no unplanned downtime and no door left unsecured outside an agreed and supervised window. The head-end upgrade was unblocked and completed afterward. The customer received a documentation package that had not previously existed: panel schedule, door schedule, address mapping from old to new, input and output function list, and the rebuilt access-level structure.

Troubleshooting elevator access-control interfaces

Client sector
Institutional property with restricted floors and mixed occupancy, where floor-level access separation is a compliance requirement.
Operational challenge
Card-controlled floor access behaved inconsistently. Some cardholders were occasionally able to select floors they had no authorization for, which is the serious half of the problem. Others presented valid credentials and were offered no floors at all. The elevator contractor and the previous security vendor each attributed the fault to the other, and the condition had persisted through several visits by both.
Systems involved
An enterprise access-control platform providing elevator control, car readers, output boards mapping to floor button enablement on the older cars, and on the modernized cars a high-level serial interface to the elevator management system in place of discrete relay control. Time schedules governed free-access periods and after-hours restriction.
Diagnostic approach
Built a truth table first: every car, every floor, every access level, and the expected result for each combination, agreed in writing with the customer before testing. Then tested against it rather than against assumptions. Three separate faults were present. On two cars the discrete output-to-floor mapping was off by one position, because a modernization had inserted a service level into the floor numbering and the security side had never been updated. On those same cars the output pulse was shorter than the elevator controller needed to latch the enable, so a valid credential sometimes produced no floors purely on timing. On a modernized car the high-level interface had reverted to a default configuration after a firmware update and was ignoring the floor mask from the security system entirely, granting whatever the passenger selected.
Solution
Re-mapped outputs to the current floor numbering with the elevator contractor present, so both sides signed off the same map. Lengthened the enable and latch timing to the value the elevator controller actually requires, confirmed by observation rather than by specification sheet. Restored the high-level interface configuration and confirmed with the elevator contractor how the setting behaves across future firmware updates so it is checked after each one. Rebuilt the elevator access levels against the agreed truth table.
Testing and verification
Every car, every floor and every access level tested with dedicated test credentials, with a witness from the elevator contractor present and the results recorded against the truth table. Denied attempts tested as carefully as granted ones and confirmed to log correctly at the head-end. Free-access schedules, after-hours restriction and the transition between them tested at the boundary times. Fire service and independent service operation verified to override correctly and to return to secured operation afterward.
Result
Floor control became consistent and the unauthorized-floor condition was eliminated. The floor map, timing values and elevator access-level structure were documented and jointly signed off by the customer, the elevator contractor and Skyfal, which removed the ambiguity that had allowed the fault to be passed back and forth for so long.

The pattern behind all six

The same sequence applies whether the fault is in a door contact or a storage array.

01 Establish what is actually failing — Separate symptom from fault. Live video working while recording stops, or doors operating while the console is dark, tells you which layer to investigate and which to leave alone.
02 Correlate the evidence — Controller event history, service logs, storage controller logs and host records compared against each other and against time of day. Patterns in an intermittent fault are usually visible before the fault is.
03 Measure at the device — Voltage under real load, signal on the bus, contact behaviour through a full door cycle. Field faults are confirmed by measurement, not inferred from the head-end.
04 Correct the cause and the conditions — Fix what failed, and fix what allowed it to fail. Exhausted batteries, wrong supervision values, absent health monitoring and drifted firmware are the conditions that turn a small fault into an outage.
05 Verify under the failure condition — Test at the load, the pressure differential, the offline state or the schedule boundary that produced the original failure. Anything less is a hope, not a verification.
06 Leave documentation behind — Findings, changes, address maps, configuration baselines and prioritized recommendations, so the next person is not diagnosing from scratch.

The services behind these records

Each case above draws on one or more of these.

If one of these sounds familiar

Describe the symptom, the platform and what has already been tried. That is enough to start.

Request Technical Service

Service Agreements