Services
Access Control Service and Repair
Diagnosis, repair, replacement and programming for access control systems already installed and in daily use. Controllers, readers, door hardware interfaces, elevator interfaces and the database behind them.
What we do
Doors, controllers and the software that decides
Access control fails in small ways long before it fails in obvious ones, and the small failures are the ones that tell you where the real fault is.
An access control system is a chain. A credential is presented to a reader, the reader passes data to a controller over a bus, the controller compares it against a decision table it received from a server, and an output releases a lock while an input confirms the door actually opened. Any link in that chain can fail on its own, and several can fail in ways that look identical from the operator workstation.
That is why we measure rather than guess. A door that will not release is a wiring, power, hardware, configuration, communication or database problem, and telling those apart takes a meter at the door and a look at the event log, not a new strike.
Below are the symptoms that most often bring a facility manager to us.
- A door that unlocks most of the time. Intermittent release is rarely the lock alone. Voltage drop under load, a marginal power supply, a failing relay or a door position switch reporting the wrong state will all produce the same complaint.
- Readers that stopped responding after a change. A firmware update, an OSDP conversion or a batch reader replacement can leave devices addressed, keyed or wired in a way the controller no longer accepts.
- Panels reporting communication loss on a schedule. Faults that appear at the same time each day or week are usually network, power or time synchronization problems, not panel failures.
- Credentials that work at one door and not another. Access level, clearance, schedule, card format or facility code mismatches, often introduced years ago and inherited ever since.
- Audit trails that no longer match the building. Doors renamed, removed or repurposed without the configuration following, so reports describe a site that no longer exists.
- A controller nobody wants to touch. Legacy hardware still running, no spares available, no documentation, and a general agreement in the building to leave it alone.
What the work covers
Grouped by where the fault actually lives rather than by the part that gets blamed for it.
Controllers, panels and field circuits
Panel-level diagnosis starts at power and communication, before any part is ordered.
- Controller and panel troubleshooting. Supply voltage and battery condition, communication status to the head-end, firmware level, board-level fault indications, and event and diagnostic logs read to establish whether the panel actually received what the software believes it sent.
- Input, output and relay troubleshooting. Door position switches, request-to-exit devices, tamper and supervision circuits, end-of-line resistor values that no longer match the input configuration, relay contacts that have welded or worn, and outputs mapped to the wrong point during an undocumented change years earlier.
- Controller replacement and migration. Replacing failed or unsupported controllers on existing field wiring, including CK721 legacy panels moved onto current iSTAR hardware, with door, reader, input and output assignments carried across and verified rather than rebuilt from memory.
Doors, readers and credentials
The layer users actually touch, and the one that generates the most reported faults.
- Door hardware interface diagnostics. Electric strikes, maglocks, mortise and motorized locks, power transfer hinges and door loops, measured under load rather than at rest. A strike that passes a bench test can still fail at the end of a long run on a warm afternoon.
- Reader and credential issues. Read range and orientation, card format and facility code mismatches, credentials enrolled under the wrong format, and mixed-technology sites where proximity and smart credentials coexist. Many buildings have had HID readers replaced in batches over the years without the format ever being written down.
- OSDP and reader communication support. Device addressing, baud rate, secure channel key state, bus topology, cable length and termination, and readers that fall off the line intermittently after a conversion from Wiegand.
Communication paths and interfaces
Where access control meets the network and the rest of the building.
- Network and communication problems. Controllers that drop and reconnect, firewall and VLAN rules blocking panel-to-server ports, duplicate addressing, DNS and time synchronization faults, and switch or fibre segments that only fail under load or after a building-wide power event.
- Elevator access-control interfaces. Floor-by-floor control through relay boards or a serial or network interface to the elevator controller, including free-access schedules, fire service interaction, and cab reader behaviour when the interface loses communication with the head-end.
Software, database and configuration
The decision layer, and the place where a physical symptom often turns out to have started.
- Database and configuration support. Server and database health, backup verification and tested restoration, database growth and journal maintenance, cardholder import and cleanup, and recovery of a system whose configuration has drifted away from the building it is supposed to describe.
- System programming and commissioning. Doors, readers, access levels and clearances, schedules and holidays, credential formats, anti-passback, interlocks and mantraps, elevator groups, alarm routing, operator privileges and partitions, in environments including Software House C•CURE 9000. Commissioned door by door and tested, not assumed.
Migration
Replacing a controller without rebuilding the system
Legacy panels can usually be retired one at a time, on the wiring and readers already in place.
The common assumption is that an unsupported controller means a full system replacement. It usually does not. Where the field wiring, readers and door hardware are serviceable, the controller itself can be changed out and the doors reconnected to the existing terminations. A CK721 panel replaced with current iSTAR hardware keeps the same doors, the same readers and the same cardholders.
The work that matters is the configuration carry-over. Door names, input and output assignments, reader ports, access levels, schedules and any custom logic have to arrive on the new controller matching what the site actually uses, and then be tested point by point. Panels are done one at a time so that the building is never fully offline and there is always a position to fall back to.
Where a migration also involves a software version change, a server move or a new interface to video or intercom, it is planned as a project rather than a service call. That work is described on Upgrades, Migrations and Integrations, and the server side on Security Server and Head-End Infrastructure.
How an access control call runs
- 01 Symptom capture — Which doors, how often, at what times, under what conditions, and what changed most recently. Intermittent faults are described in terms of frequency and pattern, because that pattern is usually the diagnosis.
- 02 Head-end and panel review — Event history, panel communication state, firmware levels, database and backup condition, and recent configuration changes. This establishes whether the system knows about the fault or is unaware of it, which points in very different directions.
- 03 Door-level testing — At the affected opening: voltage at the lock under load, reader response, request-to-exit and door position operation, strike or maglock behaviour through a full cycle, and the physical condition of the door itself. Doors that bind or drop on their hinges cause faults that look electrical.
- 04 Repair, replacement or reprogramming — Corrective work against the identified cause. Configuration backups first, then the change, with affected doors identified in advance and any door taken out of service covered by an agreed interim arrangement.
- 05 Verification door by door — Each affected point tested and the result recorded, including the condition that produced the original complaint. Where the fault was intermittent, verification includes a monitoring period rather than a single successful swipe.
- 06 Documentation and handover — A written service record and, where configuration changed, an updated point list your team can use. If anything remains outstanding, it is stated with a recommendation instead of left implied.
Scope of this service
Skyfal services existing access control infrastructure. We do not sell controllers, readers, credentials or software licences, and we hold no manufacturer dealership or partner status.
We do not perform new cabling, drilling, conduit or construction wiring. Where a new door needs a pathway pulled or a frame cored, that work belongs to an electrical or cabling contractor. On existing cable and existing device locations, we terminate, replace, program, test and document.
Common questions
A door fails to unlock maybe twice a week and works perfectly the rest of the time. Where do you start?
With the event log and a meter, in that order. The first question is whether the system recorded a valid read and an unlock command at the moment of the failure. If it did, the fault is downstream of the controller: voltage at the lock under load, relay condition, wire gauge over the run distance, or a strike or maglock that is marginal when warm. If it did not, the fault is upstream: reader communication, credential format, access level or schedule, or a panel that briefly lost contact with the head-end.
Intermittent faults are also the ones most often “fixed” by replacing parts. We would rather monitor an opening across the conditions that produce the failure than replace three components and hope.
Our controllers are old and we have been told the whole system needs replacing. Is that true?
Usually not in one step. Where field wiring, readers and door hardware are serviceable, legacy controllers can be replaced individually on the existing terminations, with configuration carried across and verified. CK721 panels moved to current iSTAR hardware is a routine example.
A full replacement is genuinely warranted when the software version is beyond support and the database cannot be carried forward, when the wiring itself has failed, or when the site needs capability the existing architecture cannot provide. We will tell you which of those applies, and we have no hardware sale riding on the answer.
Can you work on a live system without putting the building into lockdown?
Yes, and that is the normal condition of the work. Doors are taken out of service one at a time against an agreed schedule, with the affected openings identified in advance so your team can arrange staffing, temporary keying or an alternate route. Configuration and database backups are taken before any change, and a rollback position is defined before the first change is made.
Some work does require a quieter window, for example a head-end restart or a panel firmware change affecting many doors. That is scheduled with you rather than announced on the day.
We converted our readers to OSDP and now some of them report communication faults. Is that a reader problem?
Sometimes, but the bus is the more common cause. OSDP is a multi-drop line, so topology matters in a way Wiegand did not. Star wiring left over from the previous installation, excessive stub lengths, missing termination, mismatched baud rates, duplicate addresses and partially completed secure channel keying all produce intermittent dropouts that look like failing readers.
We check addressing and baud rate, secure channel key state on each device, the physical topology of the run, and whether the controller firmware supports the reader firmware in use. Replacing readers before that is checked usually reproduces the same fault on new hardware.
What does a service report actually contain?
The reported symptom in your words, the tests performed and the measured results, the identified cause, any parts replaced, any configuration changed with the previous value recorded, the verification results point by point, and any outstanding items with a recommendation and a rough sense of urgency.
It is written so that a technician who has never been to your site, including one who does not work for us, can pick up where the visit ended.
Another company installed the system and still holds the software. Can you work on it?
In most cases, provided you have or can obtain administrative access to your own system. That is a question worth resolving before a fault occurs rather than during one, and it is one of the first things we check during intake.
Where credentials, licence details or backups sit with a previous contractor, we will tell you exactly what is needed and, if you want, document the request for you. We can also carry out a configuration review and take a verified backup so the system is recoverable regardless of who worked on it last. That work is described under Troubleshooting and System Restoration.
Describe the door and the pattern
Which openings, how often, at what times, and what changed most recently. That is usually enough for us to scope the visit accurately.