A physical access control system (PACS) is now an IT system with network-connected controllers, cloud consoles and an identity feed, and buying one on hardware features alone leaves security gaps that last for a decade. PACS purchases are long-lived: readers, wiring and controllers often stay in place for ten years or more, so choices about reader protocol, credential technology and identity integration are expensive to reverse. This vendor-neutral buyer's guide is for security, facilities and IT teams writing an RFP for a new or replacement PACS, whether on-premises, hosted or cloud-managed. It covers requirements, deployment models, evaluation criteria, questions and red flags, and a proof of concept plan. For how to secure a PACS you already run, see the Physical Access Control Systems Security Guide.
Key takeaways
- Specify OSDP with Secure Channel between controllers and readers, and treat Wiegand-only hardware as a legacy constraint, not an option.
- Choose credentials for the next decade: AES-based smart cards, mobile credentials or PIV, never 125 kHz proximity for new deployments.
- Make the identity feed a hard requirement, so joiners, movers and leavers in HR or the IdP change door access automatically.
- Evaluate the vendor's own security, especially support access to cloud consoles and controller firmware updates.
- Prove it in a pilot with your real doors, your real leaver process and a forced-failure test before signing.
Define requirements
Write these down before talking to vendors. They decide the shortlist more than any feature list does.
- Estate: number of sites, doors, readers and controllers today and in five years; lifts, turnstiles, car parks and gates; existing wiring (Wiegand data lines or RS-485 two-wire).
- Risk zones: which areas need one, two or three factors. NIST SP 800-116 Rev. 1 uses Controlled, Limited and Exclusion areas with one, two and three authentication factors respectively, a useful model even outside government.
- Population: employees, contractors, visitors, cleaners, delivery staff and tenants, and who is the authoritative source for each.
- Compliance drivers: PCI DSS Requirement 9 for cardholder data environments (see the PCI DSS Requirement 9 Guide), ISO/IEC 27001:2022 Annex A 7.2 Physical entry, NIST SP 800-53 PE-2, PE-3, PE-6 and PE-8, sector rules for data centres, healthcare or critical infrastructure.
- Government needs: US federal buyers need products on the GSA FIPS 201 Approved Products List and PIV authentication; other buyers may still use PIV-I or similar PKI cards.
- Integration: HR system, identity provider, visitor management, video surveillance, intrusion alarms, building management and the SIEM.
- Operating model: who runs it day to day (facilities, security operations or an integrator), and whether you want to own servers at all.
Deployment models compared
| Model | Strengths | Watch for | Fits |
|---|---|---|---|
| On-premises head-end server and controllers | Full control of data and network placement; works with no internet link; suits air-gapped or classified sites | You own patching of the server, database and operating system; upgrades are projects; integrator dependence | High-security sites, regulated estates with in-house operations teams |
| Hosted or managed PACS (provider runs the server) | Patching and backups handled by provider; existing controllers can often stay | Provider and integrator remote access paths; contract must cover security obligations and logs | Organisations without server operations staff that keep existing hardware |
| Cloud-managed PACS (cloud console, local controllers) | Fast multi-site rollout, mobile credentials, API-first integration, frequent updates | Vendor support access to your tenant, console account security, behaviour during internet loss, data residency, vendor lock-in of controllers | Multi-site offices, retail, mid-size organisations with lean facilities teams |
| Hybrid (cloud management, on-premises fallback or edge server) | Central management with local resilience | Two sets of controls to secure; synchronisation conflicts | Large estates mixing headquarters and branch sites |
For federal topology, GSA's FIPS 201 Evaluation Program approves PACS as complete tested solutions (topology 13.01 end-to-end, or 13.02 where a combined PACS validation infrastructure integrates with a separately approved PIV reader), with cloud variants where applicable, and readers are approved only as part of a tested solution. Agencies must still check that the hosting architecture, for example FedRAMP for cloud, meets their requirements.
Evaluation criteria
| Area | What good looks like | How to verify |
|---|---|---|
| Reader protocol | OSDP v2 with Secure Channel (AES-128) on every reader; OSDP Verified devices; supervision so tampering or disconnection raises an alarm | SIA OSDP Verified listing; demonstrate secure channel on, and a disconnected reader alarm |
| Secure Channel key handling | Unique Secure Channel Base Key per reader, install mode used only for provisioning, keys changed from the specification default, keys exportable only under control | Ask the vendor to show key provisioning and what happens if a reader is replaced |
| Credential technology | AES-based smart cards with diversified keys, mobile credentials in the device wallet or app, PIV or PKI cards where needed; proximity and MIFARE Classic only during migration | Card specification sheets; key ownership statement (you or the vendor) |
| Multi-factor at the door | Card plus PIN, card plus biometric, or PKI challenge-response for high-risk zones; configurable per door and schedule | Configure a two-factor zone in the pilot |
| Identity lifecycle integration | SCIM or API provisioning from the IdP or HR system; role- or attribute-based access levels; automatic suspension on leaver events | Time a leaver in the pilot from HR change to door denial |
| Controller security | Signed firmware, secure boot, no default credentials, encrypted controller to server traffic, local event buffering | Hardening guide, firmware signing description, penetration test summary |
| Head-end and console security | SSO with MFA for operators, role-based operator permissions, audit of every configuration change, no shared admin accounts | Admin role matrix; export of operator audit log |
| Resilience | Controllers keep making decisions with cached rights when the server or cloud link is down; defined fail-safe and fail-secure per door; life safety egress unaffected | Pull the uplink during the pilot |
| Logging and integration | Streaming events (granted, denied, forced, held open, tamper) to the SIEM; video linkage; open APIs and webhooks | Send events to your SIEM in the pilot and check field quality |
| Vulnerability handling | Published security advisories, CVE disclosure policy, patch timelines, product end-of-life dates | Review the vendor's advisory history and the CISA Known Exploited Vulnerabilities catalogue for their products |
Access control controllers do appear in the CISA Known Exploited Vulnerabilities catalogue: for example CVE-2019-7256, an OS command injection in Nice Linear eMerge E3-Series controllers, was added in March 2024. A vendor's handling of such issues is a buying criterion, not an afterthought.
Evaluating the vendor's own security
- How do your support staff and integrators reach our tenant, controllers or server, and can we approve, time-limit and log each session?
- How is firmware built, signed and delivered, and can we stage updates on a pilot site first?
- Where are credential keys, cardholder data and event logs stored and processed, and who in your organisation can read them?
- What independent certifications and penetration test results can we see for the cloud service, controllers and mobile apps?
- What is your vulnerability disclosure policy and your track record of advisories in the last three years?
The Verkada camera breach showed how a cloud-managed physical security vendor's own administrative access can expose every customer at once, which is why support access belongs in the contract.
Where identity fits
A PACS is an identity system with doors attached. Every cardholder record should map to a person in your authoritative source, and leavers should lose door access as fast as they lose network access. See the Joiner-Mover-Leaver Guide. The platform also carries non-human identities that buyers forget: integration service accounts that pull HR data, API keys used by visitor management and video systems, and controller-to-cloud certificates. Ask how each is created, scoped, rotated and revoked, and whether operator and API access can use your SSO and secrets tooling instead of local passwords. For converged teams, see the Physical and cyber security convergence guide.
Framework mapping
| Framework | Reference | What it asks of the PACS |
|---|---|---|
| NIST CSF 2.0 | PR.AA-06, DE.CM-02 | Physical access managed and enforced commensurate with risk; physical environment monitored |
| NIST SP 800-53 Rev. 5 | PE-2, PE-3, PE-6, PE-8 | Access authorisations, physical access control, monitoring physical access, visitor access records |
| ISO/IEC 27001:2022 Annex A | 7.1, 7.2, 5.18 | Physical security perimeters, physical entry, access rights |
| CIS Controls v8.1 | Control 6 Access Control Management | Granting and revoking access through a defined process |
| MITRE ATT&CK | T1200 Hardware Additions | Physical access enables rogue devices on the network; door logs support investigation |
| Standards | IEC 60839-11-5:2020 (OSDP), NIST SP 800-116 Rev. 1, FIPS 201 | Reader communications, PIV use in PACS, federal credential requirements |
Questions to ask vendors
- Show OSDP Secure Channel enabled on every reader model you propose. How are per-reader keys set, and what happens if someone triggers install mode on a live reader?
- Which of your readers and controllers are OSDP Verified, and which still need Wiegand?
- Who owns the card encryption keys, and can we move to another vendor's readers without reissuing every card?
- How do mobile credentials work on lost or replaced phones, and can we require device unlock for high-risk doors?
- How does your platform receive joiner, mover and leaver events, and what is the typical time from HR termination to door denial?
- What happens at each door type when the network, server or cloud is unavailable for one hour and for one day?
- Which events can we stream to our SIEM, in what format, and with what delay?
- What is the support life of each controller and reader model, and what does a forced hardware refresh cost us?
- How are operator accounts authenticated, and can we enforce SSO with phishing-resistant MFA for administrators?
- For federal buyers: which complete solution on the FIPS 201 APL are you proposing, and which topology?
Red flags
- Readers that support only Wiegand, or OSDP offered without Secure Channel or with the default key left in place.
- 125 kHz proximity or MIFARE Classic proposed as the primary credential for a new installation.
- Card keys held only by the vendor, which locks you into their readers and their card supply.
- No identity integration beyond CSV import, or leaver processing that depends on a facilities team ticket.
- Vendor or integrator remote access that is always on, shared between staff, or not logged.
- No published security advisories or vulnerability disclosure policy, or controllers past end of support.
- Cloud platforms that cannot explain door behaviour during an outage, or that change fail-safe settings without change control.
Proof of concept
- Pick a pilot site with a mix of door types: main entrance, a high-risk room, a fire exit with alarm monitoring, and a lift or turnstile if you have them.
- Install the proposed readers with OSDP Secure Channel and unique keys; confirm a disconnected or swapped reader raises an alarm.
- Issue the proposed card and mobile credentials to a pilot group; test enrolment, loss, replacement and revocation.
- Connect the identity feed; run a joiner, a mover and a leaver end to end and record the time to effect at the door.
- Configure a two-factor zone (card plus PIN or biometric) and a time schedule; check denied events are logged with reasons.
- Stream events to the SIEM; build alerts for forced doors, held-open doors, tamper and access by suspended cardholders.
- Pull the network uplink and the server or cloud link; confirm cached decisions, life safety egress and event back-fill afterwards.
- Run an authorised physical penetration test or reader assessment. See the Social Engineering and Physical Penetration Testing Guide.
- Agree the migration and rollback plan: dual-technology readers or multi-technology cards during transition, and how to revert a site if the cutover fails.
Useful pilot measures: leaver time to door denial, percentage of readers on OSDP Secure Channel, percentage of credentials on legacy technology, forced and held-open door alarms per week, and operator accounts without MFA.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support across identity, access and the converged physical and cyber estate. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Physical Access Control Systems Security Guide · Physical Security Guide for Security Teams · IP Camera and CCTV Security Guide · Biometric Authentication Platforms Buyer's Guide · Physical Security Site Assessment Checklist