Key Card Access Control Systems: How They Work and What to Consider

A key card access control system governs who can enter a facility by replacing mechanical locks with electronic credential verification. The system reads data from a card or mobile device, checks that data against stored permissions, and releases a lock only when conditions are met.

Understanding how the system works, where it breaks down, and what compliance obligations apply is foundational to sound procurement and configuration decisions.

From Card Tap to Door Release

A Physical Access Control System (PACS) processes every access attempt through a signal flow from credential to reader, reader to controller, controller decision logic, lock actuation, and finally audit trail generation. Each phase introduces distinct security properties and failure modes.

Credential-to-Reader Communication

When a cardholder presents a credential to a reader, the interaction depends on the underlying RF technology. A legacy proximity card is energized by the reader's RF field and automatically broadcasts its facility code and card number. No command from the reader is required, and no cryptographic exchange occurs.

A smart card operating under common contactless card standards behaves differently. The interaction uses a command-response model rather than automatic transmission, which enables mutual authentication and PKI operations that proximity cards cannot support.

Reader-to-Controller Transmission

The reader passes credential data to a controller through a wired communication protocol. The protocol selected at this layer determines whether the credential's security properties survive the journey. A protocol that transmits data in cleartext strips away any encryption the card performed, reducing a cryptographically capable credential to a simple identifier.

The two dominant protocols, Wiegand and OSDP, differ fundamentally in their security architecture. Wiegand transmits unencrypted, one-way pulses, while OSDP supports bidirectional, encrypted communication.

Controller Decision Logic

The controller evaluates the credential against a sequential checklist: credential lookup, activation and expiration dates, access group membership, time schedule, anti-passback status, and any supplemental rules such as two-person control. Every check must pass. A single failure results in denial, and the system logs the event.

Lock Actuation and Audit Logging

On a granted access event, the controller activates a relay output to release the electrified lock. Two primary lock behaviors govern door hardware: fail-secure locks require power to unlock and remain locked during power loss, while electromagnetic locks (maglocks) require continuous power to stay locked and release when power fails.

Door position sensors detect forced-door and held-door conditions that credential authentication alone cannot identify. Request-to-exit devices signal the controller to release the lock on egress without generating false alarms. Backup power supplies maintain controller operation and local event journaling during outages.

Every access event generates an audit record containing the event type, timestamp, reader location, credential holder identity, and outcome. Administrators should disable credential records rather than delete them upon revocation, preserving audit data for investigations.

Credential Technologies and Their Security Properties

Credential selection has the longest operational tail of any PACS decision. The technology chosen will often constrain security posture and migration costs over a long deployment lifecycle. A principle that applies across every credential type: the security a credential achieves depends on the full stack, including the card technology, the reader-to-controller protocol, and the authentication mechanism selected. A cryptographically capable smart card connected via a legacy protocol that strips its encryption provides no meaningful advantage over a proximity card.

Proximity Cards

These cards transmit a static identifier without encryption. These credentials provide negligible assurance, and they should be phased out of active deployments. Many organizations still operate with these credentials, meaning a substantial share of surveyed enterprises still rely on a technology that offers no cryptographic protection against cloning.

Encrypted Smart Cards

Cards such as MIFARE DESFire EV2 and EV3 support mutual authentication where both the card and reader verify each other's identity.

A critical distinction exists within this category. Frequency alone is not a security indicator. An enterprise audit must identify the specific card model and cipher, not merely the operating frequency.

Mobile Credentials

Smartphone-based credentials using NFC and Bluetooth Low Energy are increasingly used in access control and can offer security and management advantages over physical cards. In managed deployments, remote revocation is supported, reducing the terminated-credential risk that affects physical cards.

Mobile credentials are increasingly part of access control planning, especially where organizations want tighter issuance and revocation workflows.

Wiegand Versus OSDP at the Reader-Controller Layer

The protocol connecting readers to controllers is the layer most frequently overlooked during upgrades, and the layer where security most often breaks down silently.

Why Wiegand Is a Liability

The Wiegand protocol transmits data as unencrypted, one-way pulses from reader to controller. The format yields a small address space that creates collision potential at scale. The controller cannot verify reader integrity, send commands to the reader, or detect tampering.

OSDP as the Replacement Standard

The Open Supervised Device Protocol (OSDP), published as an international standard, addresses each of Wiegand's weaknesses. OSDP uses RS-485 wiring, supports bidirectional communication, encrypts data via Secure Channel, and provides native tamper detection. A growing roster of products carries SIA OSDP Verified certification.

Deploying OSDP requires one configuration discipline that practitioners must enforce: the default installation key (SCBK-D) must be replaced with a site-specific key before the system goes live, and install mode must be disabled after commissioning.

Common Vulnerabilities and Practical Mitigations

Card Cloning and Protocol Exploits

Legacy cards can be cloned from close proximity in an elevator, lobby, or parking area. The countermeasure is a credential upgrade to PKI-based or mobile credentials paired with OSDP Secure Channel at the reader-controller layer. Upgrading the credential without upgrading the protocol leaves the wire-level interception path open.

Tailgating, Piggybacking, and Credential Sharing

Tailgating and piggybacking affected organizations in the prior six months, making it the most commonly reported incident type. Propped doors and credential sharing were also widespread. Tailgating and credential sharing allow unauthorized individuals to enter despite cryptographically strong credentials.

Hard anti-passback enforcement denies re-entry until exit is logged. Physical barriers (mantraps, turnstiles, speed gates) enforce one-person-per-credential. Camera-based detection can identify multiple persons entering on a single badge event. No single countermeasure eliminates the risk. Layered deployment across physical barriers, policy enforcement, and detection technology addresses the problem from multiple directions.

Networked PACS as an IT Attack Surface

Controllers connected to IP networks inherit IT cybersecurity attack surfaces. Unchanged default passwords, outdated software, and issues such as expired certificates can affect systems like PACS. Network segmentation, mandatory MFA for administrative access, and a defined patch cadence from the vendor are operational requirements, not optional hardening steps.

Compliance Frameworks That Apply to Key Card Access Control

Multiple regulatory frameworks impose physical access control requirements, each with distinct scope and specificity.

• FIPS and HSPD: These apply to U.S. federal executive branch agencies and contractors with physical access to federally controlled facilities.
• HIPAA: 45 CFR § 164.310 requires covered entities to limit physical access to systems containing electronic protected health information. The rule is technology-neutral, mandating policies and safeguards without specifying credential type.
• PCI DSS: Applies to entities that store, process, or transmit cardholder data. Physical access to data and systems must be restricted, with audit logs and formally assigned roles and responsibilities as part of the standard's control structure.
• ISO 27001: The current revision reorganized physical security into a dedicated controls category. Organizations seeking certification must implement physical entry controls or formally justify their exclusion in a Statement of Applicability.

Practitioners should map all applicable mandates before issuing an RFP. Post-deployment compliance remediation is significantly more expensive than pre-procurement requirements definition.

Evaluating a Key Card Access Control System

Start with Risk Assessment, Not Product Selection

The ASIS Enterprise Security Risk Management framework establishes the premise that security requirements should be aligned with the organization's mission, informed by its assets, and shaped by identified risks and threats.

For multi-site deployments, risk assessment must be conducted at the site level, not only at the enterprise level. A warehouse, a data center, and a corporate lobby face different threats and require different credential and barrier configurations. Identifying which assets require the highest protection, and which threat vectors are most probable at each location, determines where to allocate budget for stronger credentials, physical barriers, or multi-factor authentication.

This assessment should be completed and documented before any RFP is issued, because procurement criteria that lack a site-specific risk basis routinely produce systems that over-protect low-value areas and under-protect high-value ones.

Specify the Protocol, Not Just the Credential

RFP documents should require OSDP with Secure Channel enabled on all reader and controller specifications. Wiegand-only readers are generally not recommended for new deployments; new installations are moving to OSDP instead. Requiring multi-technology readers in all new installations supports parallel operation of legacy and encrypted credentials during phased migration.

The RFP should explicitly prohibit cleartext reader-to-controller communication. Procurement teams can verify vendor claims against the SIA OSDP Verified product registry, which independently certifies protocol compliance.

Prioritize Integration Architecture

Security professionals continue to evaluate a range of technology upgrades to improve their systems. Video surveillance integration is a common PACS integration category, often relying on open standards and vendor APIs to connect access control and video systems. RFP evaluation should verify whether the integration is certified and tested or requires custom development, whether access events trigger automatic video retrieval, and what the latency is between an access event and video availability.

Visitor management integration often uses proprietary REST API or SDK approaches rather than ONVIF-standardized interfaces. This makes it more vendor-dependent. Building management system integration often operates under separate building automation protocols such as BACnet/IP, Modbus TCP, OPC UA, and KNX, with PACS connected through middleware or PSIM translation. Both represent important RFP evaluation points for multi-system environments.

Model Total Cost of Ownership over the Full Lifecycle

The purchase price is typically the smallest component of the full lifecycle cost. Software licensing, annual maintenance, credential replacement stock, administration staffing, help desk volume for credential requests, and eventual decommissioning all contribute.

Request itemized cost projections as a required RFP deliverable. Model the cost of not migrating from legacy credentials, including the operational and liability exposure of a credential cloning incident.

Plan the Migration Before Procurement

A phased approach begins with a full inventory of readers, controllers, credential types, firmware versions, and protocols at every site. Multi-technology readers deployed during infrastructure preparation allow legacy and encrypted credentials to operate in parallel.

New encrypted credentials are issued during natural replacement cycles (new hires, lost cards, role changes) to reduce forced re-badging costs. The project team must communicate a hard cut-off date for legacy credential acceptance to all cardholders. Administrators must disable legacy read capability once migration is complete.

Building a Resilient Access Control Foundation

Key card access control decisions made during a single procurement cycle will shape a facility's security posture for years. Selecting credential technology, reader-controller protocol, and integration architecture as a coordinated set, rather than as independent line items, produces systems where each layer reinforces the others instead of silently undermining them.

Frequently Asked Questions

How do I migrate from Wiegand to OSDP without replacing all existing readers and controllers at once?

Deploy multi-technology readers at high-risk locations first, then configure controllers to support the appropriate reader protocol during the migration. Replace remaining hardware during maintenance windows, prioritizing critical zones. Test encrypted channels before disabling legacy protocol support to prevent access disruptions.

What is the difference between fail-secure and fail-safe locks, and how do I decide which type to use for different areas of my facility?

Fail-secure locks remain locked without power, protecting assets in unoccupied zones. Fail-safe locks unlock without power, ensuring egress in occupied spaces. Choose based on life safety codes, occupancy patterns, and whether asset protection or emergency evacuation takes precedence.

Why does upgrading to encrypted smart cards provide no security benefit if the reader-to-controller protocol still uses Wiegand?

Wiegand transmits credential data between reader and controller as unencrypted electrical pulses on the Data 0 and Data 1 lines. This cleartext transmission exposes card data to wire-level interception, eliminating any cryptographic protection the smart card provided during authentication.