Teams often treat customer history, device behaviour, or engagement data as proof of identity. Those signals can improve experience, but they do not confirm who is actually present. Identity verification requires explicit evidence and policy, especially before sensitive actions.
Why This Matters for Security Teams
Personalisation can be useful, but it is not a trust signal by itself. Security teams often blur the line between behavioural familiarity and verified identity, especially in onboarding, account recovery, step-up authentication, and high-risk transactions. That mistake creates a false sense of assurance: the experience feels tailored, yet the underlying identity assertion may be weak, stale, or entirely absent.
For practitioners, the real risk is not only fraud. It is also policy failure. If risk-based logic treats past engagement as proof of presence, attackers who hijack a session, compromise a device, or replay a familiar pattern can inherit trusted treatment without meeting the intended assurance level. Guidance from the eIDAS 2.0 — EU Digital Identity Framework reinforces the broader principle that identity assurance depends on explicit, verifiable credentials and trust frameworks, not inferred familiarity. In practice, many security teams discover this only after a recovery flow, payment event, or support escalation has already been abused.
How It Works in Practice
The right model is to separate experience signals from identity evidence. Personalisation data can inform friction management, fraud scoring, and journey optimisation, but it should not be used as the sole basis for granting access, approving changes, or releasing sensitive data. Strong identity verification usually combines explicit evidence, policy, and context, then applies those signals according to the action being requested.
A practical implementation typically distinguishes between:
- Recognition signals, such as device familiarity, prior login patterns, or past product usage.
- Identity evidence, such as government-issued documents, verified contact methods, biometrics with liveness checks, or trusted digital credentials.
- Authorisation policy, which defines what level of assurance is required for each transaction or lifecycle event.
- Step-up controls, which require stronger proof when the request becomes more sensitive or anomalous.
This distinction matters in customer support, account recovery, payments, healthcare portals, and crypto or fintech workflows, where attackers often target the process rather than the login screen. It also matters under AML and KYC obligations, where the FATF Recommendations — AML and KYC Framework emphasise customer due diligence and risk-based controls rather than assumptions built from historical behaviour. Where identity verification is automated, teams should validate decision inputs, monitor false accepts and false rejects, and preserve an audit trail showing why a specific step was approved or blocked. Mature programs also treat recovery and support channels as privileged identity pathways, because those routes are often easier to exploit than primary authentication. These controls tend to break down when business teams optimise for conversion in high-volume consumer flows because assurance requirements get weakened faster than the fraud model can compensate.
Common Variations and Edge Cases
Tighter verification often increases user friction and operational overhead, requiring organisations to balance fraud reduction against conversion, support cost, and accessibility. That tradeoff is real, and current guidance suggests it should be handled by risk tier rather than by a single universal rule.
There is no universal standard for using behavioural data in identity verification. In low-risk contexts, personalisation can safely reduce friction if the organisation still reserves explicit checks for privileged actions. In higher-risk environments, such as financial services, regulated onboarding, or admin access to sensitive records, behaviour should be treated as a weak signal that may trigger review, not as evidence of who the user is.
Edge cases also matter. Shared devices, family accounts, call-centre assisted recovery, accessibility accommodations, and cross-device journeys can all make “familiarity” misleading. Biometric and document-based checks can improve assurance, but they introduce privacy, bias, and spoofing considerations that need governance, not just tooling. Teams should also remember that NHI and agentic systems can inherit the same design flaw: a trusted service account or AI agent that looks normal over time may still be operating without the assurance needed for a sensitive action. The safest pattern is to tie every high-impact decision to a defined identity policy, not to engagement history alone. For broader digital identity governance, eIDAS 2.0 remains a useful benchmark for explicit trust and assurance rather than inferred trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST CSF 2.0 set the technical controls, while PCI DSS v4.0 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | IAL2 | Identity assurance levels distinguish verified identity from behavioural familiarity. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access decisions need policy-backed control, not inferred trust. |
| PCI DSS v4.0 | 8.4.2 | Sensitive payment actions require stronger authentication than personalisation signals. |
| GDPR | Art. 5(1)(c) | Behavioural data used for verification must be minimised and purpose-limited. |
Use explicit identity proofing and assurance thresholds before high-risk actions.
