What attacks target Itsme?

What attackers usually do to abuse Itsme

The common attack paths are social engineering and account compromise, not a flaw in the brand itself. Phishing tries to steal credentials or redirect the user into a fake approval flow. Device compromise and SIM swap attacks aim to take over the phone or its recovery path, while fraudulent approval prompts exploit user trust at the exact moment a login or payment is being confirmed.

That mix matters because it shifts the problem from “breaking” the service to stealing or steering a legitimate user action. In practice, attackers often need only one successful consent event, one compromised device, or one hijacked channel to turn a normal authentication step into unauthorised access.

Why approval-based attacks work so well

Approval-based attacks succeed when users see a notification, code, or request and treat it as routine. The attacker’s goal is to create urgency, fatigue, or confusion so the victim approves a login, links a device, or authorises a payment without checking the context. Once the prompt is accepted, the attacker is using legitimate trust, not forcing entry.

That makes the human decision point part of the attack surface. If the prompt does not clearly show the right transaction, device, or action scope, the user is more likely to approve something they did not intend. Attackers exploit that mismatch between the real request and the user’s mental model of what they are approving.

What defenders should monitor and verify first

Early warning signs are repeated authentication failures, a new device enrolment, unusual approval behaviour, and unexplained changes to contact details. Those signals often appear before a full takeover, especially when the attacker is testing credentials, forcing repeated prompts, or trying to move the account to a device they control.

Defenders should verify whether the event is an isolated user error or part of a broader compromise pattern. If the same account shows failed logins followed by a successful approval from a new device or changed contact channel, treat that as a potential compromise chain rather than a harmless anomaly. Suspicious changes to phone numbers or recovery details deserve immediate review because they can enable follow-on takeover.

Risk and Threat Considerations

These attacks are high risk because they target the most reliable point in many login flows, the person making the approval decision. Once an attacker controls the phone, the SIM, or the approval moment, the security boundary can shift from strong authentication to attacker-led authorisation.

Failure mechanism: The attacker either captures the user’s credentials, intercepts the recovery path, or pressures the user into approving a request that looks legitimate but is attacker initiated.

Impact: The result can be unauthorised account access, fraudulent payments, account recovery abuse, and in some cases the takeover of other services that rely on the same trusted identity flow.

Practitioner Guidance

What to verify: Investigate any login or payment event that combines a new device, an approval prompt, and a recent change to contact details. That combination is stronger evidence of abuse than any single signal on its own.

Decision rule: If the action is higher risk than a normal login, require an additional check that is independent of the same phone, session, or notification channel. If the event is sensitive enough to move money or alter recovery data, do not rely on one approval alone.

What good looks like: Users can see exactly what they are approving, and security teams can quickly distinguish routine enrolment from suspicious enrolment, routine failure from attack probing, and genuine step-up from coerced approval.

Practitioner takeaway: For approval-driven identity attacks, the control objective is to make every high-value action both visible and hard to impersonate, because the attacker is usually targeting trust in the prompt rather than the authentication engine itself.

Related resources from NHI Mgmt Group

• Guide: Digital Identity, eID and Identity Wallets Guide
• How can organizations counter AI-driven cyber attacks?
• Who should own identity risk when attacks target both people and third-party access?
• How should security teams handle vishing attacks that target SaaS support workflows?
• Why do supply-chain attacks increasingly target secrets instead of just code integrity?