> For the complete documentation index, see [llms.txt](https://docs.facephi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.facephi.com/docs.facephi-en/products/suite-iad-injection-attack-detection/manual-producto-iad.md).
# IAD Product Manual
### 1. Overview
Facephi IAD (*Injection Attack Detection*) is the solution that protects facial biometric verification processes against attacks that inject fraudulent digital data into the capture flow, bypassing the device's physical camera. Unlike traditional presentation attacks (where an impostor shows a photo or mask to the camera), injection attacks operate **behind** the sensor, replacing or manipulating the stream before it reaches the biometric service.
IAD is designed to detect signals compatible with injection attacks, assessing whether the capture:
* Comes from a physical camera on the device and not from a virtual or intermediate source.
* Shows no signs of manipulation by intermediate software (hooking, virtual cameras, injected scripts).
* Shows no signs of an untrusted environment (emulator, rooted device, browser with malicious extensions).
* Contains no artifacts compatible with synthetic content, replay, or reproduced content.
### 2. Why IAD is necessary
The massive adoption of facial biometrics has pushed attackers to abandon physical attacks (increasingly detectable by Passive Liveness) and move toward digital techniques: virtual cameras that replay prerecorded videos, manipulation of the client application, or direct injection of payloads on the network. These techniques are stealthy because from the server's perspective "everything looks normal": a camera opened, a face was captured, a match was made.
Without a specific IAD layer, a biometric system well designed against presentation attacks remains vulnerable to this vector. IAD is the layer that closes that gap.
### 3. IAD and Passive Liveness — complementary layers
It is common to confuse IAD with liveness, but they answer different questions and both are needed:
| Question | Layer that answers | What it detects |
| ------------------------------------------------------ | -------------------------- | --------------------------------------------------------------------------------- |
| Is there a person in front of the camera? | **PAD / Passive Liveness** | Printed photos, masks, videos played on a screen in front of the camera, cutouts |
| Did the capture really come from this device's camera? | **IAD** | Virtual cameras, injected deepfakes, client manipulation, emulators, MITM, replay |
Passive Liveness (PAD) and IAD answer different, complementary questions. PAD evaluates whether there is a real, living person in front of the camera; IAD evaluates whether the capture arrived through a legitimate channel and was not injected or manipulated before reaching the service. They are different defense planes: PAD analyzes the image content, IAD analyzes the origin and integrity of the delivery channel (metadata, camera fingerprint, execution environment). That is why they are recommended together: they cover attack vectors that the other, by design, is not intended to address.
**Architecture recommendation**: enable IAD + Passive Liveness in all authentication and onboarding flows with medium security requirements or higher.
### 4. Types of attacks covered by IAD
Attacks against facial biometric verification operate on two complementary planes, which require different defense layers. In the presentation plane, detection aligns with the taxonomy of international standards such as ISO/IEC 30107-3 (Presentation Attack Detection). The injection plane corresponds to a more recent family of threats, whose international standardization is still under development, and which IAD addresses specifically.
| Plane | Family | Attack method | Layer that addresses it |
| ------------ | ---------------- | ----------------------------------------------------------------------------- | ----------------------------------- |
| Presentation | Physical content | Show the camera a printed photo, a screen reproduction, or a mask | Passive Liveness (PAD) |
| Injection | Virtual camera | Use a synthetic camera instead of the physical camera | IAD |
| Injection | External device | Use an external device to capture and transmit video as if it were the camera | IAD |
| Injection | Browser | Manipulate camera calls or code in web flows | IAD |
| Injection | Network | Manipulate or replace the payload in transit between client and server. | IAD + integration layer (section 8) |
**Detected by IAD analysis:**
* **Virtual cameras:** use of a synthetic camera instead of the device's physical camera.
* **External capture devices:** external device that captures and transmits video while presenting itself as a legitimate camera.
* **Browser attacks:** manipulation of camera calls or code in web flows.
The injected content can range from a stolen static image to real-time AI-generated deepfakes, including facial morphs, GAN-generated synthetic faces, and cheap fakes (3D renderings or manipulated images).
The following threats are partially detected by IAD, but are not solved by its analysis alone: they also require the session binding, secure transport, and retry policies practices described in section 8 (Integrator responsibilities).
* **Network attacks:** manipulation or sending of payloads in transit between client and server. Their effective mitigation depends on session signing and co-origin verification in the integrator's backend.
* **Man-in-the-Middle:** interception and replacement of the payload between client and server. It is mitigated with TLS and certificate pinning.
* **Replay attacks:** reuse of previously valid captures. Replay mitigation is an evolving capability; it is reinforced with tokenization, TTL, and per-session retry limits.
**Coverage considerations:**
* The effective coverage of each family depends on the platform and the security mode configured in the tenant.
* In the face of ambiguous signals, IAD prioritizes security: it may classify a presentation attack as injection. It is a conservative and intentional classification — blocking the attack takes precedence over labeling it accurately
### 5. Product architecture
IAD consists of two layers that operate in coordination:
#### 5.1. Client layer — Selphi IAD Component
Selphi IAD SDK for facial biometric capture that incorporates the new IAD component. Functionally equivalent in flow and integration, it adds extra anti-fraud controls during capture:
* Internal camera and permissions management with a preference for native hardware.
* Collection of capture metadata and execution environment signals.
* **Security Checks**: detection of untrusted environments without access to the user's personal information.
* **Passive image analysis**: evaluation of statistical, geometric, and temporal features of the image to identify patterns compatible with video playback, frame injection, artificial upscaling, or synthetic sources versus real captures from a physical sensor. The analysis is performed without reconstructing the image or extracting biometric information.
* Generation of a **IAD bundle**: encrypted package with images and metadata prepared for server-side validation.
Platforms supported today: **Android, iOS, Hybrid Plugins, Web**
Device requirements (Android; equivalent on iOS, validate with the Facephi team):
* Minimum 3 GB of RAM.
* Front camera with 1920×1080 preview or higher.
The result of the capture (`SelphiResult`) includes, in addition to the standard biometric fields (`templateRaw`, `template`, `bestImage`, `bestImageTokenized`, `livenessDiagnostic`), the field `iad` which contains the anti-fraud analysis information ready to be sent to the verification service.
#### 5.2. Server layer — IAD Service
Stateless REST microservice that receives the IAD bundle and returns a binary verdict:
* **Bona-fide capture (1):** the capture is legitimate.
* **Injection detected (0):** signals compatible with an injection attack have been identified.
The service can be deployed in two modes:
* **SaaS (recommended):** managed deployment by Facephi with continuous updates to the model and threat signatures. It is the preferred model because it ensures detection evolves at the pace of new threats without requiring customer intervention.
* **On-premise:** deployment on the customer's infrastructure for environments with specific regulatory or network-isolation requirements.
### 6. IAD API
The API surface exposed to the integrator depends on the deployment model. The two modes are functionally equivalent with respect to attack detection, but differ in the API contract.
#### 6.1. SaaS — Identity API
In SaaS deployment, IAD is invoked through the endpoint `POST /iad` of Identity API. The complete reference, error codes, and integration examples are published at:
`docs.facephi.com/api-rest/identity-api/identity-api-reference/security-compliance/injection-attack-detection`
Contract summary:
| Item | Value |
| -------------- | ----------------------------------------------------------------------------------- |
| Endpoint | `POST {IDENTITY_API_BASE_URL}/iad` |
| Authentication | Header `x-api-key` |
| Content-Type | `application/octet-stream` |
| Body | `IAD_BUNDLE` (binary) — encrypted package generated by the Selphi Anti-spoof Widget |
Response `200`:
```json
{ "attack": true}
```
Where `attack: true` indicates that an attack was detected and `attack: false` indicates a legitimate (bona-fide) capture.
The full list of codes is in the Identity API reference linked above.
**SaaS integration flow**
1. The client integrates the Selphi IAD SDK (Selphi IAD anti-spoof component) and captures the event `onExtractionFinished`.
2. From the extraction result, the property `encryptedLivenessRaw`, which contains the encrypted bundle.
3. The client application sends that bundle to the **integrator backend** (not directly to the IAD endpoint).
4. The integrator backend invokes `POST /iad` of Identity API with the API key and the bundle in the body.
5. The response `{"attack": true|false}` determines the flow decision.
Example:
{% code title="" overflow="wrap" expandable="true" %}
```
const onExtractionFinished = (extractionResult) => {
fetch(YOUR_BACKEND_URL, {
method: 'POST',
headers: { 'Content-Type': 'application/octet-stream' },
body: extractionResult.detail.encryptedLivenessRaw
})
.then(response => response.json())
.then(result => console.log('RESULT FROM SERVICE', result));
}
```
{% endcode %}
#### 6.2. On-premise — IAD Service
In on-premise deployment, the integrator directly operates the IAD Service microservice. The published endpoints are:
| Endpoint | Method | Purpose |
| --------------------------- | ------ | ------------------------------------------------------------------------------------------------ |
| `/api/v1/iad/check-capture` | POST | Verifies the IAD bundle and determines whether the capture is legitimate or has been injected |
| `/api/v1/iad/extract-image` | POST | Extracts the validated image from the payload (optional use, depending on the integrator's flow) |
| `/api/v1/iad/version` | GET | Returns service version and license status |
| `/api/v1/iad/health` | GET | Health check for monitoring |
> Delivery of the On-prem mode is subject to approval by a sales representative.
The complete request/response schema and the operational deployment guide are delivered together with the on-premise license.
**Example — check-capture (on-prem)**
Request:
{% code title="" overflow="wrap" expandable="true" %}
```
POST /api/v1/iad/check-capture
Content-Type: multipart/form-data
file=@iad_bundle.bin
```
{% endcode %}
Response (legitimate capture):
{% code title="" overflow="wrap" expandable="true" %}
```
{
"capture": {
"probability": 1,
"rejection": [],
"score": 1
},
"capture_type": "FACE"
}
```
{% endcode %}
#### 6.3. Comparative summary
| Aspect | SaaS (Identity API) | On-premise (IAD Service) |
| ----------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Main endpoint | `POST /iad` | `POST /api/v1/iad/check-capture` |
| Authentication | `x-api-key` header | Integrator-managed license |
| Content-Type | `application/octet-stream` | `multipart/form-data` |
| Response format | `{ "attack": bool }` | `{ "capture": { "probability", "rejection", "score" }, "capture_type" }` |
| Additional endpoints | Managed by Facephi | `/extract-image`, `/version`, `/health` |
| Model updates | Continuous, automatic | Via service versioning |
| Reference documentation | `docs.facephi.com/api-rest/identity-api/identity-api-reference/security-compliance/injection-attack-detection` | Delivered with the license |
### 7. Integration — recommended flow
{% code title="" overflow="wrap" expandable="true" %}
```
[Client app]
↓ uses
[Selphi IAD Component] Face Capture + Security Checks + IAD bundle
↓ returns SelphiResult { templateRaw, bestImageTokenized, iad, ... }
↓ or the onExtractionFinished event with encryptedLivenessRaw (Web)
[Integrator backend]
↓ POST with bundle
[IAD API] SaaS: POST /iad
On-prem: POST /api/v1/iad/check-capture
↓ returns verdict
[Integrator backend]
↓ if bona-fide, continue with:
[Passive Liveness service] Live person validation
[Matching / Templates service] Identity Verification
```
{% endcode %}
Key points of the flow:
1. Capture is always performed with Selphi IAD (not the standard component). This ensures the bundle is generated correctly.
2. The bundle is sent from the **integrator backend** to the IAD API, not directly from the client. This is by design: Facephi biometric services are B2B, stateless, and are invoked from the integrator's server side.
3. The decision to continue the flow if IAD detects injection is the integrator's, within the framework of the security mode configured in the tenant.
4. IAD and liveness are independent calls. We recommend invoking IAD first as a pre-filter.
### 8. Integrator responsibilities
Facephi biometric services are stateless microservices: they apply atomic integrity controls per payload (tokenization, TTL, signature validation) but **do not correlate assets with each other**. This has implications that the integrator must manage in its orchestration layer.
#### 8.1. Session binding and asset co-origin
It is the integrator's responsibility to ensure that the different assets of the same operation (facial capture, document capture, IAD bundle, liveness token, etc.) come from the same device and the same session. This is usually achieved by signing the payloads at capture time with a session key generated on the client, and verifying that signature in the integrator backend before invoking the biometric services.
Without this binding, an attacker could combine a legitimate IAD bundle from one person with a liveness token from another (an attack known as *stream decoupling*). This cross-check is not performed by any individual Facephi biometric service, nor can it be, because each microservice only sees the asset sent to it.
This shared responsibility **is not a product gap**: it is the standard practice of biometric integration in decoupled B2B architectures, equivalent to how any integrator signs and binds assets in distributed KYC flows.
#### 8.2. Retry policies
IAD applies controls per payload. If the integrator allows unlimited retries after a rejection, an attacker can use the feedback as an oracle to iteratively refine their payloads until finding one that passes the controls. We recommend:
* Limit the number of retries per session (typically 3–5).
* Apply progressive throttling between retries.
* Do not expose the detailed rejection reason to the client (a generic message is enough and reduces the oracle surface).
* Log and alert on anomalous retry patterns.
#### 8.3. Transport and storage
The IAD bundle travels encrypted from the client component. The integrator is responsible for:
* Use TLS in all communications with the IAD Service.
* Apply certificate pinning in the mobile client to prevent MITM on compromised devices.
### 9. Detection of untrusted environments (client layer)
Selphi IAD continuously evaluates the mobile device environment during capture and reports environmental risk signals. The threat categories monitored during capture include, among others:
* **Device and system integrity:** root, unlocked bootloader, unofficial ROM, SDK library integrity, class loader tampering.
* **Debugging and instrumentation:** developer mode, connected debugger, ADB active, hooking frameworks or dynamic instrumentation.
* **Emulation and virtualized environments:** execution in an emulator, network interfaces associated with virtualized environments, cloud emulators.
* **Sensor validation and physical interaction:** absence of expected physical sensors, inactivity of present sensors.
* **Application installation and usage context:** untrusted installation source, anomalous device profiles.
* **User security posture:** lack of screen lock, active accessibility services.
The detected signals are evaluated according to the security mode configured in the integrator's tenant and are added to the IAD bundle for consolidated backend analysis. The integrator does not need to manage these signals individually: the consolidated result arrives in the IAD Service response.
IAD provides detection of untrusted environments, but the specific signals that can be evaluated depend on the capabilities available on the platform and on the component used. Specific device detections, such as root, bootloader, ADB, or sensors, correspond to capabilities of the mobile environment itself.
> For security reasons, Facephi does not publish the exhaustive enumeration of specific checks applied by each control, since that information can be used by hostile actors to design evasion techniques.
### 10. Privacy and data
* The IAD Service is stateless. It does not persist captures or metadata beyond request processing.
* The SDK Security Checks evaluate the state of the device and the system **without accessing the user's personal information**.
* Passive image analysis is performed without reconstructing the image or extracting additional biometric information.
* The detection models are trained with internal-use datasets and do not store end-user data.
* In SaaS deployment, communications are encrypted in transit; license and encryption keys are managed according to Facephi standard practices.
* In on-premise deployment, the customer fully controls the infrastructure, network, and log storage.
### 11. Support and next steps
To obtain access, licenses, detailed technical specifications (full OpenAPI, performance metrics under NDA), or to discuss a specific use case, contact the Facephi sales representative.
The integration documentation for the client component (Android, iOS, Web) is available at `docs.facephi.com/productos/suite-iad-injection-attack-detection`.
\