How to design multifactor authentication for physical access control by combining cards, PINs, and biometrics with risk, contingency, integration, and acceptance criteria.
Check it out!
Multifactor authentication in physical access control requires two or more independent pieces of evidence before passage is authorized. At a door, turnstile, mantrap, or other controlled point, this may mean combining a card and PIN, a mobile credential and biometrics, a card and biometrics, or another combination consistent with the risk. The objective is not simply to add a second step: it is to reduce the likelihood that a single lost, copied, shared, or compromised credential will be sufficient to release a critical area.
In the design of an EACS — Electronic Access Control System — MFA must be treated as an engineering requirement. It is necessary to define where two factors are actually required, which combinations are accepted, in what order they are presented, how the system behaves offline, how flow and accessibility are handled, which exceptions are permitted, which events must be logged, and how all of this will be demonstrated during FAT, SAT, and commissioning. Applying MFA without this architecture can produce queues, false rejections, operational bypasses, and contingencies that weaken the very control intended to be strengthened.
IEC 60839-11 provides the functional framework for physical electronic access control, while digital identity references such as NIST SP 800-63B help organize the concept of independent factors. These sources are not interchangeable: login authentication and authentication at a door have different operational requirements. Physical access design must additionally address controllers, readers, actuators, door sensors, continuity, emergency operation, anti-passback, passage capacity, integration, and field evidence.
What MFA means in a physical access control system
An access point typically executes a chain of actions: it receives an entry request, identifies or verifies a person, checks authorization rules, commands the physical point, and records the result. MFA appears when policy requires more than one category of evidence before authentication is considered sufficient.
The three classic categories are:
- something the person has, such as a smart card, mobile credential, or token;
- something the person knows, such as a PIN or another memorized secret;
- something the person is, such as a fingerprint, face, or palm, when biometrics is appropriate to the context.
Two methods from the same category do not necessarily create multifactor authentication. Two cards are still two pieces of possession evidence; two memorized questions are still knowledge. The gain comes from factor independence and the difficulty of compromising both through the same attack vector.
Identification, authentication, and authorization are different decisions
A user’s ID number may only locate a record. A card may identify the person or act as an authenticator, depending on the architecture. Biometrics may verify an identity already indicated by another credential or perform 1:N identification against a gallery. And even after the identity is authenticated, the person may still not be authorized for that area, time, or operating state.
This separation must appear in the event model. A denial due to an incorrect PIN is not the same as a denial due to schedule, anti-passback, or lack of privilege. Collapsing everything into “access denied” makes investigation, maintenance, and auditing more difficult.
In critical areas, the decision to require two factors must come from risk analysis, flow capacity, and failure behavior — not from the reader catalog.
Physical MFA is not the same as login MFA
NIST SP 800-63B-4 organizes digital authentication into factors and assurance levels. The concept of requiring distinct factors is useful for physical access control, but an EACS must manage variables that do not exist in an ordinary login.
Physical access involves mechanical barriers, opening time, passage, position sensors, held-open doors, forced doors, emergency conditions, loss of power, people flow, accessible routes, and tailgating risk. A policy that works well in a web application may be impractical at a turnstile during a shift change.
NIST SP 800-116 Rev. 1, focused on the use of PIV credentials for facility access, reinforces a particularly useful principle: the authentication mechanism should be selected according to risk and protection level rather than applied uniformly to every door.
When to require two factors
The main criterion should be the risk of unauthorized access combined with operational impact. Low-criticality areas may be adequately controlled with one robust factor; high-criticality areas may justify two factors, dual custody, or additional rules.
| Context | Risk example | Possible strategy |
| Common administrative area | limited impact | one strong factor and an authorization policy |
| Laboratory, restricted archive, or secondary data room | sensitive information or asset | MFA by profile, schedule, or area |
| Vault room, critical data center, or sensitive process | high operational or asset impact | mandatory MFA with governed exceptions |
| Area with segregation of duties | risk from individual action | MFA combined with dual custody |
| Temporary third-party access | temporary relationship | time-limited credential + second factor according to risk |
The matrix above is only a reasoning model. The design should relate each area to its risk and define the requirement in an access matrix. Merely stating that “the system shall support MFA” demonstrates product capability but does not determine where the function will be applied.
Common combinations and their engineering effects
Card + PIN
Card and PIN combine possession and knowledge. It is a mature architecture, but it requires a defined PIN policy covering lifecycle, use, recovery, and administrative protection.
The PIN must be individual. A shared PIN by department reduces accountability and makes selective revocation difficult. Logs must not record the PIN value; they should record only whether the factor was requested, accepted, or rejected.
At high-flow access points, entering a PIN increases transaction time. The design must measure this impact and ensure that operational pressure does not lead to weaker operating practices during peak periods.
Card + biometrics
The credential can indicate the identity and biometrics can verify that the person presenting the card is its holder. This enables an efficient 1:1 architecture because the system does not need to search the entire gallery.
Biometrics adds its own requirements: enrollment quality, FAR, FRR, failure to acquire, liveness/PAD when required, privacy, accessibility, and an equivalent alternative for people who cannot use the modality. The performance of the second factor must be tested with the actual user population.
Mobile credential + device authentication
A smartphone can protect the credential with local biometrics or a PIN. This increases resistance to use by another person, but the design must document where the second factor is actually validated. The access terminal may receive only a credential already released by the device without visibility into the local authentication performed on the phone.
This architecture may be appropriate, provided that the security model, evidence, and responsibility of each layer are understood. It should not be assumed that “phone with biometrics” automatically means MFA in the EACS.
PIN + biometrics
This combination joins knowledge and inherence without necessarily using a card. It is technically possible, but a typed identifier must be distinguished from a secret. If a person enters a public employee ID only to locate a template, that identifier should not be counted as a knowledge factor.
Card + PIN + biometrics
Three steps may be justified in highly critical areas, but operational cost rises quickly. More factors do not automatically mean greater security if the process becomes impractical, contingency controls are weak, or the team cannot sustain the policy.
Factor order and user experience
The sequence affects performance and diagnostics. With card + biometrics, presenting the card first allows the system to locate the correct template and perform 1:1 verification. With card + PIN, the credential can indicate which policy and which PIN should be validated. In other architectures, the factors are collected before any decision is made.
The terminal must provide clear feedback. The user should know whether the system expects a card, PIN, biometric sample, another attempt, or contact with the security desk. A generic “error” message increases repeated attempts and support calls.
It is also important to limit how much the feedback reveals. Telling an unauthorized user in detail which factor failed may expose unnecessary information. The design should balance usability and information exposure.
Capacity, latency, and queue formation
MFA adds time to each transaction. The actual impact cannot be estimated only from the processing time stated by the manufacturer.
The complete cycle may include:
- approaching the access point;
- presenting the first factor;
- terminal feedback;
- presenting the second factor;
- local or central processing;
- authorization;
- barrier command;
- opening;
- passage;
- rearming;
- repetition in case of failure.
At a turnstile, additional seconds multiplied by a peak entry period can create a significant queue. In industrial areas, this may affect shift changes. At reception areas, it may transfer operational pressure to the security desk.
The design should use service throughput, not only nominal time. It should consider latency percentiles, additional attempts, and users who need assistance.
Local, centralized, and hybrid architecture
MFA connects credentials, readers, controllers, servers, and, in enterprise environments, directories and IAM. Reviewing interfaces before deployment reduces incompatibilities and unintended weak points.
The MFA decision may occur in the controller, an intelligent terminal, the central server, or a combination of these layers.
Local decision
Sufficient rules and data remain close to the access point. The advantage is continuity during loss of communication. In return, local storage must be protected, changes must be synchronized, and revocation must be enforced across distributed devices.
Centralized decision
The server processes the logic. The policy can be richer and easier to administer, but the door becomes dependent on the network, server, identity services, and latency. Behavior during failure must be defined.
Hybrid architecture
Some rules remain local while others are coordinated centrally. This is common in distributed corporate systems. The design must explicitly list what continues to operate when each dependency fails.
Offline mode cannot be an unknown
One of the greatest weaknesses in MFA appears when the network goes down. If a door normally requires card + biometrics, what happens when the terminal loses access to the biometric server? If card + PIN depends on an external directory, which rule remains available locally?
The design must define contingency states:
- maintain two factors locally;
- deny access until service is restored;
- accept a degraded mode for specific groups;
- require supervisor authorization;
- use a controlled emergency credential.
Any relaxation must have an expiration period, an accountable owner, and a log. Otherwise, the “contingency mode” may become a permanently weaker configuration.
Factor failures and exception policy
Predictable failures must be addressed before deployment:
- lost or damaged card;
- forgotten or blocked PIN;
- unavailable biometric sensor;
- smartphone without battery power;
- failure to acquire;
- user unable to provide the biometric modality;
- outdated local database;
- identity server unavailable;
- isolated controller;
- clock or synchronization error.
The exception should preserve an equivalent level of security. If a critical area normally requires two factors, automatically reducing the requirement to a single card whenever a problem occurs turns failure into a path around the intended control.
MFA, dual custody, and duress are not the same thing
MFA validates multiple factors for the same identity. Dual custody requires two distinct identities. Duress is a function used to indicate that access is occurring under threat. These controls can coexist.
A highly critical room may require card + PIN from each person and also require two authorized people to be present. The logic must be defined as a state machine so that the integrator and the inspection team do not implement different interpretations.
Integration with anti-passback, schedules, and access levels
Correct authentication does not mean authorization. After validating the factors, the EACS may still deny access because of:
- schedule;
- calendar;
- area;
- profile;
- anti-passback;
- occupancy;
- lockdown;
- suspended credential;
- expired relationship;
- lack of temporary authorization.
The final decision must record the cause. This makes it possible to distinguish authentication problems from policy problems.
Integration with HR, directories, and IAM
In enterprise environments, the EACS may receive identity and attributes from corporate sources. HR may be the source of the employment relationship; a directory may provide identifiers; an IAM platform may orchestrate groups and lifecycle. Physical MFA then becomes part of a broader identity chain.
Changes in role, transfer between locations, leave, and termination must be reflected in physical permissions. Integration must define which system is the source of truth for each attribute, the propagation SLA, and how discrepancies are reconciled.
This automation reduces manual work but creates dependencies. An incorrect group mapping may grant access broadly; an integration failure may prevent revocations. Therefore, integrations need logs, monitoring, and negative testing.
Logs and evidence for a multifactor transaction
A useful log should allow the decision to be reconstructed without storing unnecessary secrets. Typical fields include:
- user identifier;
- access point;
- synchronized date and time;
- applied policy;
- requested factors;
- result of each step;
- online or offline condition;
- final authorization rule;
- use of an exception;
- origin of an administrative change.
PINs should not be stored in plain text. Biometric data requires additional protection because it is sensitive personal data under Brazil’s LGPD.
LGPD and biometrics as a second factor
When the second factor is biometric, the organization must govern purpose, legal basis, minimization, retention, administrative access, security, and deletion. It is not necessary to retain a raw image if the process can operate with an appropriately protected template and the image has no legitimate later purpose.
The architecture must also consider copies stored on terminals. Distributing a template to hundreds of devices expands the protection surface and makes revocation and disposal more complex.
MFA does not justify excessive collection. The question should be: which combination meets the risk with the lowest exposure compatible with the purpose?
Accessibility and an equivalent alternative
Keypads, biometric readers, and mobile terminals must be positioned and configured for the actual user population. Height, reach, contrast, feedback, laterality, and motor limitations can affect use.
The design should provide an alternative for people who cannot use a factor. This alternative must have an equivalent level of control and a governed process. Creating an “accessible door” that permanently operates under a weaker policy can introduce a structural workaround.
How to specify MFA by performance
A manufacturer-independent specification describes behavior, not a catalog. Instead of requiring a specific reader, it may establish:
- at least two independent factor categories wherever the risk matrix requires them;
- policy configurable by door, user, group, and schedule;
- defined authentication sequence;
- attempt limits and blocking;
- offline operation according to the continuity matrix;
- individualized logs for each step;
- integration with a directory or IAM where applicable;
- auditable contingency arrangements;
- latency and throughput requirements;
- protection of credentials and templates;
- revocation and synchronization capability;
- as-built documentation of the policy;
- acceptance test matrix.
This format preserves competition and keeps decisions on risk and performance within the engineering scope.
MFA matrix by area
| Area | Factor 1 | Factor 2 | Offline | Exception | Acceptance evidence |
| Administrative | card | not required | yes | security desk | reading and authorization |
| Data room | card | PIN | yes | supervisor | success, error, and blocking |
| Critical room | card | biometrics | restricted | formal process | matching, rule, and logs |
| Temporary access | temporary credential | according to risk | defined by design | security desk | validity and expiration |
| Dual-custody area | individual MFA | second identity | according to matrix | formal emergency procedure | complete state machine |
The matrix should be developed from the requirements program and risk analysis. It becomes the reference for configuration and commissioning.
FAT, SAT, and commissioning
MFA is only deployed when its logic has been tested. FAT verifies policy, integration, and states before field deployment. SAT verifies behavior in the actual environment. Commissioning closes the chain from factor presentation to physical command and event recording.
Positive cases
- two valid factors;
- authorized user at the correct time;
- offline operation according to the design;
- restoration and synchronization.
Negative cases
- valid first factor and invalid second factor;
- factors from different users;
- revoked credential;
- authenticated but unauthorized user;
- attempt limit exceeded;
- nonmatching biometrics;
- policy outside the permitted schedule.
Contingency cases
- network failure;
- server failure;
- reader failure;
- use of emergency credential;
- authorized exception;
- return to normal mode;
- event reconciliation.
Acceptance should not merely demonstrate that the door opened. It should demonstrate that it opened under the correct condition, denied under the correct condition, and generated the correct evidence.
Post-deployment indicators
Assisted operation can monitor:
- rejection rate by factor;
- average transaction time and transaction-time percentile;
- blocks caused by repeated attempts;
- exceptions and authorized workarounds;
- lost credentials;
- biometric reenrollment;
- synchronization failures;
- offline periods;
- differences between policy and configuration;
- support calls by access point.
An increase in exceptions may indicate that the policy has become impractical. An increase in biometric rejections may reveal sensor degradation, poor enrollment, or a change in the user population. Indicators turn MFA from a static configuration into a manageable operational control.
How to procure a design that includes multifactor authentication
Procurement should require verifiable deliverables. A mature scope may include:
- risk analysis by area;
- factor and rule matrix;
- architecture diagram;
- interface matrix;
- integration requirements;
- offline and contingency strategy;
- logging and cybersecurity requirements;
- capacity criteria;
- test cases;
- requirement–test–evidence matrix;
- as-built documentation;
- operation and exception procedures.
The expected result is not “install readers with PIN and biometrics,” but to demonstrate an authentication policy consistent with risk, operation, and continuity.
Common design errors
Requiring two factors at every door
This increases cost and friction without a proportional gain in low-risk areas.
Confusing an identifier with a factor
A typed employee ID may only locate the user record and may not constitute a secret.
Ignoring peak flow
A policy that is secure in the laboratory can create queues and operational workarounds during real operation.
Failing to define offline behavior
The system works while all infrastructure is available and becomes unpredictable at the first network failure.
Accepting exceptions without expiration
A temporary contingency becomes the new normal.
Treating biometrics as infallible
FAR, FRR, FTA, enrollment quality, and PAD must be considered.
Failing to separate authentication from authorization
Diagnostics and auditing become weak, and the system begins reporting everything as “access denied.”
Final considerations
Multifactor authentication in physical access control should be a selective, risk-driven decision demonstrated through testing. Its value does not lie in accumulating readers or steps, but in combining independent factors, maintaining continuity, preserving flow capacity, controlling exceptions, and producing auditable evidence.
When the risk matrix, architecture, offline policy, logs, and tests are defined before procurement, MFA stops being a catalog feature and becomes a measurable engineering requirement. This approach also avoids two extremes: underprotecting critical areas and overburdening common areas with controls that operations tend to circumvent.
Acceptance must prove that the access point opens for the correct combination, denies access under the expected conditions, and preserves evidence during contingency operation.
Technical references
[1] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-1:2013 — Alarm and electronic security systems — Part 11-1: Electronic access control systems — System and components requirements. 2013. Available at: https://webstore.iec.ch/en/publication/3662.
[2] INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 60839-11-2:2014 — Alarm and electronic security systems — Part 11-2: Electronic access control systems — Application guidelines. 2014. Available at: https://webstore.iec.ch/en/publication/3663.
[3] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management. 2025. Available at: https://csrc.nist.gov/pubs/sp/800/63/B/4/final.
[4] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. NIST SP 800-116 Rev. 1 — Guidelines for the Use of PIV Credentials in Facility Access. 2018. Available at: https://csrc.nist.gov/pubs/sp/800/116/r1/final.
[5] BRAZIL. Law No. 13,709 of August 14, 2018 — General Personal Data Protection Law (LGPD). 2018. Available at: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm.
Frequently asked questions
It is the requirement for two or more independent factors before passage is authorized, such as card + PIN or card + biometrics.
Not necessarily. If the employee ID only identifies the record and is not a secret, it is not an independent knowledge factor.
No. The combination should result from risk, capacity, continuity, privacy, and user-population analysis. Card + PIN may be more suitable in many scenarios.
Yes, if the architecture keeps sufficient rules and data locally. Offline behavior must be defined and tested in the design.
No. MFA combines factors for the same identity; dual custody requires two different people. Both controls can be used together.
Through positive, negative, and contingency cases that validate factors, authorization, offline mode, blocks, revocation, exceptions, and log evidence through to the physical command.
Additional technical materials
Related services
- Requirements Program and Engineering Requirements
- Design Review for Engineering Projects
- Equipment Commissioning: FAT, Installation, SAT, Startup, and Acceptance
Main content on the topic
Related technical content
- MFA and 2FA: Multifactor Authentication for Remote Access and OT Environments
- Mobile Credentials in Access Control: NFC vs. BLE, Security, and Design Criteria
- MIFARE and DESFire in Access Control: Security, Keys, and Migration
- Dual Custody in Access Control: Two-Person Rule, Dual Access, and Dual Occupancy
- FAR, FRR, and EER in Biometrics: Measuring Performance and Setting the Threshold
