FIDO’s focus on account recovery and device identity changes IAM

At a glance

What this is: This is Axiad’s analysis of how FIDO’s new working groups shift IAM attention toward account recovery, device identity, and transaction trust beyond passwords.

Why it matters: IAM teams should treat recovery, device onboarding, and transaction authentication as linked governance problems because weak handling in one area now undermines the others.

By the numbers:

• Today authentication for non-person entities represents over 30% of the identities on Axiad ID Cloud.

Context

FIDO Alliance's work on identity verification for account recovery and secure device onboarding points to a broader IAM gap: authentication is no longer only about signing a person in. Enterprises now have to govern how identities are recovered, how devices are bound, and how digital transactions are trusted after the initial login event.

That matters because account recovery becomes the weakest point as organisations reduce password reliance and expand MFA, while non-person entities continue to grow inside corporate environments. Axiad frames the issue as an identity assurance problem that spans human users, devices, applications, and systems.

The practical question is not whether the login flow is passwordless. It is whether the identity programme can still establish trust when credentials are unavailable, devices must be onboarded securely, or a transaction needs assurance beyond authentication alone.

Key questions

Q: What breaks when account recovery is easier than primary authentication?

A: Attackers target the recovery path because it often carries enough trust to bypass stronger login controls. If password resets, support escalation, or account reactivation are weakly verified, bot operators can take over accounts without needing to defeat the main authentication flow. Recovery then becomes the fastest route into the identity system.

Q: Why do non-person entities need the same lifecycle discipline as user identities?

A: Because machine identities now make up a substantial share of enterprise identity populations and they can create the same access and audit risks as humans, only at higher scale. If devices and applications are onboarded without clear issuance, ownership, and revocation paths, they become persistent trust anchors rather than governed identities.

Q: When should organisations add transaction authentication instead of relying on session login?

A: They should add it when the action itself carries higher risk than ordinary access, such as privileged changes, financial approvals, or device-control operations. Session login only proves initial entry. Transaction authentication proves the specific action is legitimate under the current context, which is a different governance question.

Q: How should organisations balance passwordless authentication with account recovery without increasing customer friction?

A: Treat account recovery as part of the authentication design, not as an afterthought. The strongest approach combines phishing-resistant login, self-service recovery, and adaptive checks that reduce call center dependence while keeping legitimate users moving. If recovery is slow or confusing, customers abandon the journey, so teams should measure friction, recovery success, and support load together.

Technical breakdown

Why account recovery becomes the new trust gap

Account recovery is the process that restores access when an enrolled credential is unavailable, lost, or suspected compromised. In passwordless and MFA-heavy environments, recovery becomes a separate authentication problem rather than a support step, because the recovery channel itself can become the easiest path for attackers. The challenge is to restore access without reintroducing weak proofing, social engineering exposure, or excessive helpdesk discretion. That makes recovery assurance a distinct control surface, not a sub-feature of login. Practical implication: treat recovery as an identity assurance workflow with its own proofing, approvals, and audit requirements.

Practical implication: design recovery with the same scrutiny as primary authentication, not as an exception path.

Device identity and non-person entity onboarding

Device identity is the process of establishing that a device, application, or system is the legitimate actor it claims to be before it can join an environment. For IoT and other non-person entities, onboarding has to remove password dependence while still preserving provenance, lifecycle control, and revocation capability. That usually means binding credentials to hardware, certificates, or other machine identity controls rather than shared secrets. Once devices become part of the corporate trust fabric, unmanaged onboarding becomes an access problem as much as a connectivity problem. Practical implication: make device onboarding an identity workflow with inventory, binding, and revocation, not a network registration step.

Practical implication: govern device onboarding as machine identity lifecycle management.

Transaction authentication extends trust beyond the login event

Transaction authentication verifies that a specific action or interaction is authorised, not just that a user or device has authenticated at session start. This matters when a session can be hijacked, a workflow can be altered in transit, or a privileged action carries higher risk than ordinary access. The article’s point is that confidentiality, integrity, and availability all depend on more than the sign-in ceremony. In other words, identity assurance has to follow the transaction itself. Practical implication: add step-up or contextual verification for sensitive actions, especially where financial, administrative, or device-control actions are involved.

Practical implication: authenticate high-risk actions, not only the session that precedes them.

Threat narrative

Attacker objective: The objective is to regain or establish trusted access through the weakest assurance path and then use that access to manipulate accounts, devices, or transactions.

1. Entry begins when an attacker targets the recovery path rather than the primary login flow, because recovery often has weaker assurance than day-to-day authentication.
2. Credential abuse follows when a compromised recovery channel or poorly verified support process is used to regain access without the original credential.
3. Impact occurs when account access is restored, a device is onboarded, or a transaction is approved under false assurance, allowing misuse of trusted identity paths.

Breaches seen in the wild

• Twilio 0ktapus breach 2022: SMS phishing of employees exposed 209 Twilio customers and 1,900 Signal users, part of the 0ktapus campaign against 130+ firms.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Account recovery has become a first-class identity control, not a support function. When organisations reduce password reliance, they often leave recovery logic behind in a weaker, less governed state. That creates a trust gap where the path back into an account is easier to attack than the primary sign-in flow. The implication is that recovery must be governed as part of the authentication architecture, not bolted on after the fact.

Non-person entity onboarding now sits inside the same governance problem as human authentication. Devices, applications, and systems are not auxiliary accounts once they are allowed to authenticate into corporate infrastructure. Their onboarding, binding, and revocation must be managed as identity lifecycle controls because machine access can scale faster than human access and is often less visible. Practitioners should treat device identity as a governed subject, not an integration detail.

Transaction authentication is the missing layer in many identity programmes. A successful login does not prove that the next action is trustworthy, especially when sessions, workflows, or device states can change after authentication. That is why trust in a digital interaction has to be re-established for sensitive actions. Teams that stop at authentication are protecting entry, not the transaction itself.

Identity assurance now spans people, devices, and actions in one control plane. The old boundary between workforce IAM and machine identity governance is collapsing under real operational use. The field needs a named concept here: identity assurance continuity, meaning trust must persist from recovery to onboarding to transaction approval. Practitioners should evaluate whether their programme can carry assurance across all three moments without dropping into manual exception handling.

FIDO’s direction reflects a category shift in IAM rather than a narrow passwordless improvement. The important change is not just replacing passwords, but recognising that recovery, machine onboarding, and transaction trust are all part of the identity surface. That broader framing aligns with where enterprise access control is already heading. Practitioners should re-centre their governance model on the full identity journey, not just initial authentication.

What this signals

Identity assurance continuity: The real control problem is not isolated authentication events but whether trust can survive the full journey from recovery to device onboarding to high-risk action. Teams that still separate those stages will miss the point where assurance quietly drops.

Governance models built only for human sign-in are no longer enough once devices and applications become active identities. The programme now has to prove who or what is being trusted at each step, and why that trust still holds when credentials, hardware, or sessions change.

For practitioners

• Strengthen recovery verification Require recovery workflows to use proofing, approval, and audit steps that are independent from the primary authentication factor. Avoid letting helpdesk convenience become the default assurance model for lost or locked credentials.
• Inventory non-person entities Maintain a complete inventory of devices, applications, and systems that authenticate into corporate resources. Track ownership, onboarding method, credential type, and revocation status so machine identities do not escape lifecycle control.
• Bind device onboarding to identity controls Use certificate- or hardware-backed identity binding for device onboarding where possible, and make revocation part of the same workflow. Registration alone is not enough if you cannot later prove or remove trust.
• Add verification for sensitive actions Apply step-up verification to high-risk transactions, administrative changes, and device-control actions. Session authentication should not be treated as sufficient proof for every downstream request.

Key takeaways

• Account recovery is now a primary control surface because passwordless and MFA environments leave the recovery path as the easiest place for assurance to fail.
• Non-person entities already make up a material share of enterprise identity activity, which means device identity has to be governed as lifecycle-controlled access.
• Identity programmes need to extend trust beyond login and into onboarding and transaction approval if they want to prevent weak exception paths from becoming the real attack surface.

Key terms

• Account Recovery: Account recovery is the process used to restore access when a user cannot authenticate normally. In mature IAM programmes, recovery is treated as part of the trust chain because a weak reset path can bypass stronger login controls and become the easiest route to account takeover.
• Device Identity: Device identity is the cryptographic proof that a specific machine is the thing being accessed, independent of its IP address or current network. In fleet governance, it allows policy, audit, and revocation to follow the device across locations and transports.
• Transaction Authentication: Transaction authentication is the control layer that validates the trustworthiness of a digital interaction after identity has been established. It focuses on confidentiality, integrity, and availability of the exchange itself, which makes it especially relevant when sign-in alone does not protect the action.
• Non-Person Entity (NPE): An alternative term for non-human identity used in some regulatory and governance frameworks, referring to any entity that is not a human user but holds digital identity and access rights.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.