Choosing Credentials for Commercial Access Control

The credential is the part of an access-control system that employees notice, but it is not the whole security decision. A card, fob or phone can be convenient and still sit inside a weak process. A technically strong credential can also fail operationally if enrolment is careless, temporary access never expires, lost credentials remain active or facilities staff cannot issue replacements during an outage.

For IT and facilities leaders, the useful question is therefore not “Which credential is best?” It is: Which credential model provides enough assurance for each opening while remaining supportable across its full lifecycle? That decision includes the credential, reader, reader-to-controller communication, identity records, issuance, revocation, privacy, door hardware, emergency operation and migration path.

Executive decision: choose a model, not a token

A defensible credential strategy should produce six decisions before products are ordered:

1. the assurance required for each door or zone;
2. the approved credential types and where each may be used;
3. how identities are verified before issuance;
4. who can issue, change, suspend and revoke access;
5. how the organization will operate through phone, network, power and vendor outages; and
6. how legacy credentials will be removed without disrupting the business.

These choices should be documented in a short credential policy and a door-by-door matrix. They can then guide the detailed design of a new commercial access-control system or the modernization of a wider commercial security program.

1. Start with the consequence of a false acceptance

Using one credential rule everywhere is easy to administer but rarely reflects actual risk. A public lobby-to-office door, a general employee entrance, a server room and a controlled inventory cage do not have the same consequence if the wrong person is admitted.

Classify openings into a small number of assurance tiers. For each tier, document:

• who should be admitted and under what conditions;
• whether access is scheduled, supervised or continuously available;
• the consequence of a copied, borrowed or incorrectly issued credential;
• whether one factor is sufficient;
• how quickly access must be revoked after a reported loss or role change;
• whether an offline controller must continue making decisions; and
• the acceptable fallback when the normal credential is unavailable.

This is a risk decision, not a race toward the most complex technology. NIST’s facility-access guidance for PIV credentials is written for United States federal facilities, not ordinary Canadian businesses, but its central planning principle is broadly useful: authentication mechanisms should be selected using risk rather than convenience alone. A commercial organization does not need to reproduce the PIV program to apply that discipline.

2. Compare credential options by operating burden

The familiar form factors are not mutually exclusive. A strategy may use secure cards for the workforce, mobile credentials for a defined group, time-limited visitor records and a second factor at a small number of higher-risk doors.

Credential model	Practical strengths	Operational burdens and failure modes
Card or fob	Familiar, quick to present, easy to keep separate from a personal phone	Can be shared or lost; weak legacy technologies may be copied; inventory, printing and replacement require administration
Mobile credential	Remote delivery can shorten issuance; people often notice a missing phone quickly; can reduce physical-card inventory	Phone compatibility, battery state, device replacement, app support, connectivity assumptions, privacy expectations and BYOD policy must be resolved
PIN	No physical item to carry; useful as a second factor or controlled fallback	Can be observed, shared or forgotten; shared PINs destroy accountability; keypad use can slow throughput
Biometric	Binds access to a physical or behavioural characteristic and cannot be casually loaned like a card	Sensitive personal information, accuracy and accessibility concerns, difficult revocation after compromise, higher governance burden
Multiple factors	Raises assurance when factors are genuinely independent	More training, more lockouts, longer transactions and more support calls; poor fallback design can quietly reduce the intended assurance

Do not score only acquisition price. Record the time needed to enrol a new hire, recover from a lost phone, replace a damaged card, support a contractor after hours, audit dormant credentials and remove access during urgent offboarding. Those repeated tasks often cost more over the system’s life than the token itself.

3. Distinguish secure smart credentials from visible form factor

Two cards that look identical can behave very differently. A procurement specification should identify the credential technology, authentication method and key-management expectations—not merely request a “proximity card” or “smart card.”

For example, NXP’s current MIFARE DESFire EV3 product documentation describes support for AES-128, application-level authentication, encrypted radio-channel data, multiple key sets, transaction controls and a proximity check. Those are capabilities of one chip family, not proof that every finished card-and-reader deployment uses them correctly. Key diversification, reader configuration, issuance and system integration still matter.

Ask vendors to state clearly:

• whether the credential performs mutual or cryptographic authentication rather than transmitting a static identifier;
• which algorithms and key lengths are actually enabled in the proposed configuration;
• whether customer-specific keys are used and who controls them;
• whether one lost or compromised key can affect the entire credential population;
• how keys are backed up, rotated and transferred at contract end;
• whether the organization can obtain credentials from more than one approved source; and
• which legacy modes remain active in readers during and after migration.

Avoid treating a manufacturer family name as the security result. Require a configuration schedule and an acceptance test that demonstrates the proposed mode.

4. Protect the path after the credential is read

A strong card or mobile credential does not protect data that leaves the reader through an unprotected legacy interface. The reader-to-controller connection is part of the credential decision.

The Security Industry Association’s current Open Supervised Device Protocol overview explains that OSDP supports bidirectional communication, device supervision, smart-card applications and Secure Channel encryption between access-control panels and peripherals. OSDP was published as IEC 60839-11-5:2020, but a product advertising “OSDP support” does not by itself prove that Secure Channel is configured or that the exact reader/controller combination has been independently verified.

For a new or renovated system, require the integrator to document:

• the reader-to-controller protocol at every opening;
• whether encrypted Secure Channel mode is enabled;
• how unique keys are established and protected;
• which reader and controller firmware versions were tested together;
• whether device supervision produces actionable alarms; and
• how the installation will be verified after commissioning or reader replacement.

This is also a migration issue. A multi-technology reader may help old and new credentials coexist, but continued acceptance of the old technology preserves its risk. Give compatibility a defined end date.

5. Design the issuance and revocation lifecycle first

Credential security begins before the first door transaction. The organization must decide how a person is identified, how a record is created, what evidence authorizes each permission and when the credential expires.

The Office of the Privacy Commissioner of Canada’s identification and authentication guidelines recommend collecting only necessary identity attributes, matching authentication strength to risk, relying on trusted credentials, training employees, maintaining appropriate transaction records and reassessing threats. The guidance is framed around PIPEDA and is not a substitute for legal advice about a specific Ontario employer, but it provides a useful governance checklist.

Create explicit workflows for:

• employees, contractors, vendors, visitors and temporary labour;
• approval by role, site, zone and time schedule;
• identity verification before first issuance;
• activation dates and automatic expiry dates;
• duplicate and replacement credentials;
• lost, stolen, forgotten or damaged credentials;
• leaves of absence, transfers and urgent termination;
• access reviews by the responsible manager; and
• disposal or cryptographic retirement at end of life.

Avoid permanent “temporary” credentials and shared cards. Every exception should have an owner, reason and expiry. The system should make overdue access visible rather than relying on someone to remember it.

6. Treat mobile credentials as an operating model

Mobile access can simplify remote delivery, but it transfers part of the system boundary onto a device the organization may not own. Before selecting it, answer practical questions:

• Are corporate and personal phones both permitted?
• Which operating-system and hardware versions are supported?
• Does presentation work when the phone is locked, offline or in low-power mode?
• What happens when a user changes phones or restores a backup?
• Can administrators revoke the access credential without controlling personal content?
• What information can the credential provider, wallet provider or platform operator observe?
• Is a physical alternative available for accessibility, privacy or operational reasons?
• What is the after-hours process when a phone is dead, lost or incompatible?

Pilot mobile access with representative users, not only the project team. Include shift workers, employees with older supported devices, users who decline BYOD, reception staff and the people who handle urgent replacements. Measure enrolment completion, help-desk effort and door transaction reliability before broad rollout.

7. Use biometrics only for a proportionate, governed need

Biometrics can add assurance, but their persistence changes the consequence of misuse or breach. A card can be revoked and replaced. A fingerprint or face cannot be reissued in the same way.

The Office of the Privacy Commissioner of Canada’s 2025 guidance for businesses processing biometrics calls for an appropriate purpose, consent, limited collection and retention, safeguards, accuracy, accountability and openness. It also notes that storage on a device or portable token may reduce some risks compared with a central biometric repository. Applicability depends on the organization and governing law; Ontario private-sector employment privacy can be legally complex.

Before approving biometric access, document:

• why a card, mobile credential or second factor cannot meet the objective;
• whether matching occurs locally or against a central database;
• whether raw samples are retained or converted into protected templates;
• accuracy and failure rates for the actual workforce and environment;
• accommodations and a non-biometric alternative;
• retention, deletion and breach-response procedures; and
• who can administer, export or audit the biometric system.

Convenience alone is a weak reason to create an enduring biometric dataset.

8. Keep credential decisions separate from safe egress

Access authorization controls entry; life-safety requirements govern how people leave. Credential selection must not create an exit that requires a card, phone, PIN or specialized knowledge where ready egress is required.

Ontario’s current Fire Code provisions for locking and egress state, with defined exceptions, that required exit doors and certain doors in access-to-exit routes must be readily opened without keys, special devices or specialized knowledge. The regulation also contains specific conditions for electromagnetic locking and particular occupancies. The applicable Building Code, Fire Code, approved design and authority having jurisdiction should be confirmed for each door; a credential strategy article cannot determine code compliance for a specific property.

Put egress, fire-alarm release, emergency unlocking, mechanical hardware and accessibility into the door schedule. Test them independently of a successful credential read.

9. Build a controlled migration instead of an endless overlap

A safe migration begins with an inventory: credential technologies, active credential counts, readers, panels, interfaces, key ownership, card printers, enrolment stations, integrations and doors that cannot tolerate downtime.

Then define phases:

1. bench-test the new credential, reader, controller and management workflow;
2. pilot a contained group with measurable support and transaction results;
3. issue new credentials with verified identities and expiry rules;
4. convert doors in logical zones with a documented rollback method;
5. monitor denied access, help-desk demand and security alarms;
6. disable legacy acceptance on a published date; and
7. confirm that readers no longer accept retired credentials or insecure modes.

Dual-technology operation is a transition tool, not an end state. If there is no retirement date, the organization pays for the new credential while retaining the old exposure.

10. Use a decision scorecard and acceptance tests

Score each candidate model against the same evidence. A useful matrix covers security assurance, interoperability, privacy, user experience, accessibility, issuance effort, revocation speed, outage behaviour, vendor dependence, migration complexity and five-to-ten-year operating cost.

Require vendors to demonstrate, using the proposed production configuration:

• enrolment and first issuance;
• a normal card or mobile transaction at representative doors;
• immediate revocation and subsequent denial;
• replacement after a lost phone or card;
• offline behaviour at the controller;
• expiry of a contractor credential;
• alarm behaviour when reader communication is interrupted;
• recovery after power and network restoration;
• export of credential and access-review records; and
• successful egress and emergency release without a credential.

Record the result, firmware, settings and responsible person. A sales demonstration proves that a feature can work somewhere; an acceptance test proves that the approved design works in the organization’s environment.

Vendor questions worth asking

1. What credential technology and authentication mode are enabled—not merely supported?
2. Who owns the cryptographic keys, and can they be transferred securely to another integrator?
3. Which legacy technologies and interfaces will remain active after migration?
4. How are mobile credentials revoked when the organization does not manage the phone?
5. What personal information is collected by each service provider, where is it stored and for how long?
6. Which functions continue during internet, cloud, phone, network and power failures?
7. How are contractor expiry and manager access reviews enforced?
8. What evidence will demonstrate Secure Channel, reader supervision and credential revocation?
9. Which parts of the solution require subscriptions, and what happens if they end?
10. How will the organization retrieve records, configurations and keys at contract termination?

The best credential strategy is not the one with the newest form factor. It is the one that produces appropriate assurance, predictable administration, a credible privacy position and a tested path through everyday failures. Decide those outcomes first, then select the card, phone, reader and platform that can demonstrate them.