Most badge systems still trust a plaintext signal on a pair of wires behind the reader, and a networked controller that few security teams have ever scanned. Physical access control systems (PACS) decide who opens which door, yet they are often built on legacy Wiegand wiring, cloneable cards, default controller passwords and head-end servers outside IT patching. This guide goes beyond the overview in the Physical Security Guide for Security Teams to cover the PACS security stack in depth: credential technology, OSDP Secure Channel and its key management, a practical Wiegand to OSDP migration, controller and server hardening, identity integration, monitoring and metrics. It is for physical security managers, security architects and integrators working on corporate, government and critical infrastructure sites.
Key takeaways
- Every link in the chain matters. Card, reader, reader-to-controller wiring, controller, network and head-end server each need their own controls; a strong card does not fix a plaintext wire.
- OSDP is only secure with Secure Channel on. OSDP over RS-485 supports AES-128 Secure Channel, but install mode and the published default key (SCBK-D) must be left behind after commissioning.
- Retire static-ID credentials. 125 kHz proximity cards and legacy card types can be copied; move to cryptographic credentials such as AES-based smart cards, mobile credentials or PIV.
- Controllers are network devices. They run web servers and embedded operating systems, appear in the CISA KEV catalogue and need segmentation, patching and unique credentials.
- Badge access follows identity. Drive PACS provisioning and revocation from HR and the identity platform, and measure the time from leaver to badge disabled.
The PACS stack and where it fails
| Layer | Components | Typical weakness | Primary control |
|---|---|---|---|
| Credential | Cards, fobs, mobile credentials, PIV cards | Static IDs that can be read and copied at a distance | Cryptographic credentials with mutual authentication |
| Reader | Card readers, keypads, biometric readers | Tamper, exposed wiring, readers that pass only a card number | Tamper switches, secure mounting, readers that validate cryptographic credentials |
| Reader to controller link | Wiegand or OSDP over RS-485 | Wiegand is one-way and unencrypted; data can be captured and replayed with an inline device (ATT&CK T1200 Hardware Additions) | OSDP with Secure Channel and supervision |
| Door controller or panel | Intelligent controllers, I/O modules | Default passwords, web interfaces, unpatched firmware, flat networks | Segmentation, hardening, firmware management |
| Head-end server and clients | PACS software, database, operator workstations, visitor systems | Windows servers outside IT patching, shared operator accounts, integration accounts with broad rights | Tier-one server management, SSO and MFA, least privilege |
| Integrations | HR, identity provider, video, alarm and building systems | Over-privileged API or database accounts | Scoped service accounts, vaulted secrets, monitored interfaces |
Credential technology choices
| Credential type | How it authenticates | Assurance | Guidance |
|---|---|---|---|
| 125 kHz proximity | Broadcasts a static number | Low: can be read and copied | Retire; never use for restricted areas |
| 13.56 MHz legacy smart cards using broken proprietary cryptography (for example MIFARE Classic) | Weak or broken cryptography | Low | Plan replacement; treat as equivalent to proximity |
| AES-based smart cards (for example DESFire EV2/EV3 class) | Mutual authentication with diversified keys | Medium to high, depending on key management | Good default for enterprises; own and protect the keys |
| Mobile credentials (BLE or NFC) | Cryptographic credential on a managed phone | Medium to high | Useful for distributed estates; depends on phone security and issuance process |
| PIV and PIV-I (FIPS 201) | PKI with card authentication key and optional PIN or biometric | High | Required in US federal facilities; follow NIST SP 800-116 Rev. 1 |
- Key ownership: for smart card systems, find out who holds the site keys. Supplier-default or shared keys across many customers reduce a strong card to a weak one. Prefer customer-specific keys held by your organisation or a trusted programmer.
- Multi-factor at the door: NIST SP 800-116 Rev. 1 sets one factor for Controlled areas, two for Limited and three for Exclusion areas, and recommends PKI-AUTH (card plus PIN) and PKI-CAK while deprecating CHUID, which it says gives little or no confidence. The same tiering works outside government.
- Biometrics: plan a fallback for people whose biometrics cannot be enrolled, as SP 800-116 notes, and treat templates as sensitive data. See the Biometrics Guide.
OSDP and Secure Channel in depth
The Open Supervised Device Protocol (OSDP), maintained by the Security Industry Association (SIA), defines communication between an access control panel (the control panel, CP) and peripheral devices (PDs) such as readers, normally over two-wire RS-485 multi-drop serial. IEC approved it as IEC 60839-11-5:2020 in May 2020, and SIA released version 2.2.2 in October 2024. Compared with Wiegand it is bidirectional, supervised (a disconnected or failed reader is reported), multi-drop and able to carry smart card and biometric data.
How Secure Channel keys work
- SCBK: the Secure Channel Base Key is the per-reader key from which session keys are derived. The panel holds one SCBK per reader.
- SCBK-D: the specification defines a default key that is public. It is used only while a reader is in install mode, so that the panel can send it a unique SCBK with the KEYSET command.
- Install mode is insecure by design: the libosdp documentation describes how a rogue device answering at a previously secured address could be offered a session on the default key and receive the real SCBK, and notes that a physical switch to force install mode can be used by anyone with physical access.
- Latching: good panel implementations refuse the default key for a reader once it has completed a handshake on its own key. Ask suppliers whether their panels do this and whether the latch survives a restart.
Secure Channel configuration checklist
- Require Secure Channel on every reader link; reject readers or panels that only support plaintext OSDP.
- Provision a unique SCBK per reader during commissioning and confirm each reader has left install mode.
- Configure the panel to refuse unencrypted communication from readers that previously used Secure Channel, and to alarm on a fall back to plaintext or on key reset.
- Record SCBKs in a protected key store, not in commissioning spreadsheets.
- Prefer SIA OSDP Verified products, which have been tested for conformance with the standard.
Migrating from Wiegand to OSDP
- Survey: list every door with reader model, protocol, wiring (cable type and conductor count), controller port type and the area classification. Older Wiegand runs often use multi-conductor cable that can carry RS-485 if the pairs and distances suit it.
- Prioritise by risk: start with Limited and Exclusion areas, external doors and doors where the reader wiring is reachable from outside the secure side.
- Check controller support: many current controllers support OSDP on the same reader ports by configuration; older panels may need interface modules or replacement.
- Pilot: convert a few doors, confirm Secure Channel, supervision alarms, card read times and any keypad or LED behaviour, and train the monitoring desk on new alarms.
- Roll out by zone: keep a documented rollback (the previous reader and configuration) for each door until the zone has run cleanly for an agreed period.
- Change credentials alongside: migrating the wire while keeping proximity cards leaves the card as the weakest link. Plan card reissue in the same programme where budget allows.
- Remove legacy paths: disable Wiegand inputs that are no longer used so that a device cannot be attached to them later.
Interim protection where Wiegand stays: mount readers with tamper detection, run cables inside conduit on the secure side, monitor reader tamper and door forced or held alarms, and add a second factor (PIN) on sensitive doors.
Hardening controllers and head-end servers
- Segmentation: place controllers on a dedicated PACS network; only the head-end server and a management host may reach them. No internet exposure (ATT&CK for ICS T0883 Internet Accessible Device describes how exposed devices are found). See the Network Segmentation Guide.
- Known exploited flaws: CVE-2019-7256, an OS command injection in Nice Linear eMerge E3-Series controllers, was added to the CISA KEV catalogue on 25 March 2024; CISA's required action is to contact the vendor for firmware remediation. Check every controller model against KEV and supplier advisories. See the ICS Advisory Triage and OT Vulnerability Management Guide.
- Controller configuration: unique admin passwords, web interfaces disabled or restricted to HTTPS from the management host, unused services off, encrypted communication to the head-end where supported, firmware kept within supplier support.
- Head-end servers: patch the operating system and PACS software on a defined cycle, run EDR, back up the database and configuration, and restrict database access to the application.
- Operators: named accounts through SSO with MFA, roles that separate badge issuing, door schedule changes and system administration, and logs of every manual door unlock.
- Safety: doors on egress routes must fail safe for fire and life safety codes; hardening must never block egress. Test fire alarm integration after every change.
Where identity fits
PACS is an identity system with physical consequences. Cardholder records should be created, changed and removed from the HR source and identity platform, not by hand at the security desk, so that a leaver's badge is disabled at the same time as their directory account. Integrations that do this (HR feeds, SCIM or database connectors, visitor management, video and alarm links) run on service accounts that can grant door access, so scope them tightly, vault their secrets and alert on changes they make outside expected jobs. Contractors and visitors need expiry dates on every badge. See the Joiner-Mover-Leaver Guide, the Contractor Identity Lifecycle Guide and the Device and IoT Identity Guide.
Decision guidance: what to fix first
| Situation | First priority | Then |
|---|---|---|
| Small office, single controller, proximity cards | Remove internet exposure, change controller defaults, link badge revocation to leavers | Replace cards and readers at next refresh with AES smart cards or mobile credentials over OSDP |
| Corporate estate, mixed sites | Inventory controllers and readers, segment PACS networks, central SSO for operators | Zone-by-zone OSDP Secure Channel and credential migration, starting with restricted areas |
| Data centres and critical infrastructure | Two or three factors at Limited and Exclusion areas, OSDP Secure Channel, tamper monitoring | Anti-passback, mantraps, integration of PACS events into the SOC |
| US federal facility | PIV authentication mechanisms per SP 800-116 Rev. 1 (PKI-AUTH, PKI-CAK; no CHUID) | Bidirectional infrastructure end to end, including OSDP Secure Channel |
Testing and assurance
Configuration on paper is not the same as a secure door. Build testing into commissioning and repeat it on a schedule.
- Commissioning acceptance: for every converted door, confirm in the panel that the reader link shows Secure Channel active with a unique key, that disconnecting the reader raises a supervision alarm within the expected time, and that tamper, forced and held alarms reach the monitoring desk.
- Credential checks: sample active credentials each quarter to confirm that legacy card types are falling, that every badge maps to a current HR or contractor record and that visitor badges expire as configured.
- Network and controller review: include PACS networks in authenticated vulnerability scanning where the supplier confirms it is safe, or use passive discovery, and review firewall rules between PACS, video and corporate networks at least annually.
- Authorised physical testing: commission independent testers under a written scope to attempt tailgating, credential copying and reader tampering at representative doors, and feed findings into the migration plan. See the Social Engineering and Physical Penetration Testing Guide.
- Change control: treat door schedule changes, new readers and firmware updates as changes with approval, a backup of the panel configuration and a rollback plan.
Detection and measurement
- Send PACS events to the SIEM: door forced, door held, reader tamper, OSDP reader offline or Secure Channel failure, invalid card reads, manual unlocks, badge record changes and operator logins.
- Correlate with logical access: badge-in at one site with a VPN login from another country, after-hours access to restricted rooms, and use of a leaver's badge. See the Physical Security Guide for Security Teams for convergence models.
- Median time from HR leaver event to badge disabled (target: same day, ideally minutes).
- Percentage of reader links using OSDP with Secure Channel, by area classification.
- Percentage of active credentials that are cryptographic rather than static-ID.
- Number of controllers with default passwords, unsupported firmware or KEV-listed flaws (target zero).
- Number of PACS devices reachable from outside the PACS network.
- Door forced and held alarms per month with documented response.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05, PR.AA-06, DE.CM-02 | Access permissions, physical access managed commensurate with risk, monitoring the physical environment |
| NIST SP 800-53 Rev. 5 | PE-3, PE-3(1), PE-6, PE-8, AC-2, SC-7, SI-2 | Physical access control, system access, monitoring, visitor records, account management, segmentation, flaw remediation |
| NIST SP 800-116 Rev. 1 | Controlled, Limited, Exclusion areas | Factors and PIV authentication mechanisms per area |
| IEC 60839-11-5:2020 | OSDP | Reader to controller communication, Secure Channel |
| ISO/IEC 27001:2022 | A.7.1, A.7.2, A.5.18 | Physical security perimeters, physical entry, access rights |
| MITRE ATT&CK | T1200, T1557, T0883 | Hardware Additions, Adversary-in-the-Middle, Internet Accessible Device |
| MITRE D3FEND | D3-MAN, D3-NI | Message Authentication, Network Isolation |
Common failure patterns
- OSDP without Secure Channel: readers upgraded to OSDP but left in plaintext or on the default key, giving supervision without confidentiality.
- Secure wire, cloneable card: money spent on readers and cabling while 125 kHz cards remain in use.
- Controllers on the corporate LAN with factory passwords: installed by an integrator, never added to the asset inventory or vulnerability scanning.
- Manual badge administration: leavers and contractors keep working badges for weeks because the desk is not told.
- Shared operator accounts: nobody can say who unlocked a door remotely or changed a schedule.
- Integrator remote access left open: permanent VPN or remote desktop into the head-end for support. See the OT Remote Access Guide.
Practitioner checklist
- Inventory every reader, controller, server and integration with protocol, firmware and support status.
- Classify areas (Controlled, Limited, Exclusion or equivalent) and set required factors per area.
- Require OSDP with Secure Channel and unique SCBKs; confirm no reader remains in install mode.
- Plan retirement of proximity and broken-cryptography cards; own the smart card keys.
- Segment PACS networks and remove all internet exposure of controllers and servers.
- Check controller models against CISA KEV and supplier advisories; patch or replace.
- Drive cardholder lifecycle from HR and the identity platform; expire contractor and visitor badges.
- Use named operator accounts with SSO, MFA and role separation.
- Feed PACS alarms and changes into the SIEM and correlate with logical access.
- Test fire and life safety behaviour after every PACS change.
Standards and references
- Security Industry Association: Open Supervised Device Protocol (OSDP)
- NIST: SP 800-116 Rev. 1 Guidelines for the Use of PIV Credentials in Facility Access
- LibOSDP: Secure Channel documentation
- LibOSDP: Open source implementation of IEC 60839-11-5
- CISA: Known Exploited Vulnerabilities Catalog
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Physical Security Guide for Security Teams · Physical and Environmental Security Policy Template · IP Camera and CCTV Security Guide · Social Engineering and Physical Penetration Testing Guide · IoT Security Guide