IN ITI 38/2026 changed the prevention and detection requirement for injection attacks already established by IN ITI No. 36/2026 for videoconferencing and the electronic Registration Authority (RA) of ICP-Brasil. The new wording removed the expression "undetectably" from the requirement concerning the injection of pre-recorded or artificially generated video during applicant identification. The change has applied since publication on October 20, 2026.
For Certification Authorities (CAs) and Registration Authorities (RAs), the revision requires attention to evidence that the capture channel is protected, in addition to liveness detection. IN 38 also adjusted rules for digital documents, validation, and biometric quality.
What does IN ITI 38/2026 change in the anti-injection requirement?
The change applies to art. 37, §1, II of IN 36, concerning the CA's videoconferencing solution, and to art. 57, VIII, concerning the electronic RA application. The latter is the automated method for issuing certificates to individuals, without human intervention and exclusively through a mobile application, as provided in arts. 51 and 53.
Previously, the solution had to apply prevention and detection measures to ensure that neither the applicant nor an external attacker could inject pre-recorded or artificially generated video "undetectably." The current wording removes that expression and keeps prevention and detection measures as part of the requirement.
These provisions establish a prevention and detection requirement, but they do not specify a mandatory blocking point before the SDK. The CA must assess the effectiveness of the set of controls and validate the applicable legal interpretation for its process.
The obligation was already in force: IN 36 took effect on May 5, 2026, including art. 57, VIII for the electronic RA. For videoconferencing, art. 69 granted 90 days for the mechanisms in items II and III of §1 of art. 37; that period ended in early August. IN 38 did not create a new transition period and approved version 4.1 of DOC-ICP-05.03, on biometric identification in ICP-Brasil.
CAs and RAs, as entities within ICP-Brasil, are responsible for the security of the identification process and for the damage they cause, under art. 1, §2 of IN 36. This responsibility existed before IN 38 and reinforces the importance of assessing the controls implemented and the evidence provided by the capture vendor.
What is a biometric injection attack, and where does it enter?
A biometric injection attack is the insertion or replacement of data in the biometric flow, bypassing legitimate capture. In facial biometrics, one path is to replace the camera feed that reaches the SDK, the vendor's software development kit.
The difference from a presentation attack lies in where the data enters. In a presentation attack, the attacker places an artifact in front of the camera, such as a photo, an on-screen video, or a mask. In an injection attack, the attacker introduces the data directly into the flow. The content may be recorded, manipulated, or AI-generated: deepfake describes the media, while injection describes how it is inserted.
The Fortface technical guide to injection attacks in facial biometrics details three vectors in the capture channel:
- Virtual camera: provides a software feed through the application's camera interface, replacing capture with pre-recorded or real-time generated video.
- Capture-channel hook: intercepts calls or data and replaces the stream in transit while the camera appears to work normally to the application.
- Device emulation: simulates the execution environment and feeds the camera content prepared by the attacker.
These examples explain replacement at the capture input; injection can also occur at other points in processing. Protection therefore considers the signal's origin and the flow's integrity, in addition to image content.
Why does liveness alone not prove protection against injection?
Liveness detection assesses signs of liveness in the image, such as texture, movement, and depth, among other factors, depending on the technology. Anti-injection assesses risks associated with the origin of the data and the channel. Some PAD mechanisms may detect injected media, but an isolated presentation assessment does not prove protection of this channel.
IN 36 separates the requirements: art. 37, §1, I and art. 57, VII address liveness using PAD (Presentation Attack Detection); the following items address the prevention and detection of injection.
The evaluation scopes are also distinct. ISO/IEC 30107-3 establishes test methods and reporting of results for PAD. CEN/TS 18099:2024 guides the evaluation of injection attack detection. They are technical references for evaluations, not certification bodies.
Art. 37, §2 and art. 57, IX require periodic independent testing for PAD technologies. IN 36 does not expressly extend this obligation to injection or make CEN/TS 18099:2024 mandatory. A specific anti-injection report is useful evidence of effectiveness within the tested scope; compliance depends on the complete process. The requirements of IN 36 are not exhaustive, under art. 1, §1.
Which controls verify the capture channel?
Defense combines checks of the capture source, application integrity, and execution environment, with controls on the client, in communications, and on the server. RASP (Runtime Application Self-Protection) techniques help identify tampering during the session. Coverage depends on the platform and must keep pace with new attack methods.
Some of these controls are already required by IN 36:
- Videoconferencing: detection and blocking of virtual camera drivers, integrity detection, and blocking of compromised devices (art. 37, §1, III).
- Electronic RA: verification of application and environment integrity, with no evidence of administrative privilege unlocking; a hardware-attested unique device identity; and end-to-end encryption for communication with the CA's systems (art. 57, I to III).
Blocking mechanisms must be calibrated to avoid excessive friction or improper rejection of legitimate users, which can affect the experience. This calibration must preserve the blocks and integrity requirements imposed by the standard.
Which document and biometric rules changed with IN 38?
In addition to anti-injection, IN 38 introduced operational changes to identification:
- Physical or digital document: accepting digital documents and repealing art. 70 may reduce friction in remote issuance, enabling scale and a higher volume of transactions. In videoconferencing, the change allows applicants to send and present a physical or digital document; in the electronic RA, capture and validation are no longer restricted to physical documents (arts. 38, I and III; 57, V; and 58, II). The validations required by the standard remain in place.
- Embedded-technology validation: QR Code, MRZ, NFC, or a chip may be validated before or during videoconferencing, while maintaining comparison with the presented document (art. 38, §1). When no official validation mechanism exists, a second registration agent must verify issuance before the certificate's validity begins (art. 9, I-A).
- Driver's license query through Datavalid: art. 27 changes from "all issuances" to in-person, videoconferencing, and electronic RA modalities.
- Fingerprint quality: version 4.1 of DOC-ICP-05.03 lowers the minimum NFIQ 2.0 score from 70 to 40, measured after WSQ compression. The threshold changes, not the quality standard used.
What should the CA and RA request from the capture vendor?
As part of technical due diligence, request evidence separated by layer. This is a vendor-assessment recommendation, not a list of reports expressly required by IN 36:
Presentation: a PAD report under ISO/IEC 30107-3, including the laboratory, date, SDK version, scope, and results. Any levels should be associated with the laboratory's program.
Injection: a specific assessment, for example under CEN/TS 18099:2024, identifying the laboratory, level, platform, versions, and bypass result. The scope must distinguish attack instruments (IAI, Injection Attack Instrument, the biometric samples used) from insertion methods (IAM, Injection Attack Method).
This evidence can form part of the contractual acceptance criteria for the integration between the CA, its RAs, and the vendor. Some controls depend on who develops and operates the application, not only on the capture SDK. It is therefore advisable to define contractually the responsibilities for implementing, integrating, and operating controls for application and device integrity, hardware-attested device identity, and protection of communications with the CA's systems. For the electronic RA, it is essential to verify coverage of the mobile application required by the standard.
How does Fortface handle the anti-injection layer?
Fortface operates liveness detection and anti-injection as independent modules, each with its own evaluation.
For presentation attacks, iBeta assessed Fortface at Level 1 and Level 2 under the laboratory's program, according to ISO/IEC 30107-3, with an APCER (Attack Presentation Classification Error Rate) of 0% reported at both levels. The metric represents the proportion of attack presentations incorrectly classified as bona fide in the test.
For injection attacks, Antisec assessed the Web SDK under CEN/TS 18099:2024 between July 30 and August 18, 2026, with a result reported at the High level: 18 attacks executed, with no bypass observed. The test assessed injection detection and did not include biometric matching.
This report provides evidence for the anti-injection layer in Web integrations within the tested scope. The result must not be extrapolated to iOS or Android: for the electronic RA, the coverage of the controls in the CA's mobile application must be assessed.
“A well-made deepfake can fool the human eye and may fool liveness. What it cannot fool is channel verification. Anti-injection acts before the frames—and that is where a deepfake delivered through injection is blocked.” (Ricardo Fristche, CTO of Fortface by Payface)
