Device Attestation Nodes
Beyond the network and session signals in the risk snapshot, a KYC flow can place explicit device-integrity nodes in its onboarding graph. These consume attestation and capability evidence that Identity verified, and — unlike the fail-open risk summary — they are gates: they can hold or fail a step. This page covers the three integrity nodes and draws the line between them and the KYC risk-scoring node.
These nodes are fail-closed by design. Where the identity riskSummary is best-effort enrichment, a device-integrity gate that cannot establish trust stops the step rather than waving it through. Their strictness is deliberate — they guard against a compromised or spoofed client at onboarding.
device_attestation
The device_attestation node consumes a hardware attestation verdict — App Attest (iOS), Play Integrity (Android) or DeviceCheck — that Identity has already verified server-side. The node does not trust a claim sent by the client; it reads the verdict Identity pinned at SDK initialisation and branches on it, fail-closed:
| Verdict | Node outcome |
|---|---|
ALLOW | Attestation passed — the flow continues |
REVIEW | Ambiguous — routed to manual review |
BLOCK | Attestation failed — step fails with DEVICE_INTEGRITY_FAILED |
UNKNOWN | No usable verdict — treated as failure, DEVICE_INTEGRITY_FAILED |
Both BLOCK and UNKNOWN fail the step. The node does not fall through to "continue" when it lacks a verdict — a missing or unrecognised attestation is treated as a failure, not a pass. This is the fail-closed contract.
The verdict is pinned at SDK init
When the mobile SDK initialises, Identity verifies the platform attestation and pins the resulting verdict to the session server-side. The client cannot later assert its own integrity — the pinned verdict is authoritative.
The node reads the pinned verdict
When the flow reaches device_attestation, it reads that server-side verdict, never a value supplied in the client request.
The node branches fail-closed
ALLOW continues, REVIEW goes to manual review, BLOCK/UNKNOWN fail with DEVICE_INTEGRITY_FAILED.
When the gate is off
Attestation is configurable. If the gate is disabled for the flow (attestation.enabled is false), the node is inert: it does not verify or fail, and reports ATTESTATION_DISABLED as it passes through. This is how a flow that has not yet enrolled platform attestation runs without hard-failing every session.
ATTESTATION_DISABLED is not a failure code — it means the gate was intentionally off. Attestation requires enrollment (Apple App Attest / Google Play Integrity registration); until that is in place the node stays inert rather than blocking. See Mobile Threat for the attestation surface.
device_preflight
The device_preflight node checks a server-verified capability snapshot of the client before the flow relies on those capabilities — camera, NFC, sensors and the like. As with attestation, the capabilities are verified on the server, not taken from a client claim. If the client cannot demonstrate the capabilities the flow needs, the node fails with INSUFFICIENT_CLIENT_CAPABILITY rather than letting the applicant proceed into a step their device cannot complete.
channel_capability_gate
The channel_capability_gate guards that the onboarding channel is capable of the step ahead — gating the flow on whether the current channel and client can support what comes next, so an applicant is not routed into a node their channel cannot satisfy.
The clear line: risk_assessment does not read identity
It is important not to confuse these device-integrity nodes, or the network risk band, with the KYC flow's own risk_assessment node.
The risk_assessment node does not read the identity snapshot. Its inputs are sanctions and biometric evidence — not device, network or related-session signals. Identity risk enters the flow through a different door.
The identity risk band you read about in Onboarding Risk Signals is applied by the network evaluator inside verify_and_decide, not by risk_assessment. Keeping the two separate matters:
risk_assessment— evaluates sanctions and biometric evidence. Does not consume the identity snapshot.verify_and_decideevaluator — where the identity network and session signals (anonymising networks, device familiarity, related-session velocity) fold into the decision.device_attestation/device_preflight/channel_capability_gate— fail-closed integrity gates on the client itself.
So "identity affects the KYC decision" is true — but it happens in the verify_and_decide evaluator and the integrity gates, not in risk_assessment.
Next steps
- Identity in KYC Onboarding — the snapshot and the fail-open bridge
- Onboarding Risk Signals — where the network risk band enters
- Mobile Threat — attestation and on-device integrity signals