Entienda liveness, anti-spoofing y PAD en biometría, métricas como APCER/BPCER/IAPAR y cómo especificar, probar y aceptar la función en control de acceso.
¡Descúbrelo!
Liveness y anti-spoofing son mecanismos utilizados para reducir el riesgo de que un sistema biométrico acepte una presentación artificial, reproducida o manipulada como si fuera una característica genuina de una persona presente. En terminología normativa, el concepto más preciso es Presentation Attack Detection (PAD): detección de ataques realizados en el dispositivo de captura durante la presentación y adquisición de la característica biométrica.
En control de acceso, PAD no sustituye FAR/FMR, FRR/FNMR, verificación 1:1, identificación 1:N, autenticación multifactor, autorización ni la propia barrera física. Actúa sobre una amenaza diferente. Un matcher puede distinguir muy bien a usuarios genuinos de impostores de intento cero y, aun así, ser vulnerable a una fotografía, reproducción en pantalla, máscara, réplica de huella dactilar u otro artefacto presentado al sensor.
Por ello, especificar únicamente “biometría con liveness” es insuficiente. Un diseño técnicamente verificable debe definir el modelo de amenazas, la modalidad biométrica, las condiciones de captura, los criterios de desempeño, las evidencias de ensayo, el comportamiento ante fallas y la forma de comprobación en FAT, SAT y puesta en servicio. El objetivo no es prometer invulnerabilidad, sino controlar un riesgo medible sin degradar indebidamente la experiencia de los usuarios legítimos.
Liveness, anti-spoofing y PAD no son lo mismo
“Liveness” es el término comercial y operativo más difundido para indicar que la muestra parece proceder de una persona viva y presente. “Anti-spoofing” es una expresión más amplia, usada para mecanismos destinados a dificultar o detectar falsificaciones. La familia ISO/IEC 30107 utiliza Presentation Attack Detection porque el problema normativo no se limita a “probar vida”: el foco está en detectar presentaciones realizadas al dispositivo de captura con intención de interferir en el funcionamiento del subsistema biométrico.
Esta distinción evita una especificación imprecisa. Un algoritmo puede buscar movimiento ocular, textura, profundidad, respuesta espectral, propiedades del tejido u otros indicios, pero el diseño no debe contratar el “truco” tecnológico. Debe contratar un desempeño verificable frente a las clases de presentación relevantes para el riesgo.
| Término | Uso típico | Limitación de interpretación |
| Liveness | Evaluar señales asociadas a una presencia viva | Puede sugerir un alcance más estrecho que el riesgo real |
| Anti-spoofing | Impedir o detectar falsificación | Término amplio que no define por sí solo el método de prueba y aceptación |
| PAD | Detectar presentation attacks en el punto de captura | No cubre todas las amenazas al sistema biométrico |
ISO/IEC 30107-1:2023 delimita PAD a los ataques que ocurren en el dispositivo de captura durante la presentación y adquisición de la característica biométrica. La inyección de datos después del sensor, el compromiso de API, el robo de templates, la alteración de bases de datos, la vulneración de credenciales administrativas o el bypass de la controladora pertenecen a otras superficies de ataque. Esto significa que un producto con PAD robusto sigue dependiendo de una arquitectura, ciberseguridad y política de acceso adecuadas.
La guía completa sobre sistemas de control de acceso sitúa la biometría dentro de la cadena más amplia de identificación, autenticación, autorización, decisión y actuación. PAD es una capa adicional en esa cadena, no un sustituto de las demás.
Presentation attack ocurre en el punto de captura
Una presentation attack ocurre cuando se presenta al sensor una característica o un artefacto con el objetivo de provocar una respuesta indebida. En reconocimiento facial, la clase de amenaza puede incluir presentaciones bidimensionales o tridimensionales. En huella dactilar, puede incluir materiales capaces de reproducir características relevantes para el sensor. Otras modalidades poseen sus propias superficies.
El requisito de diseño no debe convertirse en un catálogo de recetas de ataque. Lo que importa es establecer, con un nivel de detalle adecuado, qué familias de presentación son plausibles para ese activo, cuál es la criticidad del acceso y qué evidencias demostrarán una resistencia compatible.
La figura muestra por qué PAD y matching no deben confundirse. Una presentación puede ser bona fide y no corresponder al template; puede reproducir características suficientes para el matcher pero ser clasificada como ataque por PAD; o puede superar ambas capas y aun así ser denegada por la política de autorización.
Un FAR bajo no demuestra resistencia a presentation attacks
FMR/FAR y FNMR/FRR caracterizan errores de comparación o de decisión biométrica bajo condiciones definidas. Una presentation attack es un problema adversarial en el que alguien intenta deliberadamente explotar el proceso de captura. Un equipo con excelente FMR ante intentos de impostor de esfuerzo cero no está automáticamente protegido contra presentaciones artificiales.
Los documentos de ingeniería deben separar al menos tres familias de requisitos: calidad de captura, desempeño de matching y desempeño de PAD. Sumar todo en una frase como “biometría de alta precisión con anti-spoofing” vuelve subjetiva la aceptación.
PAD pasivo y activo son decisiones de arquitectura
Las soluciones denominadas PAD pasivo intentan clasificar la presentación sin solicitar al usuario una acción adicional perceptible. Las soluciones activas pueden introducir un desafío, interacción o secuencia de captura. Ningún enfoque es universalmente superior. La elección afecta al caudal, accesibilidad, formación, ergonomía, tasa de rechazo y capacidad de operar en contingencia.
La técnica debe evaluarse como parte del sistema. En un acceso de bajo caudal y alta criticidad, una interacción adicional puede ser aceptable. En una entrada con picos de flujo, la misma interacción puede generar filas, presión operativa y excepciones que debiliten el propio control.
Modelo de amenazas: qué debe detectar realmente el PAD
El punto de partida no debe ser “¿qué lector biométrico comprar?”, sino qué amenaza debe controlarse y cuál es la consecuencia si el mecanismo falla. La misma tecnología puede ser suficiente para un área administrativa e inadecuada para una sala crítica, laboratorio, data center, entorno industrial o zona con segregación reforzada.
Un modelo de amenazas útil considera el valor del activo, el atractivo del acceso, el perfil de los usuarios, la posibilidad de obtener material biométrico, la exposición pública de las características, la supervisión humana existente, la presencia de otras credenciales y la consecuencia de una liberación indebida.
La clasificación de riesgo debe convertirse después en requisitos verificables en la matriz funcional de control de acceso: modalidad, modo de autenticación, necesidad de PAD, factores adicionales, política de intentos, comportamiento ante fallas, registro de eventos y criterios de prueba por punto o clase de punto.
Una foto impresa es solo el ataque más evidente
Limitar el ensayo a una única fotografía impresa puede generar una falsa sensación de seguridad. La evaluación debe considerar clases representativas de presentación compatibles con la modalidad, la técnica de captura y el escenario de amenaza. ISO/IEC 30107-3:2023 estructura principios de prueba y reporte precisamente para evitar que una demostración puntual se confunda con una caracterización amplia del desempeño.
Esto también significa que la especificación debe evitar afirmaciones absolutas como “inmune a fotos, videos y máscaras”. El resultado depende del instrumento de presentación, la calidad de fabricación, las condiciones ambientales, la posición, la distancia, el sensor, el algoritmo, la versión de software y los parámetros de decisión. La ingeniería debe contratar evidencia, no adjetivos.
Un deepfake puede o no ser un presentation attack
Deepfake no es sinónimo de presentation attack. Si contenido sintético se presenta físicamente o en una pantalla al sensor de captura, puede formar parte de una presentación adversarial. Si se inyecta directamente en un flujo digital después de la captura, la amenaza ya no pertenece al mismo dominio de PAD definido por ISO/IEC 30107.
La consecuencia de diseño es importante: exigir PAD e ignorar integridad del canal, autenticación de dispositivos, protección de API y hardening del servidor deja abierta una superficie que el mecanismo biométrico no fue diseñado para resolver.
1:1 y 1:N cambian la consecuencia de un bypass
En la verificación 1:1, el sistema compara la muestra presentada con una identidad declarada o previamente seleccionada. En la identificación 1:N, busca una correspondencia en una base de candidatos. Las dos arquitecturas modifican el riesgo, el tiempo de procesamiento, la probabilidad agregada de correspondencia y las consecuencias de un bypass.
El contenido específico sobre biometría 1:1 frente a 1:N profundiza esta diferencia. Para PAD, la regla es simple: la protección contra presentaciones debe analizarse junto con el modo de comparación que viene después.
MFA reduce la dependencia de una sola capa
Cuando la criticidad exige mayor robustez, la biometría puede combinarse con otro factor, credencial o condición operativa. La autenticación multifactor no vuelve innecesario el PAD, pero reduce la dependencia de una única barrera. Del mismo modo, un PAD robusto no justifica debilitar autorización, anti-passback, doble custodia o segregación física cuando esos controles forman parte del concepto de seguridad.
Una arquitectura por capas es preferible a confiar en un único indicador propietario de “liveness”. El riesgo residual de cada capa debe comprenderse y combinarse con las demás.
Métricas de PAD: APCER, BPCER, IAPAR y desempeño del usuario legítimo
Las métricas de laboratorio solo son útiles cuando corresponden al producto, la versión, la configuración y las condiciones relevantes del proyecto. Una revisión técnica puede identificar brechas entre el desempeño declarado y lo que realmente se especifica para el diseño.
La validación independiente es especialmente útil antes de congelar requisitos, aprobar equivalencias o aceptar cambios de threshold.
PAD introduce su propia matriz de errores. Un sistema puede ser agresivo al rechazar ataques y, al mismo tiempo, rechazar personas legítimas con una frecuencia inaceptable. También puede preservar una excelente experiencia de usuario y permitir que una clase relevante de presentación adversarial pase. El diseño debe contemplar ambos lados.
APCER y BPCER caracterizan errores de clasificación
En evaluaciones de PAD, APCER se asocia con la proporción de presentaciones de ataque clasificadas indebidamente como bona fide para la clase evaluada, mientras que BPCER caracteriza presentaciones bona fide clasificadas indebidamente como ataques. No deben confundirse con FMR/FNMR, pues corresponden a una etapa de decisión distinta.
| Indicador | Pregunta de ingeniería | Riesgo cuando es alto |
| APCER | ¿El PAD deja pasar presentaciones de ataque de la clase ensayada? | Bypass de la capa de detección |
| BPCER | ¿El PAD rechaza usuarios genuinos como si fueran ataques? | Filas, excepciones, soporte y bypass operativo |
| FMR/FNMR | ¿Cómo se comporta el matcher en la comparación biométrica? | Falsa correspondencia o rechazo de usuario legítimo |
| IAPAR | ¿Cuál es la aceptación de presentaciones de ataque en el contexto de autenticación evaluado? | Éxito adversarial en el sistema bajo la metodología adoptada |
El valor técnico está menos en buscar un “número mágico” que en exigir metodología, población, condiciones, instrumentos de presentación, número de intentos, versión del producto, configuración y forma de cálculo. Sin esa trazabilidad, dos porcentajes de proveedores distintos pueden no ser comparables.
NIST es una referencia útil, no un límite universal para el acceso físico
NIST SP 800-63B-4, publicado en julio de 2025, trata la autenticación de identidades digitales en sistemas gubernamentales estadounidenses conectados en red. En ese contexto, exige PAD para reconocimiento facial, recomienda PAD para huella dactilar e iris e indica, para pruebas de implantación, la demostración de IAPAR inferior a 0,07.
Estos requisitos son valiosos como referencia contemporánea de ingeniería y demuestran la separación entre desempeño biométrico y resistencia a presentation attacks. Sin embargo, no deben copiarse automáticamente como requisito legal o umbral universal de un sistema físico brasileño. El criterio de aceptación debe derivarse del análisis de riesgo, la aplicación, la tecnología y las obligaciones específicas del proyecto.
Los thresholds de matching y PAD requieren gobernanza
Algunas soluciones permiten ajustar la sensibilidad de matching, PAD o ambos. Cambiar el threshold únicamente para “hacer que el torniquete avance” puede reducir rechazos y, al mismo tiempo, modificar el riesgo. Por ello, los parámetros críticos deben definirse, documentarse, protegerse mediante perfiles administrativos y someterse a gestión de cambios.
El Data Book de puesta en servicio debe registrar la configuración aprobada, versiones, parámetros relevantes, evidencia de pruebas y línea base de aceptación. Sin línea base, un cambio posterior puede degradar el sistema sin que la organización pueda demostrar cuándo o por qué cambió el desempeño.
Diseño físico y operativo: sensor, iluminación, flujo y accesibilidad
Cuando PAD se aplica en áreas críticas, el requisito debe surgir del modelo de amenazas, la matriz funcional y las condiciones reales de cada punto. Especificar únicamente “terminal con liveness” transfiere decisiones de seguridad al proveedor y vuelve subjetiva la aceptación.
Un diseño independiente transforma criticidad, modalidad biométrica, flujo, contingencia y criterios de prueba en requisitos verificables antes de la compra.
El desempeño de PAD no existe fuera del entorno. Cámara, lente, resolución efectiva, iluminadores, distancia, ángulo, altura de instalación, fondo de escena, exposición solar, reflejos, temperatura, suciedad, humedad, vibración y posición del usuario pueden alterar la captura y la clasificación. En huella dactilar, el estado de la piel, los contaminantes y las características del sensor también interfieren en la experiencia.
Por ello, la especificación debe vincular el requisito de seguridad con el diseño físico del punto de acceso. No basta aprobar un terminal en banco de pruebas y asumir que el comportamiento será idéntico instalado junto a una fachada acristalada, en exterior o dentro de un flujo industrial.
PAD debe ser compatible con el caudal esperado
La seguridad que no encaja en la operación tiende a generar excepciones. Si cada intento exige repetición, reposicionamiento o intervención de un vigilante, las filas en horas punta pueden llevar a puertas mantenidas abiertas, autenticaciones por terceros, creación de atajos o migración a un modo menos seguro.
El diseño debe establecer el caudal de referencia, tiempo de transacción esperado, tasa de reintento, tratamiento de fallas y procedimiento para usuarios que no consiguen completar el flujo. Estos criterios deben probarse con una población representativa, no solo con el equipo técnico que instaló el sistema.
La accesibilidad forma parte del criterio de aceptación
Altura del equipo, campo de captura, necesidad de aproximación, gestos, tiempo de reacción e instrucciones de interfaz pueden crear barreras para determinados usuarios. Un diseño biométrico debe prever alternativas operativas y formas de autenticación compatibles con el entorno y con los requisitos de accesibilidad aplicables.
La alternativa no debe convertirse en un bypass sin gobernanza. Si una persona no puede utilizar la modalidad principal, el flujo alternativo debe mantener identificación, autorización, trazabilidad y un nivel de control coherente con el riesgo.
Iluminación y geometría deben ensayarse en el sitio
Para reconocimiento facial, la condición luminosa puede afectar tanto matching como PAD. Contraluz, baja iluminancia, luz solar variable o reflejos pueden alterar características extraídas por el sensor. Si PAD depende de múltiples canales ópticos, la arquitectura física y la ventana de operación también deben ser compatibles.
El SAT debe reproducir situaciones reales previsibles: diferentes horarios, usuarios con características variadas, accesorios permitidos, distancias de aproximación y condiciones de flujo. El objetivo no es someter el producto a escenarios imposibles, sino demostrar que el sistema funciona dentro de la envolvente operativa contratada.
Enrollment, templates, LGPD y ciberseguridad
Enrollment y PAD resuelven problemas diferentes, pero se encuentran en un punto crítico. Si la identidad o el template inicial se registra de forma incorrecta, todo el resto del ciclo puede operar exactamente como fue diseñado y aun así proteger una identidad falsa o una asociación indebida.
PAD durante el enrollment puede ser más crítico que en el uso posterior
El registro debe tener gobernanza sobre identidad, operador, estación autorizada, calidad de la muestra, duplicidad, aprobación y pista de auditoría. Cuando el modelo de amenazas lo justifique, mecanismos de PAD durante el enrollment ayudan a reducir el riesgo de registrar una presentación adversarial como referencia legítima.
También deben definirse revocación y nuevo registro. Un template biométrico no es una contraseña cuya característica física pueda simplemente cambiarse; compromisos y cambios de proveedor exigen una estrategia de ciclo de vida.
La protección del template sigue siendo indispensable
PAD actúa antes o durante la captura. Después, las representaciones biométricas circulan, se procesan y pueden almacenarse. Cifrado en tránsito y reposo, segregación de claves, control de acceso administrativo, hardening, logging, backup, retención y eliminación pertenecen a otra capa de seguridad y siguen siendo indispensables.
Cuando existan integraciones con sistemas corporativos, el artículo sobre API, webhooks y middleware en control de acceso muestra por qué autenticación de servicio, autorización, integridad y tratamiento de eventos deben diseñarse más allá del terminal biométrico.
LGPD exige gobernanza proporcional al carácter sensible del dato
Los datos biométricos vinculados a una persona natural son datos personales sensibles en el contexto de la LGPD brasileña. Esto aumenta la necesidad de finalidad definida, base jurídica aplicable, necesidad, seguridad, control de acceso, retención coherente y gobernanza del tratamiento. La ANPD también destaca riesgos de privacidad, protección de datos y posibles impactos discriminatorios asociados a biometría y reconocimiento facial.
La decisión de usar biometría, por tanto, no debe tomarse únicamente porque el equipo ofrece la función. Es necesario justificarla dentro del control de acceso y limitar la recopilación y el tratamiento a lo que exige el caso de uso.
PAD basado en software o IA exige gestión de versiones
Una actualización de firmware, modelo, biblioteca o backend puede alterar la clasificación sin cambiar el hardware visible. El contrato y el plan de mantenimiento deben definir cómo se evaluarán los cambios de versión, cuándo requieren pruebas de regresión y cómo volver a la configuración anterior si el desempeño se deteriora.
Los eventos de PAD también deben diferenciarse de simples fallas de matching. Esta granularidad mejora la investigación, permite identificar tendencias y evita interpretar intentos adversariales repetidos como mera “biometría deficiente”. La integración con VMS puede enriquecer la investigación, pero no mejora por sí sola la capacidad algorítmica de PAD.
La operación offline y las fallas requieren un comportamiento explícito
Algunos terminales ejecutan matching y PAD localmente; otros dependen de servicios centrales para parte del análisis. El diseño debe aclarar qué ocurre cuando red, servidor, licencia o servicio de análisis quedan indisponibles. Seguir autorizando con funcionalidad degradada puede reducir la seguridad; bloquear todo puede comprometer la continuidad operativa o las rutas de emergencia.
Esta decisión no puede quedar oculta en el comportamiento por defecto del fabricante. Debe especificarse por clase de puerta, alinearse con la filosofía de operación y probarse en contingencia.
Cómo especificar y contratar PAD sin depender de promesas comerciales
En procurement, nombres comerciales como “AI liveness”, “3D anti-spoofing” o “detección avanzada” no son comparables por sí solos. La evaluación técnica debe confrontar requisitos, informes, versiones, condiciones de prueba, desviaciones y criterios de aceptación.
El apoyo técnico a la contratación mantiene la trazabilidad entre especificación, propuesta, aclaraciones, suministro y pruebas.
Una contratación robusta transforma una necesidad en un requisito verificable. “Tener liveness” no define qué será aceptado, qué evidencias se presentarán ni cómo se compararán los oferentes. La especificación debe evitar tanto el direccionamiento hacia una implementación propietaria como una generalidad que vuelva suficiente cualquier afirmación comercial.
La ingeniería comienza por definir el objeto: sistema biométrico para un conjunto determinado de puntos, con clases de criticidad, modalidades, políticas de autenticación e integración. Después vienen los requisitos funcionales y de desempeño, las condiciones ambientales, las evidencias previas, las pruebas de suministro y los criterios de aceptación.
Qué exigir en la especificación técnica
Cuando corresponda, la documentación debe establecer:
- modalidad biométrica y modo de operación 1:1 o 1:N;
- puntos o clases de puntos en los que se requiere PAD;
- modelo de amenazas y clases de presentación que orientan la evaluación;
- métricas solicitadas y condiciones en las que se reportarán;
- evidencias de laboratorio o informes de prueba aplicables a la versión ofertada;
- condiciones mínimas de captura e instalación;
- capacidad, latencia, caudal y tratamiento de reintentos;
- comportamiento ante indisponibilidad, falla de PAD y operación offline;
- requisitos de logs, sincronización de tiempo, exportación de eventos e integración;
- requisitos de protección de templates y seguridad de las comunicaciones;
- FAT, SAT, pruebas de regresión y documentación de aceptación;
- política de actualización, mantenimiento y gestión de cambios.
La lista debe calibrarse según el riesgo. No todo acceso exige el mismo nivel de evidencia, pero los puntos críticos no deberían depender de un checkbox que nadie puede probar.
Certificación e informe de laboratorio deben leerse críticamente
Una declaración de conformidad con ISO/IEC 30107-3 no debe interpretarse como certificación genérica de invulnerabilidad. Es necesario verificar alcance, modalidad, producto, versión, configuración, clases evaluadas, condiciones, laboratorio, métricas y resultados reportados.
ISO/IEC 30107-3:2023 establece principios y métodos para evaluar y reportar mecanismos de PAD; no estandariza un algoritmo específico ni realiza una evaluación general de seguridad del sistema. Esta delimitación es esencial en procurement: un informe válido puede responder solo una parte de la pregunta de ingeniería.
La evaluación técnica debe comparar evidencia, no nomenclatura
Dos proveedores pueden llamar “liveness avanzado” a capacidades muy diferentes. La evaluación debe colocar lado a lado requisitos, evidencias, brechas, condiciones y desviaciones. Cuando falten datos, el resultado debe ser “no demostrado” o “requiere aclaración”, no una aprobación por inferencia.
Este razonamiento se conecta con la requisición técnica para procurement: los requisitos de PAD deben llegar al proceso de compra en un formato que permita comparar propuestas y mantener la trazabilidad hasta la aceptación.
Alcance de contratación recomendado
El apoyo de ingeniería en este tema puede abarcar diagnóstico de riesgo, definición de arquitectura, especificación técnica, matriz funcional, revisión de evidencias del proveedor, evaluación técnica, FAT, SAT, puesta en servicio y documentación final. Las fronteras deben ser explícitas: quién suministra instrumentos y muestras de ensayo, quién prepara el entorno, quién ejecuta las pruebas, quién registra evidencias y quién tiene autoridad para aceptar desviaciones.
Los entregables pueden incluir memoria de criterios, matriz de requisitos, especificación técnica, matriz de puntos, protocolo de pruebas, informe FAT/SAT, lista de pendientes, línea base de configuración y Data Book. La medición del servicio debe apoyarse en estos productos y hitos, no solo en presencia en reuniones o número de horas sin resultado verificable.
FAT, SAT, puesta en servicio y criterios de aceptación
PAD solo se demuestra en el sistema implantado cuando FAT, SAT y pruebas de campo verifican simultáneamente el rechazo de las clases de presentación previstas, el comportamiento de usuarios bona fide, integraciones y contingencias.
La puesta en servicio organiza protocolos, evidencias, no conformidades, reensayos y línea base de configuración para que la aceptación sea técnica y trazable.
PAD deja de ser una promesa solo cuando se prueba de manera trazable. El plan de pruebas debe distinguir lo que puede validarse en un entorno controlado de aquello que depende de la instalación definitiva. FAT y SAT cumplen funciones complementarias.
FAT debe demostrar los requisitos antes de la movilización definitiva
En FAT, el equipo puede verificar versiones de hardware y software, parámetros, interfaces, logs, políticas, clases de presentación previstas, comportamiento ante intentos bona fide y escenarios de falla controlados. El protocolo debe identificar claramente qué resultados son objetivos y qué observaciones requieren reensayo en el sitio.
El objetivo no es reproducir todos los riesgos de campo dentro de un laboratorio, sino evitar que problemas básicos aparezcan solo después de la implantación. Las evidencias deben incluir identificación del ítem probado, configuración, fecha, responsables, resultados y no conformidades.
SAT valida el entorno definitivo
En SAT entran geometría, iluminación, posición, red, controladora, cerradura o torniquete, integración, base de usuarios, flujo, políticas de acceso, contingencias y experiencia real. Un PAD que funciona en banco puede comportarse de forma diferente en el sitio por las condiciones de captura.
El artículo sobre puesta en servicio de sistemas de control de acceso conforme IEC 60839 detalla la disciplina de pruebas, evidencias y aceptación aplicada al sistema completo.
Probar ataques sin probar usuarios legítimos produce una visión incompleta
Una campaña centrada solo en bloquear presentaciones artificiales puede ocultar un BPCER elevado, repetición de intentos y degradación de la operación. El protocolo debe medir también el éxito de usuarios legítimos, tiempo de transacción, reintentos y comportamiento en grupos y condiciones relevantes para el uso.
Si se requieren ajustes de threshold, el cambio debe registrarse y repetirse las pruebas pertinentes. Aceptar el sistema después de “ajustarlo hasta que funcione” sin conservar la configuración final impide una auditoría futura.
Los criterios de aceptación deben definirse antes de la prueba
El proveedor no debería descubrir el día del SAT cuál será el umbral de aceptación. El protocolo debe definir previamente requisitos, muestreo, condiciones, número de intentos cuando corresponda, tolerancias, tratamiento de resultados inconclusos, clasificación de no conformidades y reglas de reensayo.
También es recomendable separar pendientes críticos que impiden la liberación de ítems menores que pueden tratarse en una punch list con plazo y responsabilidad definidos.
La operación asistida consolida la línea base
Después de la entrada en operación, un período asistido puede revelar situaciones no capturadas por SAT: picos de flujo, iluminación estacional, accesorios, comportamiento de grupos de usuarios, indisponibilidades intermitentes y procedimientos de excepción. El objetivo no es reabrir indefinidamente la aceptación, sino confirmar la estabilidad y ajustar parámetros bajo gobernanza.
Operación, mantenimiento y cambios
La seguridad de PAD puede degradarse sin una falla física evidente. Cambios de firmware, reposicionamiento del terminal, modificación de iluminación, sustitución de cámara, limpieza inadecuada, nueva película, cambio de algoritmo o configuración pueden alterar el desempeño. Por ello, el mantenimiento debe preservar la función, no limitarse a verificar si el equipo enciende.
El plan de mantenimiento de sistemas de control de acceso debe incluir inspecciones y pruebas proporcionales a la criticidad, además del registro de intervenciones y cambios de configuración.
Los indicadores operativos ayudan a detectar degradación
Tasa de intentos repetidos, rechazos bona fide, eventos de PAD, solicitudes de soporte, tiempos de paso y excepciones manuales pueden revelar degradación antes de que se transforme en un bypass permanente. Las tendencias deben analizarse por punto, período y versión, respetando las restricciones aplicables al tratamiento de datos.
Un aumento de rechazos después de una actualización de software, por ejemplo, debe activar una investigación técnica. Del mismo modo, una caída súbita de eventos de PAD no significa necesariamente mejora: puede indicar recurso desactivado, falla de logging o cambio de parámetro.
El mantenimiento físico puede alterar la captura
Reposicionar un terminal, cambiar un soporte, modificar la altura o instalar nueva iluminación parece una intervención simple, pero puede cambiar la envolvente de captura. Los puntos críticos deben tener criterios de reinspección y, cuando sea necesario, reensayo de funciones biométricas después de cambios relevantes.
La obsolescencia debe tratarse antes del fin de soporte
PAD depende con frecuencia de software, modelos y bibliotecas que evolucionan con las amenazas y con la plataforma del fabricante. La planificación del ciclo de vida debe considerar fin de soporte, compatibilidad de versiones, migración de templates, disponibilidad de actualizaciones y estrategia de sustitución sin pérdida de gobernanza.
Checklist de diseño para liveness y anti-spoofing
Antes de aprobar una solución biométrica con PAD, el equipo debe poder responder de forma documentada a las siguientes preguntas.
- ¿Cuál es la modalidad biométrica y el modo de comparación, 1:1 o 1:N?
- ¿Qué puntos de acceso requieren PAD y por qué riesgo?
- ¿Qué modelo de amenazas orienta las clases de presentación evaluadas?
- ¿La función ofertada es PAD medible o solo una denominación comercial de “liveness”?
- ¿Qué métricas se reportan y en qué condiciones de prueba?
- ¿La evidencia presentada corresponde al producto, versión y configuración ofertados?
- ¿Cómo equilibra el sistema el rechazo de ataques y el rechazo de usuarios bona fide?
- ¿Qué condiciones ambientales y geométricas limitan el desempeño?
- ¿Qué caudal debe mantenerse y cómo se tratan los reintentos?
- ¿Existe un flujo accesible y gobernado para quien no puede usar la modalidad principal?
- ¿Cómo se controlan enrollment, revocación y nuevo registro?
- ¿Cómo se protegen templates y comunicaciones?
- ¿Qué eventos se registran y cómo se diferencian PAD, matching y fallas operativas?
- ¿Qué ocurre en operación offline, falla del servidor o indisponibilidad de la función PAD?
- ¿FAT y SAT tienen protocolos y criterios de aceptación previamente definidos?
- ¿La configuración final queda registrada en el Data Book?
- ¿Las actualizaciones de versión exigen análisis y pruebas de regresión?
- ¿Mantenimiento y operación tienen indicadores para detectar degradación?
- ¿El contrato define responsabilidades, evidencias, reensayos y cierre de pendientes?
- ¿Existe una alternativa de autenticación compatible con el riesgo para excepciones legítimas?
Si varias de estas respuestas dependen de “lo veremos durante la instalación”, el riesgo todavía no se ha transformado en requisito de ingeniería. El mejor momento para cerrar esa brecha es antes de la contratación y la implantación.
Consideraciones finales
Liveness y anti-spoofing deben tratarse como un problema de Presentation Attack Detection, y no como un checkbox de producto. El objetivo es reducir el riesgo de que una presentación artificial sea tratada como bona fide sin convertir a los usuarios legítimos en una excepción operativa constante.
La ingeniería debe definir el modelo de amenazas, las métricas, las condiciones operativas, el comportamiento ante fallas, las evidencias y los criterios de aceptación, y después verificar esos requisitos mediante FAT, SAT, puesta en servicio y operación asistida. La familia ISO/IEC 30107 proporciona el marco conceptual y de pruebas para PAD, mientras que referencias como NIST SP 800-63B-4 muestran cómo las métricas de presentation attack pueden incorporarse a políticas de autenticación dentro de su contexto específico.
Un PAD robusto es una capa importante, pero sigue dependiendo de matching adecuado, protección de datos, ciberseguridad, autorización, barrera física, mantenimiento y gestión de cambios para formar un sistema de control de acceso robusto y auditable.
Referencias técnicas
[1] ISO. ISO/IEC 30107-1:2023 — Information technology — Biometric presentation attack detection — Part 1: Framework. Disponible en: 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. Disponible en: https://www.iso.org/standard/79520.html.
[3] NIST. SP 800-63B-4 — Digital Identity Guidelines: Authentication and Authenticator Management. July 2025. Disponible en: https://csrc.nist.gov/pubs/sp/800/63/b/4/final.
[4] ANPD. Radar Tecnológico nº 2 — Biometría y Reconocimiento Facial. Brasília, 2024. Disponible en: https://www.gov.br/anpd/pt-br/centrais-de-conteudo/documentos-tecnicos-orientativos/radar-tecnologico-biometria-anpd.pdf/@@display-file/file.
[5] SUPREMA. Curso de Control de Acceso y Biometría. Secciones sobre detección de presentaciones falsas, multiespectro y autenticación biométrica. Material técnico consultado en la base interna de A3A Engenharia.
Preguntas frecuentes
Liveness suele referirse a mecanismos que evalúan señales asociadas a una persona viva y presente. Anti-spoofing es un término más amplio para medidas contra falsificación. PAD es el concepto normativo utilizado por ISO/IEC 30107 para detectar ataques de presentación durante la captura biométrica.
No. FAR/FMR describen el desempeño de comparación biométrica bajo condiciones definidas. El desempeño de PAD es una capa diferente y requiere evidencia y evaluación propias.
No. APCER y BPCER caracterizan errores de clasificación de PAD, mientras que FAR/FMR y FRR/FNMR caracterizan el desempeño de comparación o decisión biométrica. Las dos capas deben especificarse por separado.
No existe una regla universal para toda aplicación de control de acceso físico. El requisito debe derivarse del riesgo, del caso de uso y de las normas u obligaciones aplicables.
Revise evidencias vinculadas al producto, versión y configuración ofertados, incluyendo metodología, alcance, métricas, condiciones de prueba y criterios de aceptación.
Sí, cuando PAD forme parte del requisito. El SAT debe verificar la función bajo las condiciones contratadas de instalación y operación, junto con integraciones y comportamiento en contingencia.
No. Los datos biométricos vinculados a una persona natural son datos personales sensibles, por lo que su tratamiento requiere base jurídica adecuada, finalidad, necesidad, seguridad y gobernanza coherentes con la LGPD y el caso de uso.
Materiales técnicos complementarios
Servicios relacionados
- Diseño de Control de Acceso: arquitectura, dispositivos, integración y especificación
- Design Review de Proyectos de Ingeniería: revisión técnica, interfaces y madurez del diseño
- Procurement Técnico: especificación, evaluación, proveedores y apoyo a la contratación
- Puesta en Servicio de Ingeniería: planificación, pruebas, readiness y handover
Contenidos principales sobre el tema
- Sistemas de Control de Acceso: tipos, tecnologías, normas y diseño
- ABNT NBR IEC 60839: requisitos para sistemas de control de acceso
- Matriz funcional de control de acceso: cómo especificar cada punto
- Puesta en servicio de sistemas de control de acceso conforme IEC 60839
- Biometría 1:1 frente a 1:N: verificación, identificación y criterios de diseño
Contenidos técnicos relacionados
- API, webhooks y middleware en control de acceso: integración, seguridad y arquitectura
- Mantenimiento de sistemas de control de acceso: plan, inspecciones, pruebas y evidencias
- Doble custodia en control de acceso: regla de dos personas, dual access y dual occupancy
- Tailgating y anti-tailgating en control de acceso: riesgos, detección y criterios de diseño
