Yes. Conflicting signals usually mean the session cannot be trusted as a whole, even if one check passes. The right response is to pause automation, route the case for review, and require stronger evidence before account creation proceeds.
Why conflicting device and camera signals should stop onboarding
Onboarding relies on a chain of trust, not on a single passing check. If the device posture says one thing and the camera or liveness signal says another, the session may be partially valid but still unsafe to trust for account creation. That is a control failure, not a minor exception, because it can indicate spoofing, relay, or a mismatched enrollment context.
Conflicts matter because onboarding is where an organisation decides whether to bind a new identity, device, or credential set to a real person and a real endpoint. If those signals do not agree, the safest assumption is that the evidence set is incomplete or manipulated, and the workflow should not advance as if it were clean.
The practical question is not whether any one check succeeded, but whether the combined signal is coherent enough to support a durable trust decision. Strong organisations treat onboarding as an evidence threshold, so a single strong signal cannot override a contradictory one when the result would be a new account, new access path, or new credential lifecycle.
What conflicting signals usually tell you about the session
Conflicting device and camera signals often point to one of three conditions: the wrong device is being used, the visual proof is unreliable, or someone is trying to separate the human claimant from the endpoint being enrolled. In all three cases, the onboarding flow has lost the assurance needed for autonomous completion.
Device checks and camera checks can fail for benign reasons, but the security meaning is the same: the control set cannot yet establish a consistent subject, endpoint, and session relationship. That is why pausing automation and forcing review is better than trying to “average out” the mismatch.
When the mismatch persists, organisations should also treat it as a signal to validate the surrounding assumptions, not just the failed step. That includes the enrollment channel, the device attestation path, the camera capture quality, and whether the user is being asked to re-authenticate from a different context than the one originally approved.
How to handle the exception without weakening onboarding controls
Use a simple decision rule: if the signals are inconsistent, stop the straight-through workflow and move the case to a higher-assurance path. The goal is to preserve trust in the onboarding decision, not to rescue every failed attempt with more automation.
- Require a manual review when the mismatch affects identity binding, device binding, or both.
- Ask for stronger evidence rather than repeated retries when the same contradiction appears more than once.
- Keep the case separate from routine onboarding so the exception does not become a quiet bypass.
- Record which signal conflicted, because pattern analysis matters more than the one-off failure.
Where the organisation allows exceptions, they should be tightly scoped and explicitly owned. An exception is only defensible when the reviewer can explain why the conflict is operational noise rather than a trust-break, and can document what additional evidence closed the gap.
If the workflow is part of regulated customer or employee onboarding, the review path should be deterministic and auditable. That prevents teams from making ad hoc trust decisions under time pressure, which is where bypasses tend to enter.
Risk and Threat Considerations
Conflicting signals are attractive to attackers because they can expose a gap between what the platform thinks it verified and what was actually present during onboarding. A weak response can let spoofed liveness, device swapping, relay activity, or session manipulation slip through at the point where the organisation is about to issue durable access.
Failure mechanism: the onboarding system accepts partial evidence as sufficient and creates an account, device registration, or credential binding even though the session is not coherent end to end.
Impact: the organisation can enrol the wrong subject, legitimise an untrusted device, and create a persistent foothold that is harder to unwind after the fact than it would have been to block at the start.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Conflicting onboarding signals affect whether a new user identity can be trusted and enrolled. |
| IA-3 — Device Identification and Authentication | Device signals are central to deciding whether the enrolling endpoint is trustworthy. | |
| IA-5 — Authenticator Management | Onboarding often issues or binds credentials after trust is established, so conflicts affect credential issuance. | |
| Recommendation — Require stronger identity proofing before creating or activating the account. Validate device identity and block enrollment when the endpoint signal is inconsistent. Delay authenticator issuance until the onboarding evidence set is consistent. | ||
| OWASP ASVS | V6 — Authentication | The question concerns whether authentication evidence is strong enough to continue onboarding. |
| Recommendation — Enforce stronger authentication when onboarding evidence conflicts. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The issue is identity proofing assurance during enrollment and whether evidence is sufficient to proceed. |
| Recommendation — Apply higher assurance and step-up verification before accepting the enrollment. | ||
Practitioner Guidance
What to verify: Confirm that the conflict is visible to the decisioning layer, not just buried in logs. If one signal is strong and the other is contradictory, the workflow should fail closed until a reviewer can reconcile the discrepancy.
Decision rule: If the mismatch affects who is being enrolled or what device is being trusted, do not treat it as a quality issue. Treat it as a trust issue and require additional evidence before account creation continues.
What good looks like: The onboarding system produces a clear exception state, routes it to review, and prevents silent completion until the reviewer explicitly clears the case or rejects it.
Practitioner takeaway: The safest onboarding posture is not maximum automation, it is consistent trust. When key signals disagree, the right control is to slow down, not to guess.
Related resources from NHI Mgmt Group
- What should organisations do when mobile device management and identity policy conflict?
- When should organisations block device code flow entirely?
- Who should own decisions when device signals and identity controls conflict?
- When should organisations prioritise zero-touch onboarding and offboarding over manual device administration?