Liveness and Anti-Spoofing in Biometrics: PAD, Presentation Attacks, and Design Criteria

Understand liveness, anti-spoofing, and PAD in biometrics, metrics such as APCER/BPCER/IAPAR, and how to specify, test, and accept the capability in access control.

Check it out!

Liveness and anti-spoofing are mechanisms used to reduce the risk of a biometric system accepting an artificial, reproduced, or manipulated presentation as if it were a genuine characteristic of a person who is physically present. In standards terminology, the more precise concept is Presentation Attack Detection (PAD): detecting attacks performed at the capture device during presentation and acquisition of the biometric characteristic.

In access control, PAD does not replace FAR/FMR, FRR/FNMR, 1:1 verification, 1:N identification, multifactor authentication, authorization, or the physical barrier itself. It addresses a different threat. A matcher may distinguish genuine users from zero-effort impostors very effectively and still be vulnerable to a photograph, screen replay, mask, fingerprint replica, or another artifact presented to the sensor.

For that reason, specifying only “biometrics with liveness” is insufficient. A technically verifiable design needs to define the threat model, biometric modality, capture conditions, performance criteria, test evidence, failure behavior, and how compliance will be demonstrated in FAT, SAT, and commissioning. The objective is not to promise invulnerability, but to control a measurable risk without unduly degrading the experience of legitimate users.

Liveness, anti-spoofing, and PAD are not the same thing

“Liveness” is the most widespread commercial and operational term for indicating that a sample appears to come from a living person who is present. “Anti-spoofing” is a broader expression used for mechanisms intended to hinder or detect forgery. The ISO/IEC 30107 family uses Presentation Attack Detection because the standards problem is not limited to “proving life”: the focus is detecting presentations made to the capture device with the intent of interfering with operation of the biometric subsystem.

This distinction prevents an imprecise specification. An algorithm may look for eye movement, texture, depth, spectral response, tissue properties, or other cues, but the design should not procure a technological “trick.” It should procure verifiable performance against the presentation classes relevant to the risk.

Term	Typical use	Interpretation limitation
Liveness	Verify signals associated with live presence	May suggest a narrower scope than the actual risk
Anti-spoofing	Prevent or detect forgery	Broad term that does not by itself define a test and acceptance method
PAD	Detect presentation attacks at the capture point	Does not cover every threat to the biometric system

ISO/IEC 30107-1:2023 limits PAD to attacks that occur at the capture device during presentation and acquisition of the biometric characteristic. Data injection after the sensor, API compromise, template theft, database tampering, administrative credential compromise, or controller bypass belong to other attack surfaces. This means that even a product with robust PAD still depends on appropriate architecture, cybersecurity, and access policy.

The complete guide to access control systems places biometrics within the broader chain of identification, authentication, authorization, decision, and actuation. PAD is an additional layer in that chain, not a substitute for the others.

A presentation attack occurs at the capture point

A presentation attack occurs when an attacker presents a characteristic or artifact to the sensor with the objective of producing an improper response. In facial recognition, the threat class may include two-dimensional or three-dimensional presentations. In fingerprint recognition, it may include materials capable of reproducing patterns relevant to the sensor. Other modalities have their own attack surfaces.

The design requirement should not become a catalog of attack recipes. What matters is establishing, at an appropriate level of detail, which presentation families are plausible for the asset, how critical the access is, and what evidence will demonstrate compatible resistance.

The figure shows why PAD and matching should not be confused. A presentation may be genuine and not match the template; it may reproduce enough characteristics for the matcher but be classified as an attack by PAD; or it may pass both layers and still be denied by the authorization policy.

Low FAR does not demonstrate spoofing resistance

FMR/FAR and FNMR/FRR characterize comparison or biometric decision errors under defined conditions. A presentation attack is an adversarial problem: someone deliberately attempts to exploit the sensor and processing. A device with excellent FMR under artifact-free impostor attempts is not automatically protected against artificial presentations.

Engineering documents should therefore separate at least three requirement families: capture quality, matching performance, and PAD performance. Combining everything into a phrase such as “high-accuracy biometrics with anti-spoofing” makes acceptance subjective.

Passive and active PAD are architecture choices

Solutions described as passive PAD attempt to classify the presentation without requesting an additional perceptible action from the user. Active solutions may introduce a challenge, interaction, or capture sequence. Neither approach is universally superior. The choice affects throughput, accessibility, training, ergonomics, rejection rate, and the ability to operate in contingency scenarios.

The design should evaluate the technique as part of the system. At a low-throughput, high-criticality access point, an additional interaction may be acceptable. At an entrance with peak arrival periods, the same interaction may cause queues, operational pressure, and the creation of exceptions that weaken the control itself.

Threat model: what PAD really needs to detect

The starting point should not be “which biometric reader should we buy?” but which threat needs to be controlled and what consequence exists if the mechanism fails. The same technology may be sufficient for an administrative area and inadequate for a critical room, laboratory, data center, industrial environment, or zone with reinforced segregation.

A useful threat model considers asset value, attractiveness of the access point, user profile, possibility of obtaining biometric material, public exposure of characteristics, existing human supervision, presence of other credentials, and the consequence of an improper release.

The risk classification should then be converted into verifiable requirements in the access-control functional matrix: modality, authentication mode, PAD requirement, additional factors, attempt policy, failure behavior, event logging, and test criteria by point or point class.

A printed photograph is only the most obvious attack

Restricting the test to a single printed photograph can create a false sense of security. The evaluation needs to consider representative presentation classes compatible with the modality, capture technique, and threat scenario. ISO/IEC 30107-3:2023 structures testing and reporting principles precisely to prevent a one-off demonstration from being mistaken for broad performance characterization.

This also means the specification should avoid absolute phrases such as “immune to photos, videos, and masks.” Results depend on the presentation attack instrument, fabrication quality, environmental conditions, position, distance, sensor, algorithm, software version, and decision parameters. Engineering should procure evidence, not adjectives.

A deepfake may or may not be a presentation attack

Deepfake is not synonymous with presentation attack. If synthetic content is physically presented or displayed on a screen to the capture sensor, it may form part of an adversarial presentation. If it is injected directly into a digital flow after capture, the threat is no longer in the same PAD domain defined by ISO/IEC 30107.

The design consequence is important: requiring PAD while ignoring channel integrity, device authentication, API protection, and server hardening leaves open an attack surface that the biometric mechanism was not designed to address.

1:1 and 1:N change the consequence of a bypass

In 1:1 verification, the system compares the presented sample with a claimed or previously selected identity. In 1:N identification, it searches for a match among a candidate database. The two architectures change risk, processing time, aggregate match probability, and consequences of a bypass.

The dedicated content on 1:1 vs. 1:N biometrics explores this difference in greater depth. For PAD, the rule is simple: protection against presentation must be analyzed together with the comparison mode that follows it.

MFA reduces dependence on a single layer

When criticality requires greater robustness, biometrics can be combined with another factor, credential, or operational condition. Multifactor authentication does not make PAD unnecessary, but it reduces dependence on a single barrier. Likewise, strong PAD does not justify weakening authorization, anti-passback, dual custody, or physical segregation when those controls are part of the security concept.

A layered architecture is preferable to relying on a single proprietary “liveness” indicator. The residual risk of each layer should be understood and combined with the others.

PAD metrics: APCER, BPCER, IAPAR, and legitimate-user performance

PAD introduces its own error matrix. A system may be aggressive in rejecting attacks and at the same time reject legitimate people at an unacceptable frequency. It may also preserve an excellent user experience while allowing a class of adversarial presentation to pass under relevant conditions. The design needs to see both sides.

APCER and BPCER characterize classification errors

In PAD evaluations, APCER is associated with the proportion of attack presentations improperly classified as bona fide for the evaluated class, while BPCER characterizes bona fide presentations improperly classified as attacks. They should not be mixed with FMR/FNMR because they address a different decision stage.

Indicator	Engineering question	Risk when high
APCER	Does PAD allow attack presentations from the tested class to pass?	Bypass of the detection layer
BPCER	Does PAD reject genuine users as if they were attacks?	Queues, exceptions, support burden, and operational bypass
FMR/FNMR	How does the matcher behave in biometric comparison?	False match or rejection of a legitimate user
IAPAR	What is the acceptance rate of attack presentations in the evaluated authentication context?	Adversarial success under the adopted methodology

The technical value lies less in seeking a “magic number” and more in requiring methodology, population, conditions, presentation attack instruments, number of attempts, product version, configuration, and calculation method. Without this traceability, two percentages from different vendors may not be comparable.

NIST is a useful reference, not a universal physical-access limit

NIST SP 800-63B-4, published in July 2025, addresses digital identity authentication in U.S. government networked systems. In that context, it requires PAD for facial recognition, recommends PAD for fingerprint and iris recognition, and indicates, for implementation testing, demonstration of IAPAR below 0.07.

These requirements are valuable as a contemporary engineering reference and demonstrate the separation between biometric performance and resistance to presentation attacks. However, they should not automatically be copied as a legal requirement or universal threshold for a Brazilian physical system. Acceptance criteria for access control should arise from risk analysis, the application, the technology, and the project’s specific obligations.

Matching and PAD thresholds require governance

Some solutions allow matching sensitivity, PAD sensitivity, or both to be adjusted. Changing a threshold simply to “keep the turnstile moving” can reduce rejections while also changing risk. Critical parameters therefore need to be defined, documented, protected by administrative profiles, and subject to change management.

The commissioning Data Book should record the approved configuration, versions, relevant parameters, test evidence, and acceptance baseline. Without a baseline, a later change can degrade the system without the organization being able to demonstrate when or why performance changed.

Physical and operational design: sensor, lighting, flow, and accessibility

PAD performance does not exist independently of the environment. Camera, lens, effective resolution, illuminators, distance, angle, installation height, scene background, solar exposure, reflections, temperature, dirt, humidity, vibration, and user position can change capture and classification. In fingerprint recognition, skin condition, contaminants, and sensor characteristics also affect the experience.

The specification should therefore connect the security requirement to the physical design of the access point. It is not enough to approve a terminal on a bench and assume its behavior will be identical when installed near a glazed façade, outdoors, or in an industrial flow.

PAD must be compatible with expected throughput

Security that does not fit the operation tends to create exceptions. If every attempt requires repetition, repositioning, or guard intervention, peak-period queues may lead to doors being held open, authentication by third parties, shortcuts, or migration to a less secure mode.

The design should establish reference throughput, expected transaction time, retry rate, failure handling, and the procedure for users who cannot complete the flow. These criteria need to be tested with a representative population, not only with the technical team that installed the system.

Accessibility is part of the acceptance criterion

Equipment height, capture field, required approach, gestures, response time, and interface instructions can create barriers for certain users. A biometric design needs to provide operational alternatives and authentication methods compatible with the environment and applicable accessibility requirements.

The alternative should not become an ungoverned bypass. If a person cannot use the primary modality, the alternate flow must maintain identification, authorization, traceability, and a level of control consistent with the risk.

Lighting and geometry need to be tested on site

For facial recognition, lighting conditions can affect both matching and PAD. Backlighting, low illuminance, variable sunlight, or reflections can change characteristics extracted by the sensor. If PAD depends on multiple optical channels, the physical architecture and operating envelope must also be compatible.

SAT should reproduce foreseeable real situations: different times of day, users with varied characteristics, permitted accessories, approach distances, and flow conditions. The objective is not to “torture” the product with impossible scenarios, but to demonstrate that the system operates within the contracted operating envelope.

Enrollment, templates, LGPD, and cybersecurity

Enrollment and PAD solve different problems, but they meet at a critical point. If the identity or initial template is enrolled incorrectly, the rest of the lifecycle may operate exactly as designed and still protect a false identity or an improper association.

PAD during enrollment may be more critical than during later use

Enrollment should be governed with respect to identity, operator, authorized workstation, sample quality, duplicates, approval, and audit trail. When justified by the threat model, PAD mechanisms during enrollment help reduce the risk of registering an adversarial presentation as the legitimate reference.

Revocation and reenrollment also need to be defined. A biometric template is not a password whose physical characteristic can simply be changed; compromise and vendor changes require a lifecycle strategy.

Template protection remains essential

PAD operates before or during capture. After that, biometric representations are transmitted, processed, and may be stored. Encryption in transit and at rest, key segregation, administrative access control, hardening, logging, backup, retention, and disposal belong to another security layer and remain essential.

Where integrations with enterprise systems are present, the article on APIs, webhooks, and middleware in access control shows why service authentication, authorization, integrity, and event handling need to be designed beyond the biometric terminal.

LGPD requires governance proportional to the sensitive nature of the data

Biometric data linked to a natural person are sensitive personal data under Brazil’s LGPD. This increases the need for a defined purpose, applicable legal basis, necessity, security, access control, coherent retention, and processing governance. Brazil’s ANPD also highlights privacy, data-protection, and potential discriminatory risks associated with biometrics and facial recognition.

The decision to use biometrics should therefore not be made simply because equipment offers the feature. The function must be justified within access control, and collection and processing should be limited to what the use case requires.

Software- or AI-based PAD requires version management

A firmware, model, library, or backend update can change classification without changing visible hardware. The contract and maintenance plan need to define how version changes will be evaluated, when regression testing is required, and how to return to the previous configuration if performance deteriorates.

PAD events should also be differentiated from simple matching failures. This granularity improves investigation, makes trends visible, and prevents repeated adversarial attempts from being interpreted as merely “poor biometrics.” Integration with VMS can enrich the investigation but does not by itself improve the algorithmic PAD capability.

Offline operation and failures require explicit behavior

Some terminals perform matching and PAD locally; others depend on central services for part of the analysis. The design should clarify what happens when the network, server, license, or analysis service is unavailable. Continuing to grant access with degraded functionality may reduce security; blocking everything may compromise operational continuity or emergency routes.

This decision cannot remain hidden in the manufacturer’s default behavior. It should be specified by door class, aligned with the operating philosophy, and tested under contingency conditions.

How to specify and procure PAD without relying on commercial claims

A robust procurement process converts need into a verifiable requirement. “Has liveness” does not define what will be accepted, what evidence will be submitted, or how bidders will be compared. The specification should avoid both locking the design to a proprietary implementation and being so generic that any marketing statement is sufficient.

Engineering work begins by defining the object: a biometric system for a given set of points, with criticality classes, modalities, authentication policies, and integration. Functional and performance requirements follow, together with environmental conditions, prior evidence, supply testing, and acceptance criteria.

What to require in the technical specification

Where applicable, the documentation should establish:

• biometric modality and 1:1 or 1:N operating mode;
• points or point classes where PAD is required;
• threat model and presentation classes guiding the evaluation;
• requested metrics and the conditions under which they will be reported;
• laboratory evidence or test reports applicable to the offered version;
• minimum capture and installation conditions;
• capacity, latency, throughput, and retry handling;
• behavior during unavailability, PAD failure, and offline operation;
• logging, time synchronization, event export, and integration requirements;
• template-protection and communication-security requirements;
• FAT, SAT, regression testing, and acceptance documentation;
• update, maintenance, and change-management policy.

The list should be calibrated to risk. Not every access point requires the same level of evidence, but critical points should not depend on a checkbox that nobody can test.

Certification and laboratory reports need critical review

A declaration of conformity with ISO/IEC 30107-3 should not be interpreted as a generic certification of invulnerability. Scope, modality, product, version, configuration, attack classes evaluated, conditions, laboratory, metrics, and reported results need to be checked.

ISO/IEC 30107-3:2023 establishes principles and methods for evaluating and reporting PAD mechanisms; it does not standardize a specific algorithm or provide a general security evaluation of the system. This limitation is essential in procurement: a valid report may answer only one part of the engineering question.

Technical equalization should compare evidence, not terminology

Two vendors may call very different capabilities “advanced liveness.” Technical equalization needs to place requirements, evidence, gaps, conditions, and deviations side by side. Where data are missing, the result should be “not demonstrated” or “clarification required,” not approval by inference.

This reasoning connects with the technical requisition for Procurement: PAD requirements need to enter the purchasing process in a format that supports proposal comparison and maintains traceability through acceptance.

Recommended contracting scope

When contracting engineering support on this topic, the scope may include risk diagnosis, architecture definition, technical specification, functional matrix, review of vendor evidence, technical equalization, FAT, SAT, commissioning, and final documentation. Boundaries should be explicit: who provides test instruments and samples, who prepares the environment, who executes tests, who records evidence, and who has authority to accept deviations.

Deliverables may include a design-criteria memorandum, requirements matrix, technical specification, point matrix, test protocol, FAT/SAT report, punch list, configuration baseline, and Data Book. Measurement of the engineering service should be based on these products and milestones, not merely meeting attendance or hours without a verifiable result.

FAT, SAT, commissioning, and acceptance criteria

PAD stops being a promise only when it is tested in a traceable manner. The test plan should distinguish what can be validated in a controlled environment from what depends on the final installation. FAT and SAT have complementary roles.

FAT should demonstrate requirements before final mobilization

During FAT, the team can verify hardware and software versions, parameters, interfaces, logs, policies, expected presentation classes, bona fide-attempt behavior, and controlled failure scenarios. The protocol needs to clearly identify which results are objective and which observations require retesting on site.

The objective is not to reproduce every field risk in a laboratory, but to prevent basic problems from being discovered only after deployment. Evidence should identify the item tested, configuration, date, responsible parties, results, and nonconformities.

SAT validates the final environment

SAT brings in geometry, lighting, position, network, controller, lock or turnstile, integration, user database, flow, access policies, contingencies, and actual experience. A PAD mechanism that works on a bench may behave differently on site because of capture conditions.

The article on commissioning access control systems according to IEC 60839 details the testing, evidence, and acceptance discipline applied to the complete system.

Testing attacks without testing genuine users gives an incomplete view

A campaign focused only on blocking artificial presentations can hide high BPCER, repeated attempts, and operational degradation. The protocol should also measure legitimate-user success, transaction time, retries, and behavior across groups and conditions relevant to actual use.

If threshold adjustments are required, the change should be recorded and relevant tests repeated. Accepting the system after “tuning it until it works” without preserving the final configuration makes future audits impossible.

Acceptance criteria should be defined before testing

The vendor should not discover on the day of SAT what the acceptance threshold will be. The protocol should state requirements, sampling, conditions, number of attempts where applicable, tolerances, treatment of inconclusive results, nonconformity classification, and retest rules in advance.

It is also advisable to separate critical issues that prevent release from minor items that can be managed in a punch list with defined deadlines and responsibilities.

Assisted operation consolidates the baseline

After go-live, an assisted-operation period may reveal situations SAT did not capture: peak flow, seasonal lighting, accessories, behavior across user groups, intermittent unavailability, and exception procedures. The objective is not to reopen acceptance indefinitely, but to confirm stability and adjust parameters under governance.

Operation, maintenance, and change

PAD security can degrade without an obvious physical failure. Firmware changes, terminal repositioning, lighting changes, camera replacement, improper cleaning, a new screen film, algorithm changes, or configuration changes can alter performance. Maintenance therefore needs to preserve the function, not merely verify that the equipment powers on.

The maintenance plan for access control systems should include inspections and tests proportional to criticality, together with records of interventions and configuration changes.

Operational indicators help detect degradation

Repeated-attempt rates, bona fide rejections, PAD events, support calls, passage times, and manual exceptions can reveal degradation before it becomes a permanent bypass. Trends need to be analyzed by point, period, and version while preserving applicable data-processing restrictions.

An increase in rejections after a software update, for example, should trigger technical investigation. Likewise, a sudden drop in PAD events does not necessarily mean improvement: it may indicate the feature was disabled, logging failed, or a parameter changed.

Physical maintenance can change capture conditions

Repositioning a terminal, replacing a mount, changing height, or installing new lighting may seem like a simple intervention, but it can alter the capture envelope. Critical points should have reinspection criteria and, when necessary, biometric-function retesting after relevant changes.

Obsolescence should be addressed before support ends

PAD often depends on software, models, and libraries that evolve with threats and the manufacturer’s platform. The lifecycle plan needs to consider end of support, version compatibility, template migration, update availability, and a replacement strategy that preserves governance.

Design checklist for liveness and anti-spoofing

Before approving a biometric solution with PAD, the team should be able to answer the following questions in documented form.

1. What is the biometric modality and comparison mode, 1:1 or 1:N?
2. Which access points require PAD, and for what risk?
3. What threat model guides the presentation classes evaluated?
4. Is the offered feature measurable PAD or merely a commercial “liveness” label?
5. Which metrics are reported and under what test conditions?
6. Does the submitted evidence correspond to the offered product, version, and configuration?
7. How does the system balance rejection of attacks and rejection of bona fide users?
8. Which environmental and geometric conditions limit performance?
9. What throughput must be maintained, and how are retries handled?
10. Is there an accessible, governed flow for people who cannot use the primary modality?
11. How are enrollment, revocation, and reenrollment controlled?
12. How are templates and communications protected?
13. Which events are logged, and how are PAD, matching, and operational failures distinguished?
14. What happens during offline operation, server failure, or unavailability of the PAD feature?
15. Do FAT and SAT have predefined protocols and acceptance criteria?
16. Is the final configuration recorded in the Data Book?
17. Do version updates require analysis and regression testing?
18. Do maintenance and operations have indicators to detect degradation?
19. Does the contract define responsibilities, evidence, retests, and closure of punch-list items?
20. Is there an authentication alternative consistent with the risk for legitimate exceptions?

If several of these answers depend on “we will see during installation,” the risk has not yet been converted into an engineering requirement. The best time to correct that gap is before procurement and deployment.

Final considerations

Liveness and anti-spoofing should be treated as a Presentation Attack Detection problem, not a product checkbox. The objective is to reduce the probability that an artificial presentation is classified as bona fide without turning legitimate users into constant operational exceptions.

Engineering needs to define the threat, metrics, conditions, failure behavior, evidence, and acceptance criteria, then demonstrate those requirements through FAT, SAT, commissioning, and assisted operation. The ISO/IEC 30107 family provides the conceptual and testing framework for PAD, while references such as NIST SP 800-63B-4 show how presentation-attack metrics can be incorporated into contemporary authentication policies within their specific context.

Strong PAD is an important layer, but it still depends on appropriate matching, data protection, cybersecurity, authorization, the physical barrier, maintenance, and change management to form a robust and auditable access control system.

Technical references

[1] ISO. ISO/IEC 30107-1:2023 — Information technology — Biometric presentation attack detection — Part 1: Framework. Available at: https://www.iso.org/standard/83828.html.

[2] ISO. ISO/IEC 30107-3:2023 — Information technology — Biometric presentation attack detection — Part 3: Testing and reporting. Available at: https://www.iso.org/standard/79520.html.

[3] NIST. SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management. July 2025. Available at: https://csrc.nist.gov/pubs/sp/800/63/b/4/final.

[4] ANPD. Technology Radar No. 2 — Biometrics and Facial Recognition. Brasília, 2024. Available at: https://www.gov.br/anpd/pt-br/centrais-de-conteudo/documentos-tecnicos-orientativos/radar-tecnologico-biometria-anpd.pdf/@@display-file/file.

[5] SUPREMA. Access Control and Biometrics Course. Sections on false-presentation detection, multispectral methods, and biometric authentication. Technical material consulted in the A3A Engenharia internal knowledge base.

Frequently asked questions

What is the difference between liveness, anti-spoofing, and PAD?

Liveness commonly refers to mechanisms that look for signals associated with a living, present person. Anti-spoofing is a broad term for techniques against forgery. PAD, or Presentation Attack Detection, is the standards concept used by ISO/IEC 30107 to detect attacks presented to the capture device during biometric acquisition.

Does a low FAR or FMR mean the biometric system is resistant to spoofing?

No. FAR/FMR characterize biometric comparison or decision errors under defined conditions. Presentation attacks are adversarial attempts at the capture point and require a specific PAD evaluation.

Are APCER and BPCER the same metrics as FAR and FRR?

No. APCER and BPCER characterize PAD classification errors for attack and bona fide presentations. FAR/FMR and FRR/FNMR belong to biometric comparison or decision performance. The two layers should be specified separately.

Is PAD mandatory in every facial-recognition system?

There is no universal rule making PAD mandatory in every physical access control system. The need should be defined by risk, application, and applicable requirements. In the specific NIST SP 800-63B-4 context for digital identity authentication, PAD is required for facial recognition.

How should a vendor claiming liveness be evaluated?

Request evidence tied to the offered product, version, and configuration; verify methodology, presentation classes, metrics, test conditions, and report scope; then convert relevant requirements into traceable FAT, SAT, and acceptance criteria.

Should SAT test liveness and PAD in the real environment?

Yes, when PAD is part of the system requirement. SAT should verify behavior in the final installation, including lighting, geometry, flow, bona fide users, integrations, contingencies, and the presentation classes defined in the protocol.

Does Brazil’s LGPD prohibit the use of biometrics in access control?

Not generally. Biometric data linked to a natural person are sensitive personal data, and processing requires an appropriate legal basis, purpose, necessity, security, and governance consistent with the LGPD and the use case.

Complementary technical materials

Related services

• Access Control Design: architecture, devices, integration, and specification
• Engineering Design Review: technical review, interfaces, and design maturity
• Technical Procurement: specification, technical equalization, vendors, and procurement support
• Engineering Commissioning: planning, testing, readiness, and handover

Key content on this topic

• Access Control System: types, technologies, standards, and design
• ABNT NBR IEC 60839: requirements for access control systems
• Access-control functional matrix: how to specify each point
• Commissioning access control systems according to IEC 60839
• 1:1 vs. 1:N biometrics: verification, identification, and design criteria

Related technical content

• APIs, webhooks, and middleware in access control: integration, security, and architecture
• Access control system maintenance: plan, inspections, tests, and evidence
• Dual custody in access control: two-person rule, dual access, and dual occupancy
• Tailgating and anti-tailgating in access control: risks, detection, and design criteria