Notifications
Clear all
Topic starter
12/06/2026 9:57 pm
TL;DR: More than 70% of enterprises now rank identity-based attacks as a top concern, while 40% of those attacks are AI-powered and 88% of security professionals report rising bot activity, according to Arkose Labs. Device identification can reduce friction, but it does not remove the underlying trust problem in registration, login, and payments.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- 70% of enterprises consider identity-based attacks, ed attacks, including fake account creation and account takeovers, their top security concern.
- 40% of these attacks are AI-powered, reflecting the growing sophistication of modern threats.
- 88% of security professionals report a rise in AI-powered bot attacks, where bots can mimic trusted devices and identities to evade detection.
Questions worth separating out
Q: How should security teams use device identification without over-trusting it?
A: Use device identification as a correlation signal, not as proof of legitimacy.
Q: Why do AI-powered bots make identity-based fraud harder to stop?
A: AI-powered bots can adapt to challenge responses, mimic trusted device traits, and automate repeated attempts at scale.
Q: What breaks when device trust is treated as a standalone control?
A: Standalone device trust breaks when attackers reuse credentials, spoof browser signals, or simulate normal session behaviour long enough to pass a simple reputation check.
Practitioner guidance
- Treat device identity as a decision signal, not a trust verdict. Combine device identifiers with account age, credential history, session patterning, and transaction context before allowing access or payment completion.
- Harden recovery and step-up paths against AI-assisted abuse. Review password reset, account recovery, and challenge bypass logic for paths that reward a fraudster who has already mimicked a trusted device.
- Preserve lineage across device reputation changes. Version your device trust logic so historical fraud patterns remain visible after updates, and retain a mapping between old and new identifiers.
What's in the full announcement
Arkose Labs' full article covers the implementation detail this post intentionally leaves for the source:
- How Arkose Device ID creates persistent identifiers from browser configuration, hardware attributes, and session telemetry.
- How risk rules are tuned for registration, login, account takeover, account sharing, and payment workflows.
- How versioning preserves continuity between old and new identifiers when the underlying detection logic changes.
- How challenge bypass decisions are configured to reduce friction for returning devices without weakening enforcement.
👉 Read Arkose Labs' article on Arkose Device ID and AI-powered fraud →
Device IDs, AI-powered fraud, and the trust gap in login flows?
Explore further
13/06/2026 12:23 am
Device identity is not a trust boundary, it is a correlation layer. The article treats persistent device identifiers as a way to separate legitimate users from fraudulent traffic, but that signal only has value when it is combined with account, session, and behavioural context. In identity security terms, the device becomes evidence, not proof. Practitioners should therefore stop treating device reputation as a decisive control and start treating it as one input in a broader identity decisioning model.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
A question worth separating out:
Q: Who should own device risk decisions in an IAM programme?
A: Device risk decisions should be shared across fraud, IAM, and customer identity teams because the control affects authentication, account security, and transaction authorisation at once. If those teams work separately, the organisation usually creates inconsistent friction and blind spots that attackers can exploit across the customer journey.
👉 Read our full editorial: Arkose Device ID and the limits of device trust in fraud defense
