Specifying access control: readers, controllers, credentials and biometrics

Architecture is the first security decision, not a later implementation detail. When the network link to the head-end fails, something at the door has to keep making decisions, and the specification has to say what.

State the offline requirement in numbers: how many cardholders each controller must hold locally, how many events it must buffer before overwriting, how long it must run on battery, and what its behaviour is for a credential that was valid at the moment the link dropped. Then state the decision latency at the door under normal conditions — the time from credential presentation to lock release — because that number drives the user experience and the throughput of any lane the reader sits on.

This is also where cloud-hosted platforms have to be examined honestly rather than rejected or adopted on principle. A cloud system with a capable edge controller can be an excellent choice. A cloud system that needs a round trip to a remote data centre to open a door is a different proposition, and the question to ask in evaluation is not whether it is cloud, but which decisions survive a loss of connectivity.

Wiegand is a one-way, unsupervised interface with no cryptography. Credential data travelling on it can be captured and replayed from the unsecured side of the door, and because the link is not supervised, a reader can be removed without the system noticing. It should not appear in a new specification.

The replacement is OSDP, the Open Supervised Device Protocol, published internationally as IEC 60839-11-5:2020 and maintained by the Security Industry Association. It runs bidirectionally over RS-485, supervises the reader so removal or a broken line is reported, and supports a Secure Channel using AES-128 for encryption and authentication.

Specify it precisely, because partial implementations are common. Require OSDP with Secure Channel enabled in operation, not merely supported; require that installation-mode or default keys be replaced with site-specific keys before handover; require that key custody sit with the client; and require reader tamper and communication loss to be reported as alarms with a defined response. An OSDP reader running in clear text is a Wiegand reader with a better datasheet.

Two credential technologies still routinely offered in the region should be refused outright. Low-frequency 125 kHz proximity cards carry no cryptography at all and can be read and cloned with inexpensive commodity hardware. MIFARE Classic relies on the proprietary CRYPTO1 cipher, which was broken academically in 2008 and is now defeated in seconds by widely available tools; its identifier can be copied and its sectors read.

Specify instead a contactless smart card to ISO/IEC 14443 that performs mutual authentication with AES-128 — the MIFARE DESFire EV2 and EV3 families are the common examples, and DESFire EV3 carries Common Criteria certification at EAL5 augmented. Name the exact chip variant and memory size in the schedule. A specification that says smart card or equal is routinely satisfied with MIFARE Classic, and that substitution is usually discovered years later during an audit.

Then specify the keys, which is the part almost everyone omits. Require a site-specific, diversified key set generated for this client; require a documented key ceremony with the client holding custody; and require in writing that the integrator retains no copy of the master key and that the key set is not shared with other sites. Without that clause, the client is dependent on one supplier for every future card order, which is a commercial lock-in dressed as a technical constraint.

Mobile credentials follow the same logic. Ask who issues and holds the keys, what happens to issued credentials at the end of the contract, whether the phone credential works when the handset is offline, and what the read range is — a long-range Bluetooth credential is convenient at a vehicle gate and a liability at a speed gate lane, where it can open the wrong barrier.

Biometric performance claims in datasheets are close to meaningless unless the test that produced them is stated. Require the false accept and false reject rates — or the equivalent match error rates — to be quoted together with the dataset, the test protocol and the operating threshold used, and give preference to independent evaluation over self-declared figures. A supplier that will not name the test has not measured one.

Spoofing is a separate question from accuracy, and it has its own standard. ISO/IEC 30107-3 covers presentation attack detection testing and reporting, using metrics such as APCER and BPCER. Specify that presentation attack detection be evaluated to ISO/IEC 30107-3, and require the test laboratory and the attack instruments considered to be named. A face reader with excellent match rates and no presentation attack detection can be opened with a photograph.

Then deal with the data. Under the Saudi Personal Data Protection Law, issued by Royal Decree M/19 of 2021 with implementing regulations from September 2023 and full enforcement from 14 September 2024, biometric data used to identify a person is Sensitive Data, and the Saudi Data and Artificial Intelligence Authority is the regulator. Processing sensitive personal data requires explicit consent, and consent obtained from an employee in an imbalanced relationship deserves particular care.

That translates into specification clauses: state the lawful basis and who is accountable for it; prefer template storage on the credential or on the device over a central biometric database where the use case allows; require templates rather than images, with the conversion irreversible; state retention and deletion periods and the deletion process at end of employment; state where the data resides and whether any of it leaves the Kingdom; and provide a non-biometric alternative for anyone who declines, because a system with no alternative route makes consent meaningless.

A door is controlled only if it is also monitored. Specify a door position switch on every controlled door, together with forced-open and held-open alarms and a defined response, and make sure the request-to-exit device releases the lock without suppressing the monitoring — a common configuration that produces a system with no evidence of anything.

Fail-safe versus fail-secure is a fire strategy decision, not a preference. State it per door, aligned with the means of egress requirements of the Saudi Building Code and agreed with the Civil Defence authority having jurisdiction, and state the behaviour on fire alarm, on mains loss and on battery depletion. Include the mechanical override path and who holds the keys, because that is what will be used at three in the morning.

For lanes and gates that are part of an escape route, coordinate this clause with the entrance control specification so that the two documents do not describe different behaviours for the same event.

EN/IEC 60839-11-1 defines security grades from 1 to 4 for electronic access control systems and components, applied per access point. Using it lets you express intent without naming a product: a grade for general office doors, a higher grade for restricted areas, and the supplier demonstrates compliance.

Interoperability needs to be written down while you still have leverage. Require a documented API for integration with video, intrusion, visitor management and HR systems; require that the cardholder database, credential assignments and the event log can be exported in a documented, non-proprietary format on demand; and require that the client owns the data and the encryption keys.

Then read the commercial model as carefully as the technical one. Ask what is licensed and on what basis — per door, per reader, per cardholder, per year — what happens if a licence lapses, what the firmware update path is, how long the platform will be supported, and what the published policy is for security patches. Ask how controller-to-server traffic is encrypted, how certificates are managed, and how default credentials are handled at commissioning. These questions cost nothing at tender stage and are unanswerable at year three.

A short list of things that should not survive a technical review. Wiegand reader interfaces on any new installation. Low-frequency 125 kHz proximity credentials. MIFARE Classic, including as an accepted alternative. OSDP specified without Secure Channel in operation. Default or installer-held cryptographic keys carried into service.

Also: controllers mounted on the unsecured side of the door; a cloud-only architecture with no local decision capability on a door that matters; biometric enrolment with no stated lawful basis, no retention period and no alternative route; and any credential clause using the words or equal without naming the chip.

Finally, be wary of any system whose cardholder data cannot be exported. Access control systems outlive the companies that install them, and an unexportable database is what converts a fifteen-year asset into a forced replacement.

An access control specification is defensible when it states each of these:

• Offline behaviour in numbers: cardholders held locally, events buffered, battery runtime, and door decision latency under normal operation.
• OSDP reader communications to IEC 60839-11-5, with Secure Channel enabled in operation and default keys replaced before handover.
• Reader tamper and communication loss reported as alarms, with a defined response.
• Credentials to ISO/IEC 14443 using AES-128 mutual authentication, with the exact chip variant and memory named — and MIFARE Classic and 125 kHz proximity explicitly excluded.
• A site-specific diversified key set, a documented key ceremony, client custody of keys, and a written statement that the integrator retains no master key copy.
• For mobile credentials: key ownership, offline operation, read range and end-of-contract handling.
• Biometric error rates quoted with the dataset, protocol and operating threshold, from independent evaluation where available.
• Presentation attack detection evaluated to ISO/IEC 30107-3, with the laboratory and attack instruments named.
• PDPL position stated: lawful basis and explicit consent, template rather than image storage, storage location, retention and deletion, and a non-biometric alternative for anyone who declines.
• Door position monitoring on every controlled door, with forced and held-open alarms and a defined response.
• Fail-safe or fail-secure stated per door, aligned with the Saudi Building Code means of egress requirements and agreed with the Civil Defence authority, plus the mechanical override path.
• An EN/IEC 60839-11-1 grade assigned per access point.
• A documented API, and the right to export cardholder data, credential assignments and event logs in a non-proprietary format.
• The licensing model, support lifetime, firmware update path and security patch policy, stated in the tender.