The login page gets all the attention.
It gets the passkeys, adaptive authentication, bot detection, device intelligence, fraud signals, and carefully designed user journeys.
Account recovery gets a chatbot and a reset button.
That imbalance is becoming dangerous.
In June 2026, Reuters reported that attackers manipulated Meta’s AI-powered support process into resetting credentials for Instagram accounts without independently verifying the identity of the requester. Accounts associated with Sephora, a senior U.S. Space Force official, and the former Obama White House were among those affected.
Meta later disclosed that more than 20,000 Instagram accounts may have been accessed through the issue. The underlying flaw allowed password-reset links to be sent to email addresses that were not already associated with the targeted accounts.
The attackers did not need to defeat a sophisticated login journey.
They found a workflow with enough authority to replace it.
That is the CIAM lesson.
Your security boundary does not end when the user clicks “Forgot password.” Every process capable of recovering, modifying, enrolling, or delegating identity is part of the authentication system, whether the architecture diagram labels it that way or not.
The Side Door Has the Same Keys as the Front Door
Most organizations understand that changing a password is sensitive.
But customer-support and recovery workflows often perform actions that are even more powerful:
- Replacing the account email address
- Changing the recovery phone number
- Resetting a password
- Removing or reenrolling an authentication factor
- Unlocking a suspended account
- Bypassing a failed verification step
- Inviting another user into an account
- Assigning administrative access
Any workflow capable of performing those actions is effectively operating as a privileged identity system.
That includes human support agents.
It includes automated recovery journeys.
It includes AI assistants.
It includes outsourced contact centers.
And in B2B environments, it includes customer and partner administrators managing other users inside their organizations.
The problem is not automation itself. The problem is giving an automated or human support process authority without applying controls proportional to that authority.
A support agent who can replace an authentication factor should not be governed like someone answering a billing question.
An AI assistant that can change a recovery address is not merely a chatbot. It is a privileged operator with access to the customer identity lifecycle.
That distinction matters.
Stronger Login Changes the Attacker’s Route
The industry is making real progress on primary authentication.
The FIDO Alliance reported in May 2026 that approximately five billion passkeys were active worldwide. Its survey found that 90% of consumers were familiar with passkeys and 75% had enabled them on at least some accounts.
That is good news.
Passkeys make traditional phishing and credential theft substantially harder. MFA, device intelligence, behavioral analytics, and risk-based authentication are also raising the cost of attacking the login flow directly.
But attackers are not emotionally attached to the login page.
When the front door gets stronger, they look for another entrance.
The logical next targets are the workflows surrounding authentication:
- Account recovery
- New-device enrollment
- Passkey replacement
- MFA reset
- Email and phone changes
- Help-desk overrides
- Partner administrator actions
- Customer-service impersonation
Removing passwords does not eliminate account-recovery risk.
In some cases, it makes recovery more consequential. A lost device or unavailable passkey creates pressure to offer a fallback path, and attackers know organizations are reluctant to make that path too difficult for legitimate customers.
That creates the central CIAM tension: recovery must be accessible enough to retain customers, but difficult enough to resist impersonation.
“Ask a few questions and send a reset link” is no longer a sufficient answer.
Recovery Should Be Treated as a High-Risk Transaction
Many CIAM programs apply adaptive controls during login but return to static rules during recovery.
That is backwards.
A successful login gives someone access to an account.
A successful recovery can let someone redefine who owns the account.
Recovery should therefore be treated as a high-risk transaction, not a customer-convenience detour.
A mature recovery journey should evaluate more than whether the requester knows an email address or can answer a support question.
Depending on the customer, transaction, and risk level, the journey may consider:
- Whether the request comes from a known device
- Whether the device has previously authenticated successfully
- Recent password, email, phone, or MFA changes
- Impossible travel or unusual location
- Behavioral anomalies
- Account value and privilege level
- Recent fraud or support activity
- Strength of the evidence used to recover the account
- Whether the requested change affects another authentication factor
The response should then match the risk.
A familiar customer recovering access from a known device may receive a low-friction path.
A request to replace both the account email and MFA factor from a new device in a new country should require substantially stronger proof.
That may mean step-up verification, delayed activation, secondary approval, notification through an existing trusted channel, restricted access after recovery, or escalation to a trained human reviewer.
The answer is not to make every recovery painful.
The answer is to stop treating every recovery as equally trustworthy.
Customer Support Is Part of the CIAM Control Plane
Support teams are often viewed as consumers of identity data.
In reality, many are operators of identity.
They can unlock accounts, update profile information, trigger password resets, remove authentication factors, or override automated decisions. That makes the support platform, its agents, and its procedures part of the CIAM control plane.
Organizations should be able to answer:
Who can initiate a credential reset?
Which support actions require step-up authentication from the agent?
Which customer changes require additional verification?
Can an agent change multiple recovery factors in one session?
Are high-risk actions recorded in an immutable audit trail?
Are customers notified through an existing trusted channel?
Can AI-generated recommendations directly trigger identity changes?
What happens when a support account is compromised?
If the answers are unclear, the organization may have built a strong customer login experience on top of a weak administrative bypass.
Support access should be scoped.
Sensitive actions should require stronger assurance.
The person or system performing the change should be attributable.
And an AI agent should never be given more authority than the organization is prepared to govern, monitor, and revoke.
In B2B CIAM, Delegated Administrators Are the Recovery Desk
The same problem appears differently in B2B environments.
A consumer platform may rely on customer support to recover an account. A B2B platform often delegates identity administration to someone inside the customer or partner organization.
That administrator may be able to:
- Invite new users
- Remove existing users
- Assign roles
- Reset access
- Manage federation settings
- Approve requests
- Grant administrative privileges
- Control an entire customer tenant
KuppingerCole’s 2026 B2B IAM guidance highlights scoped delegated administration, tenant isolation, risk-based authentication, lifecycle automation, and auditable governance as core capabilities for managing external organizations.
That framing is important.
Delegated administration is not merely a usability feature.
It is customer-facing privileged access.
A compromised partner administrator can affect more than one account. Depending on the platform, that identity may control an entire organization, supplier relationship, dealer network, or business customer.
B2B CIAM therefore needs to answer questions that basic consumer registration does not:
Which organization does this administrator represent?
Who authorized that relationship?
What can the administrator do within that tenant?
Can the administrator grant permissions equal to their own?
Which actions require step-up authentication?
How are dormant partner administrators detected?
What happens when the administrator leaves the partner company?
How can the platform prove who performed each change?
The ability to delegate administration is valuable.
The ability to constrain and audit that delegation is mandatory.
Secure Every Path That Can Redefine Identity
The industry has spent years strengthening authentication.
That work should continue.
But a passkey-protected login does not help when an untrusted workflow can replace the passkey. Adaptive MFA does not help when a support process can change the account email without equivalent verification. Bot detection does not help when a privileged administrator can invite the attacker directly.
Modern CIAM must secure the entire identity lifecycle:
- Registration
- Authentication
- Recovery
- Factor enrollment
- Profile changes
- Consent
- Delegated administration
- Account suspension
- Account closure
The weakest point may not be where identity is verified.
It may be where identity is allowed to change.
How Navar Helps
Navar helps organizations design CIAM programs around complete customer and partner journeys, not isolated login screens.
That includes:
- B2C and B2B CIAM architecture
- Adaptive authentication and step-up orchestration
- Account-recovery journey design
- Passkey and MFA enrollment strategies
- High-risk profile-change controls
- Fraud-signal integration
- Customer-support authorization
- Partner and tenant administration
- Scoped delegated access
- Journey testing and abuse-case analysis
- Logging, auditability, and operational handoff
Our focus is practical: identify which workflows can create, replace, recover, or delegate identity, then apply controls appropriate to the authority each workflow holds.
Because the login page is only one entrance.
Navar helps secure the rest of the building.
