AI Agents Need Autonomy Budgets, Not Just Governance Policies

Posted on by
Reply

Most organizations are granting AI agents authority faster than they are defining the limits of that authority.

That is the problem.

We have already started treating AI agents as digital workers. That is the right mental model. An agent that can access data, call tools, trigger workflows, generate artifacts, influence decisions, or alter enterprise state is not just another application. It needs identity. It needs boundaries. It needs oversight. It needs evidence. It needs a human owner. It needs a kill switch. That has been the right foundation for agent governance. 

But it is not enough.

There is another question that needs to be asked much earlier:

How much damage is this agent allowed to cause before a human must approve the next action?

Not theoretically.

Not in vague risk language.

In actual economic terms.

How much money can it spend?
How many systems can it change?
How many records can it touch?
How much customer impact can it create?
How much privacy exposure can it cause?
How much reputational risk can it accumulate?

If we cannot answer those questions, we have not governed autonomy.

We have only documented intent.

ModelTesting

The Missing Control: Economic Blast Radius

Security people are comfortable talking about blast radius.

We use the phrase when we talk about network segmentation, credential compromise, ransomware containment, cloud permissions, production access, and incident response. The idea is simple: assume something fails, then design the environment so the failure does not become catastrophic.

AI agents need the same treatment.

But with agents, blast radius is not only technical. It is also economic.

An agent can consume resources.
An agent can make choices.
An agent can initiate actions.
An agent can change state.
An agent can expose data.
An agent can create obligations.
An agent can influence people.
An agent can make the organization look careless, unfair, unsafe, or incompetent.

That means the agent is not merely a software component.

It is an actor inside the business.

And actors need limits.

Responsible AI Policies Are Not Autonomy Budgets

Many organizations are already trying to address AI risk.

They are writing responsible AI policies.
They are creating approval workflows.
They are forming model risk committees.
They are deploying prompt filters.
They are experimenting with AI security gateways.
They are adding manual reviews around sensitive use cases.

All of that is useful.

None of it is sufficient by itself.

The gap is that most of those controls do not quantify the maximum loss an agent can create before human approval is required.

A policy might say:

“AI-generated financial actions require review.”

That sounds reasonable.

But what does it actually mean?

Can the agent approve a $50 refund?
Can it approve $500?
Can it issue 10,000 refunds at $50 each?
Can it retry failed payments?
Can it change pricing?
Can it modify a vendor record?
Can it recommend a wire transfer?
Can it initiate the workflow but not complete it?
Can it draft the customer message but not send it?
Can it update the CRM but not the billing system?

Without numeric thresholds, the policy is mostly aspiration.

The agent still has authority.
The business just has not priced it.

First Principles: What Is an Agent?

To govern AI agents well, we need to strip away the hype and start from first principles.

An AI agent is an autonomous or semi-autonomous actor that can:

  1. Consume inputs from users, systems, documents, APIs, messages, logs, tickets, databases, or the internet.
  2. Interpret goals using a model, prompt, policy, memory, context, or workflow.
  3. Select actions based on that interpretation.
  4. Use tools to retrieve data, generate outputs, modify systems, trigger processes, or communicate with people.
  5. Create consequences inside the enterprise.

That last point matters most.

The business does not suffer because an agent “thought” something incorrect.

The business suffers when the agent’s incorrect reasoning becomes action.

A hallucinated summary is annoying.

A hallucinated summary sent to regulators is risk.

A bad recommendation is manageable.

A bad recommendation that automatically changes production configuration is an incident.

A mistaken customer classification is unfortunate.

A mistaken customer classification that denies service, changes pricing, or triggers collections is a business problem.

The risk is not the model in isolation.

The risk is the combination of model, authority, tools, data, workflow, and consequence.

The Autonomy Budget

An autonomy budget is the maximum amount of authority an AI agent can exercise without additional approval.

It defines how much business impact the agent is allowed to create on its own.

Think of it like a spending limit, but broader.

A corporate credit card does not give an employee unlimited purchasing authority. It has a limit. A purchase order process has thresholds. A junior analyst cannot usually approve a seven-figure vendor contract. A new system administrator should not begin with global admin. A customer support representative may be able to issue small credits, but not rewrite revenue recognition policy.

We already understand this model for people.

We need to apply it to agents.

An autonomy budget should define limits across several dimensions:

1. Financial Authority

How much money can the agent spend, refund, approve, transfer, discount, credit, allocate, or influence?

Examples:

  • Maximum dollar value per transaction
  • Maximum cumulative dollar value per day
  • Maximum discount percentage
  • Maximum refund amount
  • Maximum procurement threshold
  • Maximum cloud spend increase
  • Maximum number of paid resources it can provision
  • Maximum value of invoices it can route or approve

This matters because many agent failures will not look like classic security incidents. They will look like leakage, waste, fraud exposure, billing errors, margin erosion, or uncontrolled operational cost.

2. Operational Authority

How much change can the agent make to systems, workflows, or production environments?

Examples:

  • Read-only access versus change access
  • Number of records it can modify
  • Number of users it can affect
  • Number of systems it can touch
  • Ability to restart services
  • Ability to deploy code
  • Ability to change configuration
  • Ability to create tickets but not close them
  • Ability to recommend remediation but not execute it

This is where traditional change control and agentic autonomy collide.

A human engineer may understand that “fix the issue” does not mean “restart every production service during peak traffic.”

An agent may not.

Unless the boundary is explicit.

3. Privacy Authority

How much sensitive data can the agent access, process, summarize, transmit, or expose?

Examples:

  • Maximum number of customer records per task
  • Permission to access regulated data
  • Permission to summarize sensitive content
  • Permission to include sensitive data in prompts
  • Permission to transmit data to third-party systems
  • Limits on memory retention
  • Limits on cross-domain correlation
  • Limits on exporting, emailing, or embedding sensitive information

AI agents change the privacy risk model because they often operate by pulling context together.

That context may be individually harmless but collectively sensitive.

An agent that reads one customer note may be low risk.

An agent that reads every customer note, correlates them with billing records, drafts outreach, and sends the output through a third-party workflow has a very different blast radius.

4. Reputational Authority

How much public, customer-facing, employee-facing, or partner-facing communication can the agent perform without review?

Examples:

  • Can it draft messages only?
  • Can it send internal messages?
  • Can it respond to customers?
  • Can it post externally?
  • Can it negotiate?
  • Can it apologize on behalf of the company?
  • Can it make commitments?
  • Can it communicate about outages, legal matters, security incidents, HR issues, or pricing?

Reputational authority is often overlooked because it does not fit cleanly into IAM.

There is no simple permission called “damage customer trust.”

But agents can absolutely do that.

One poorly worded automated message during an outage can create more executive attention than a dozen blocked malware attempts.

5. Decision Authority

What decisions can the agent make, and which decisions can it only recommend?

Examples:

  • Hiring decisions
  • Fraud decisions
  • Access approvals
  • Security severity ratings
  • Vendor risk scoring
  • Customer eligibility
  • Account suspension
  • Legal routing
  • Incident escalation
  • Production remediation

This is one of the most important distinctions in agent governance:

Recommendation is not the same as execution.

An agent that recommends disabling an account is one thing.

An agent that disables the account is another.

An agent that recommends terminating a vendor relationship is one thing.

An agent that initiates the termination workflow is another.

The control question is not simply, “Can the agent reach the conclusion?”

The control question is, “Can the agent make the conclusion real?”

Loss Thresholds: The Human Approval Line

Once we define autonomy budgets, we need loss thresholds.

A loss threshold is the point where autonomous action must stop and human approval must begin.

For example:

  • The agent may approve refunds up to $100 per customer, but anything above that requires human approval.
  • The agent may modify up to 25 low-risk records per task, but bulk changes require review.
  • The agent may draft external communications, but cannot send them without approval.
  • The agent may provision cloud resources up to a daily cost ceiling, but cannot exceed it.
  • The agent may recommend incident containment, but production isolation requires human authorization unless a declared emergency mode is active.
  • The agent may read sensitive records for a specific task, but cannot export or summarize more than a defined volume without approval.

That is where governance becomes operational.

The question changes from:

“Do we trust this agent?”

to:

“What is this agent allowed to risk?”

That is a much better question.

Trust is vague.

Risk can be modeled.

The Agent Authority Ledger

Every production AI agent should have an authority ledger.

Not just a description.
Not just an owner.
Not just a model card.
Not just an architecture diagram.

A ledger.

It should document, at minimum:

  • Agent name and unique identity
  • Business owner
  • Technical owner
  • Data domains accessible to the agent
  • Tools the agent can invoke
  • Systems the agent can change
  • Decisions the agent can make
  • Decisions the agent can only recommend
  • Financial authority limits
  • Operational authority limits
  • Privacy limits
  • Communication limits
  • Escalation thresholds
  • Required evidence logs
  • Kill-switch mechanism
  • Review cadence
  • Expiration or reauthorization date

This does not have to be complicated at first.

A spreadsheet is better than nothing.

A GRC record is better than a spreadsheet.

An integrated control plane is better still.

But the key is that the organization must be able to answer a simple question quickly:

What can this agent do before a human gets involved?

If that answer requires a meeting, three Slack threads, and a developer reading through code, the agent is not governed.

It is merely deployed.

Autonomy Budgets Should Be Tiered

Not every agent needs the same level of control.

A read-only research assistant that summarizes internal policy documents is not the same as an agent that can modify firewall rules, issue refunds, provision infrastructure, approve vendors, or message customers.

A practical model is to define autonomy tiers.

Tier 0: No Autonomy

The agent can answer questions or draft content, but it cannot take action.

Human review is required for all external outputs and all system changes.

This is where many agents should start.

Tier 1: Low-Impact Autonomy

The agent can perform limited, reversible, low-value actions.

Examples might include creating draft tickets, labeling documents, routing requests, or updating non-critical metadata.

The budget is small.
The actions are reversible.
The blast radius is contained.

Tier 2: Controlled Business Autonomy

The agent can complete defined business tasks within strict thresholds.

Examples might include issuing small refunds, scheduling routine workflows, provisioning pre-approved resources, or updating limited record sets.

Human approval is required when thresholds are exceeded.

Tier 3: High-Impact Autonomy

The agent can affect production systems, regulated data, financial workflows, security controls, customer communications, or business-critical decisions.

This tier requires strong identity, logging, testing, monitoring, approval gates, and rapid containment.

Tier 4: Emergency or Exceptional Autonomy

The agent can act at machine speed during declared emergency conditions.

This might apply to containment workflows, fraud response, or infrastructure protection.

But this authority should be temporary, heavily logged, explicitly invoked, and automatically revoked when the emergency state ends.

The higher the tier, the more evidence the organization should require.

Autonomy should be earned.

And it should be revocable.

The Failure Mode Is Not Always Malice

It is tempting to frame agent risk entirely around attackers.

Prompt injection.
Credential theft.
Data exfiltration.
Tool abuse.
Supply-chain manipulation.
Compromised models.

Those threats are real.

But many agent failures will be boring.

The agent misunderstood the instruction.
The workflow retried too many times.
The API returned unexpected data.
The prompt lacked a business rule.
The model produced a confident but wrong answer.
The agent optimized for task completion instead of risk reduction.
The test environment did not match production.
The human assumed someone else had reviewed the output.

This is why autonomy budgets matter.

They protect the organization from adversarial abuse, but they also protect it from normal failure.

Bad automation is not new.

What is new is automation that can reason, chain actions, consume messy context, and operate across business workflows with a level of flexibility that older systems did not have.

That flexibility is useful.

It is also dangerous when paired with undefined authority.

A Simple Formula for Agentic Exposure

Here is a practical way to think about it:

Agentic Exposure = Autonomy × Access × Actionability × Consequence

Where:

  • Autonomy is how independently the agent can decide what to do.
  • Access is what data, systems, credentials, and workflows it can reach.
  • Actionability is whether it can merely recommend or actually execute.
  • Consequence is the business impact if it is wrong, manipulated, or misused.

Most organizations are looking at access.

Some are looking at autonomy.

Fewer are looking closely at actionability.

Almost none are quantifying consequence.

That is the gap.

An agent with high access but no ability to act may be a privacy concern.

An agent with low access but high actionability may still create operational trouble.

An agent with high autonomy, broad access, real tool execution, and material business consequence is not a pilot.

It is a controlled risk asset.

Treat it that way.

What CISOs and Governance Teams Should Do Now

Start with the agents that can create real-world consequences.

Do not begin with philosophical debates about artificial general intelligence.

Begin with inventory.

Ask:

  • What agents exist today?
  • Which ones can call tools?
  • Which ones can access sensitive data?
  • Which ones can change systems?
  • Which ones can communicate externally?
  • Which ones can spend money or influence financial workflows?
  • Which ones can affect customers, employees, vendors, or production operations?
  • Which ones can chain actions across systems?
  • Which ones have no clear owner?

Then assign each agent an autonomy tier.

Define its budget.

Set its thresholds.

Instrument the evidence trail.

Test the kill switch.

Review the results.

This should not be treated as a one-time AI governance exercise. It should become part of identity governance, access management, change control, vendor risk, privacy review, incident response, and enterprise architecture.

AI governance committees should not only ask whether an agent is fair, explainable, secure, or compliant.

They should ask:

What is the maximum loss this agent can create before a human must approve the next step?

That question will make some people uncomfortable.

Good.

That means it is getting close to the real risk.

Autonomy Without Budgets Becomes Unlimited Liability

Organizations do not give employees unlimited authority on their first day.

They do not give every developer production access.

They do not give every analyst the ability to approve payments.

They do not let every help desk technician change identity policy.

They do not let every marketing intern publish public statements without review.

Not because those people are bad.

Because authority needs structure.

AI agents deserve the same discipline.

The next phase of agent governance is not just about knowing what agents are, who owns them, and how to shut them off.

It is about defining how much independent authority they are allowed to exercise in economic, operational, privacy, and reputational terms.

Agents need identities.

Agents need boundaries.

Agents need oversight.

Agents need evidence.

Agents need owners.

Agents need kill switches.

And now, just as importantly, agents need autonomy budgets.

Because if you do not define the agent’s blast radius, the business will discover it the hard way.

More Information and Help

If your organization is deploying AI agents, copilots, autonomous workflows, or AI-enabled business processes, now is the time to move beyond general policy and into measurable control.

MicroSolved can help with agentic threat modeling, AI governance, identity design, workflow risk assessment, control validation, and tabletop exercises focused on real-world failure modes.

The goal is not to stop innovation.

The goal is to make autonomy safe enough to scale.

Relax. We’re on watch.

 

 

AI tools were used as a research assistant for this content, but human moderation and writing are also included.

Account Recovery Is Becoming the New Identity Attack Surface

Posted on by
Reply

As passkeys and phishing-resistant authentication reduce password risk, attackers will move pressure to the recovery plane.

The industry is moving in the right direction.

Passkeys, FIDO2/WebAuthn, hardware security keys, conditional access, better MFA policies, and risk-based sign-in controls are all meaningful improvements. They reduce entire classes of credential theft. They make phishing harder. They remove reusable passwords from many authentication ceremonies. They shift more of the security burden from user judgment to protocol design.

That is good.

But it is not the finish line.

In my recent passkeys article, I called out a point that deserves its own treatment: passkeys do not solve weak account recovery, help desk social engineering, stolen session tokens, OAuth consent abuse, unmanaged vendor access, or excessive privilege. They are a major step forward, but they do not remove the rest of the identity attack surface. 

That matters because attackers adapt.

If passwords become harder to steal, guess, spray, reuse, or phish, attackers will apply pressure somewhere else. They will go where the assurance is weaker, the workflows are more manual, the exceptions are more frequent, and the blast radius is still large.

Increasingly, that place is account recovery.

PassKey

The Inversion Test

A useful way to think about this is inversion.

Do not start with the defender’s roadmap. Start with the attacker’s question:

Once passwords disappear, where would I attack next?

The answer is usually not exotic.

I would attack the process that lets a user back into the account after they lose the device.

I would attack the support workflow that removes an authenticator.

I would attack the exception path that grants temporary access.

I would attack the SaaS admin who can approve OAuth grants.

I would attack the vendor portal that still uses email-based recovery.

I would steal a browser session instead of a password.

I would enroll a new device.

I would persuade the help desk to do for me what the authentication system will not.

That is the problem.

Authentication is getting stronger, but recovery is often still treated like customer service, not like privileged access.

The Recovery Plane Is Bigger Than Password Reset

When many teams hear “account recovery,” they think about password reset.

That definition is too narrow.

The recovery plane includes every path that can restore, replace, bypass, reset, re-enroll, approve, or extend access after normal authentication fails or becomes inconvenient.

That includes:

  • Password reset and account unlock workflows
  • MFA reset
  • Authenticator removal
  • Passkey re-enrollment
  • Lost phone and device replacement processes
  • Temporary access passes
  • Emergency access procedures
  • Help desk verification scripts
  • Vendor support portals
  • OAuth consent grants
  • Long-lived sessions
  • Break-glass accounts
  • Shared accounts
  • Offboarding workflows

That is a lot of surface area.

It is also where many organizations have the least visibility.

They can tell you how many users enrolled a passkey. They can tell you how many privileged users have hardware keys. They can show a nice adoption dashboard.

But ask how many privileged recovery events occurred last quarter, how many required human exception, how often callbacks used known-good numbers, how many OAuth grants have offline access, or how many vendor admins can recover access without the organization’s IdP, and the room gets quieter.

That is not because security teams do not care.

It is because the measurements have not caught up to the new risk.

Passkey Adoption Is Not the Same as Recovery Risk Reduction

Most passkey programs measure adoption.

That is understandable. Adoption matters. A phishing-resistant authenticator that nobody uses is not a control; it is a feature sitting idle.

But adoption alone can become a vanity metric.

A dashboard that says “82% of users have enrolled passkeys” may look good while the recovery plane remains weak. A privileged administrator may have a hardware key and still be vulnerable if a support agent can remove that key after a convincing phone call. A finance user may authenticate with a passkey and still have an OAuth grant that allows a third-party application to read mail and files. A SaaS admin may have phishing-resistant login and still carry a session token that can be replayed from an infected endpoint.

In other words, the front door can improve while the side doors remain unchanged.

The right question is not only:

How many users have passkeys?

The better question is:

Can an attacker still recover, re-enroll, delegate, or persist access without satisfying the same level of assurance we require at login?

That question changes the program.

Why Attackers Like Recovery Paths

Recovery paths are attractive because they are designed for failure.

Users lose phones. Laptops die. Executives travel. Hardware keys get left at home. Contractors change devices. Mergers bring strange identity histories. Help desks are measured on resolution time. Business units want access restored now. Support teams are asked to be helpful, empathetic, and fast.

Attackers understand this.

They do not need to defeat your strongest control if they can trigger a workflow that temporarily removes it. They do not need a zero-day if they can convince a support agent that the CFO is locked out before payroll closes. They do not need to phish a password if a malicious OAuth application can be granted the right permissions. They do not need to reauthenticate if a stolen session or refresh token remains valid.

This is second-order identity risk.

The first-order improvement is passwordless authentication.

The second-order attacker response is pressure on the lifecycle around authentication.

That is where many programs are underbuilt.

Help Desks Are Now Part of the Identity Control Plane

Help desk directors should be in the room for passkey planning.

Not after rollout.

Before rollout.

The support function is no longer just a service channel. In a passwordless environment, it becomes one of the places where identity assurance is either preserved or quietly downgraded.

When a support agent removes an authenticator, issues a temporary access pass, resets MFA, unlocks an account, updates a phone number, or approves device replacement, that agent may be changing the effective security posture of the identity.

For normal users, that can still matter.

For privileged users, it can be catastrophic.

Scattered Spider is a useful warning here. CISA has described the group’s use of social engineering to convince IT help desk personnel to reset passwords and MFA tokens, and CISA’s mitigation guidance emphasizes phishing-resistant MFA such as FIDO/WebAuthn. 

The broader lesson is that support and recovery workflows can become identity attack paths when attackers cannot easily defeat the primary login ceremony.

The lesson is simple: recovery for privileged users should not be a normal ticket.

It should be a controlled ceremony.

That means strong proofing, out-of-band verification using known-good contact information, two-person approval, time-bound access, explicit logging, alerting to security operations, and post-event review.

It also means the help desk needs permission to slow down when risk is high.

“Fast resolution” cannot be the only service metric when the request changes identity assurance.

Fallback Methods Are the Old Attack Surface Wearing a New Name

Fallback methods are often kept for good reasons.

They reduce lockouts. They make pilots easier. They help executives. They make support less painful. They allow legacy applications to keep working. They reduce friction for BYOD and remote users.

But they also preserve the attack surface that passkeys were meant to reduce.

SMS, voice OTP, email OTP, TOTP, push approval, security questions, personal email recovery, and “call the help desk” workflows can become the weakest link in an otherwise strong authentication program.

That does not mean every fallback disappears on day one.

It means fallback must be governed by risk tier, not convenience.

For privileged users, weak fallback should be removed first.

For high-risk business users, fallback should be limited, logged, and reviewed.

For standard users, fallback should be transitional and measured.

For vendors, fallback should be part of the access contract.

For break-glass accounts, fallback should be designed, vaulted, monitored, and tested.

Do not let fallback become the permanent exception nobody owns.

Device Replacement Is a Security Event

Passkeys change the device lifecycle.

If the authenticator is a phone, laptop, platform credential, password manager, sync fabric, or hardware key, then device loss and device replacement become security-sensitive workflows.

A new phone is not just a new phone.

It may be the path to a new authenticator.

A laptop rebuild is not just an endpoint ticket.

It may become a passkey re-enrollment event.

A password manager recovery is not just a user convenience problem.

It may restore access to synced credentials.

NIST’s current SP 800-63B language draws an important assurance distinction here: syncable authenticators are not allowed at AAL3 because syncing requires the private key to be exportable, while AAL3 requires stronger hardware-protected key handling. 

That distinction should shape enterprise recovery design.

The organization should know which authenticators are allowed for which risk tiers, whether credentials are synced or device-bound, how many authenticators each user must maintain, what happens when one is lost, and who can approve replacement.

For high-risk roles, device replacement should trigger stronger checks than normal sign-in.

If the attacker’s goal is to become the new device, then treating new-device enrollment as routine is a mistake.

OAuth Grants Are Recovery’s Cousin

OAuth consent is not account recovery in the traditional sense, but it belongs in the same risk conversation.

Why?

Because OAuth grants can create durable delegated access that survives the user’s normal login ceremony. In many attacks, the adversary does not need the password. The user is tricked into granting a malicious or compromised application access to mail, files, contacts, or other SaaS data. The attacker then operates through authorized application access rather than a classic interactive login.

Microsoft describes consent phishing as an attack where users are tricked into granting permissions to malicious cloud applications, allowing those applications to access legitimate cloud services and user data. Microsoft also recommends auditing applications and consented permissions, limiting user consent, and monitoring suspicious application behavior. 

Red Canary describes application access token theft as a technique adversaries use to gain unauthorized access to SaaS, cloud, and containerized resources, including through OAuth consent grant attacks. 

That is an identity bypass from a governance point of view.

If your passkey program does not include connected-app review, admin consent workflows, publisher verification, permission classification, and revocation procedures, then you have left a major identity path out of scope.

This is especially important in Microsoft 365, Google Workspace, Salesforce, GitHub, Slack, Box, Dropbox, and other SaaS-heavy environments where business productivity depends on integrations.

Security teams should ask:

  • Who can consent to applications?
  • Which grants include mail, files, directory, impersonation, or offline access?
  • Which applications are publisher verified?
  • Which grants are unused, stale, or excessive?
  • Which service principals have tenant-wide reach?
  • How quickly can suspicious consent be revoked?
  • Are OAuth changes visible in the SIEM?

Do not celebrate passwordless authentication while ignoring delegated access.

Sessions Are Where Authentication Becomes Authorization

Another uncomfortable point: authentication strength does not automatically protect the entire session.

After authentication succeeds, applications issue session tokens, cookies, and refresh tokens. Those artifacts often become the practical proof that the user is already trusted. If malware, a phishing proxy, browser compromise, or endpoint theft captures that token, the attacker may be able to bypass the login ceremony entirely.

Ping Identity describes session hijacking as reuse of a stolen session token to impersonate a logged-in user; because the attack occurs after login, MFA may already be satisfied. 

Microsoft has also published guidance on cloud token theft, including prevention, detection, and response considerations for token-based attacks. 

That is why session governance belongs in the passkey roadmap.

Shorter session lifetimes, device compliance, token binding where available, continuous access evaluation, impossible travel detection, user-agent and device mismatch analytics, rapid revocation, EDR coverage, browser hardening, and SaaS session visibility all matter.

Passkeys reduce credential theft.

They do not make stolen sessions harmless.

A Recovery-Plane Risk Score

Organizations need a way to score recovery paths the same way they score applications, data, vendors, and vulnerabilities.

Here is a practical model.

Factor Question High-Risk Signal
Proof strength How strongly does the process verify the person requesting recovery? Email access, caller ID, personal information, or manager approval alone.
Social-engineering exposure Can a human be pressured into overriding controls? Phone-only recovery, urgent executive exceptions, vague escalation rules.
Exception frequency How often is the standard process bypassed? Frequent temporary access, recurring VIP exceptions, non-expiring risk acceptances.
Blast radius What can the recovered account access? Admin roles, finance workflows, HR data, developer systems, mailboxes, cloud consoles.
Persistence Does recovery create long-lived access? Refresh tokens, remembered devices, OAuth grants, persistent sessions, new authenticators.
Visibility Can security see and investigate the event? No SIEM logging, no alerting, limited ticket context, SaaS-only logs.
Ownership Who governs the path? No control owner, no review cadence, split responsibility between IAM and support.

Score each recovery path from 1 to 5 on each factor.

Then multiply or weight by user tier.

A recovery path for a standard user with limited SaaS access is not the same as a recovery path for a global admin, payroll approver, domain admin, developer with production access, or vendor administrator.

Do not flatten the organization.

Risk is not evenly distributed. Recovery controls should not be either.

What Leaders Should Measure

CISOs and IAM leaders should add recovery-plane metrics to identity dashboards.

At minimum, track:

  • Recovery events by user tier
  • Authenticator resets and removals
  • New authenticator enrollments
  • Temporary access passes
  • Privileged recovery exceptions
  • Help desk recovery requests denied or escalated
  • Recovery events outside business hours
  • Users with fewer than two approved authenticators
  • Weak fallback still enabled by tier
  • OAuth grants by risk level
  • Long-lived session exceptions
  • Third-party accounts without phishing-resistant authentication
  • Vendor support paths that bypass the primary IdP
  • Open recovery exceptions by owner and expiration date

The executive dashboard should answer a plain question:

Can someone get back into a high-risk account through a process weaker than the process required to sign in?

If the answer is yes, the organization has work to do.

A Practical 90-Day Plan

Days 0–30: Inventory the Recovery Plane

Start with the systems that matter most:

  • IdP
  • Email
  • Endpoint management
  • PAM
  • Cloud consoles
  • Finance systems
  • HR systems
  • Developer platforms
  • Backup consoles
  • EDR
  • SIEM
  • Ticketing
  • Major SaaS applications

For each system, document:

  • Normal authentication method
  • Recovery method
  • Fallback methods
  • Approval path
  • Required proof
  • Generated logs
  • Alerts
  • Temporary access lifetime
  • Post-recovery review process

Do not start by buying another tool.

Start by finding the paths.

Days 31–60: Harden High-Risk Recovery

Prioritize administrators, executives, finance, HR, developers, help desk staff, security staff, and third parties with privileged or sensitive access.

For those users:

  • Require at least two approved authenticators before enforcement.
  • Remove weak fallback where feasible.
  • Require device-bound passkeys or hardware keys for privileged access.
  • Implement two-person approval for privileged authenticator reset.
  • Use known-good callback procedures.
  • Alert on authenticator removal and re-enrollment.
  • Require post-recovery review for high-risk accounts.

This is also the time to train the help desk on adversarial recovery scenarios.

Not generic security awareness.

Specific scripts.

Specific red flags.

Specific escalation authority.

The help desk needs to know when a request is no longer just a request.

It is a security event.

Days 61–90: Govern Tokens, Grants, Vendors, and Exceptions

Once the human recovery paths are under control, expand to adjacent identity persistence.

Review OAuth grants and connected applications.

Restrict user consent for higher-risk permissions.

Implement admin consent workflows.

Review refresh token and session lifetime policies.

Test rapid session revocation.

Identify vendor-controlled recovery paths.

Require phishing-resistant MFA for vendors with privileged access.

Publish an exception register with owners and expiration dates.

Run a tabletop exercise against recovery abuse.

The tabletop should be blunt:

An attacker has convinced the help desk to remove MFA from a finance administrator. What alerts fire? Who knows? How fast can we revoke sessions, disable OAuth grants, suspend the account, preserve evidence, and determine blast radius?

If that exercise feels uncomfortable, good.

That is the point.

Policy Baseline Language

Here is practical language to adapt:

Account recovery, authenticator reset, passkey registration, passkey removal, device replacement, temporary access issuance, OAuth consent approval, and session revocation are security-sensitive identity lifecycle events. These events must be governed by risk tier, verified using approved proofing methods, logged centrally, monitored for abuse, and reviewed for privileged or high-impact users. Recovery processes must not allow access to be restored through a weaker assurance path than the access being recovered without documented, time-bound risk acceptance.

That last sentence is the core principle.

Do not let recovery be weaker than login.

Where Compliance and Risk Teams Fit

Compliance teams should pay attention because recovery-plane risk creates evidence problems.

When auditors ask whether privileged access is controlled, the answer cannot stop at:

We require MFA.

The next questions are predictable:

  • How is MFA reset?
  • Who can approve a reset?
  • Are approvals logged?
  • Can support staff bypass the policy?
  • Are exceptions time-bound?
  • Are recovery events reviewed?
  • Are vendor recovery paths included?
  • Are OAuth grants reviewed?
  • Can sessions be revoked?

Those are not theoretical questions.

They are control design questions.

They are also incident response questions.

A mature identity program should be able to produce evidence for recovery events the same way it produces evidence for access reviews, privileged access approvals, and policy exceptions.

The Bottom Line

Passkeys are a real improvement.

Phishing-resistant authentication is worth doing.

Hardware keys for privileged users are worth the operational effort.

Conditional access, MFA cleanup, passkey rollout roadmaps, and fallback reduction all matter.

But the next identity fight is not only at login.

It is in recovery.

It is in help desk workflows.

It is in device replacement.

It is in OAuth consent.

It is in session persistence.

It is in vendor support paths.

It is in the exception process.

Attackers follow pressure. As the password attack surface shrinks, the recovery attack surface becomes more valuable.

So build for that reality now.

Measure recovery-plane risk.

Score recovery paths by proof strength, social-engineering exposure, exception frequency, persistence, visibility, ownership, and blast radius.

Harden the workflows that can restore high-impact access.

Give the help desk better procedures and the authority to use them.

Govern OAuth and sessions as part of identity, not as unrelated SaaS hygiene.

Treat vendor access and support recovery as part of the enterprise control plane.

The goal is not to make recovery impossible.

People will lose devices. Executives will travel. Hardware will fail. Business will need continuity.

The goal is to make recovery trustworthy.

Because in a passwordless world, the attacker does not need your password if they can become your recovery event.

More Information and Assistance

At MicroSolved, Inc., we help organizations move from security intentions to operational reality. If you are rolling out passkeys, hardening MFA, modernizing IAM, or trying to understand whether your recovery plane is becoming your weakest identity control, we can help.

MicroSolved can assist with:

  • Identity architecture assessments
  • Passkey and phishing-resistant authentication roadmaps
  • Account recovery and help desk workflow hardening
  • OAuth grant and SaaS identity reviews
  • Privileged access and vendor access risk reduction
  • Identity logging and SIEM use-case development
  • Tabletop exercises and adversarial simulations focused on recovery abuse
  • Executive dashboards for identity risk reduction

Contact MicroSolved at +1.614.351.1237 or info@microsolved.com.

Relax. We’re on watch.

 

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Passkeys, Not Passcodes: A Practical Enterprise Guide to Moving Beyond Passwords

Posted on by
Reply

There is a small terminology problem in the identity world right now, and it matters more than it looks.

A passcode or PIN is usually a local unlock secret. It unlocks a phone, a laptop, Windows Hello, an authenticator app, or a hardware security key. A passkey is different. A passkey is the standards-based replacement for passwords, built on FIDO2/WebAuthn. The user unlocks the passkey locally with a fingerprint, face scan, device PIN, pattern, or security key, but the website or application receives cryptographic proof — not a reusable password. FIDO defines passkeys as FIDO authentication credentials based on FIDO standards, tied to an account, and used with the same process the user already uses to unlock a device. 

That distinction is not pedantry. It is the difference between a local unlock method and a replacement for one of the most abused controls in the history of computing.

Passwords have had a long run. They also have had a long list of failures: reuse, phishing, spraying, stuffing, database theft, weak reset workflows, help desk abuse, and user fatigue. We have spent decades trying to compensate for those failures with complexity rules, expiration schedules, password managers, SMS codes, mobile push prompts, training campaigns, and detective controls.

Some of those helped. Some just moved the pain around.

Passkeys change the model.

They are not merely “better passwords.” They are a different authentication architecture.

A hacker is seated in front of a computer fingers poised over the keyboard They are ready to break into a system and gain access to sensitive information 6466041

The Problem: Passwords Are Shared Secrets in a World Built to Steal Them

A password proves identity by revealing a secret. That is the root of the problem.

When users type passwords into websites, there is always a chance they will type them into the wrong website. When companies store password material, there is always a chance attackers will steal it. When people reuse passwords, a breach in one place becomes an entry point somewhere else. When attackers automate guessing, weak and reused passwords become an industrial-scale attack surface.

Microsoft’s 2025 Digital Defense Report says 97% of identity attacks were password spray attacks, which is a pretty direct reminder that attackers still love the boring stuff that works. Verizon’s 2026 DBIR highlights that breaches continue to involve the human element, phishing, stolen credentials, ransomware, and software vulnerability exploitation — and also reports that 31% of breaches now start with software vulnerabilities, beating stolen passwords as the top initial entry point in that dataset. 

That combination matters. It tells us two things at once.

First, passwords remain a major identity risk. Second, replacing passwords is not the whole security program.

That is the right mental model for passkeys: they are a major improvement in authentication, not a magic shield around the enterprise.

What a Passkey Does Differently

A password is something the user knows and types.

A passkey is a cryptographic credential. When the user registers a passkey for a site or application, the device creates a unique public/private key pair. The private key stays with the authenticator or passkey provider. The public key is registered with the service. At sign-in, the service sends a fresh challenge. The authenticator signs the challenge with the private key. The service verifies the response with the public key.

No reusable password crosses the wire.

No password database needs to be protected in the same way.

No user has to remember whether the login page looks slightly wrong.

The protocol carries a lot of the security burden that we previously dumped on the user.

That is the real breakthrough.

FIDO describes passkeys as password replacement technology that uses cryptographic key pairs for phishing-resistant sign-in. It also notes that passkeys can be synced across devices or bound to a particular device. Microsoft Entra describes the same basic model: the private key is stored on the user device, the public key is stored with the app or website, and both unique keys are needed to sign in. 

The user experience is simple: unlock the device.

The security model is not simple — and that is a good thing.

The Plain-English Explanation for Users

For users, do not start with asymmetric cryptography. Start with what changes for them.

“A passkey is a safer way to sign in without typing a password. Instead of remembering and entering a password, you unlock your phone, laptop, or security key. The website gets proof that your device has the right key, but it never gets a password. That means there is no password for you to forget, reuse, mistype, or accidentally give to a fake website.”

That is enough for most end users.

Then answer the question they are really asking:

Does the website get my fingerprint or face scan?

No. The biometric check happens locally. FIDO states that biometric information and processing remain on the device and are not sent to a remote server; the server receives assurance that the biometric check succeeded. 

Is my device PIN now my corporate password?

No. NIST distinguishes centrally verified passwords from local activation secrets. A device PIN or unlock secret used locally to access an authenticator is not sent to the verifier the way a website password is. 

That is an important communication point. Users often hear “PIN” and think “weak password.” In a passkey model, the PIN is usually a local unlock mechanism protecting the private key, not the secret being verified by the website.

Why Passkeys Reduce Risk

Passkeys reduce several common attack paths:

Risk How passkeys help
Phishing The user does not type a reusable password, and the passkey is scoped to the legitimate relying party. A fake site should not be able to obtain a valid assertion for the real site.
Credential stuffing There is no shared password to reuse from another breach.
Password spraying Attackers cannot guess a password that is no longer accepted for that workflow.
Password database theft The service stores public key material rather than reusable passwords.
Weak MFA interception Passkeys can replace password plus SMS OTP, password plus TOTP, or password plus push approval in many use cases.
User fatigue Users approve sign-in with a familiar local unlock gesture rather than remembering and typing complex passwords.

FIDO states that passkeys are resistant to phishing, designed without shared secrets, and can replace legacy MFA flows such as password plus SMS OTP. FIDO also notes that common second factors such as OTPs and phone approvals remain phishable. NIST is similarly direct: passwords are not phishing-resistant, and authenticator outputs manually entered into an impostor verifier — such as OTP-style flows — are not considered phishing-resistant because they can be relayed. 

That last point is key.

A lot of organizations believe they solved phishing because they deployed MFA. In many cases, they deployed phishable MFA. That is better than passwords alone, but it is not the same as phishing-resistant authentication.

What Actually Happens Under the Hood

There are two ceremonies that matter: registration and authentication.

Registration

When a user creates a passkey:

  1. The user starts registration through an approved enrollment path.
  2. The relying party sends registration options to the browser or application.
  3. The browser or app calls the WebAuthn API.
  4. The authenticator creates a new public/private key pair scoped to that relying party.
  5. The private key stays in the authenticator or passkey provider.
  6. The public key, credential ID, user handle, flags, and optional attestation data are returned.
  7. The relying party stores the credential record with the user account.

W3C WebAuthn describes a model where the public key is returned to the relying party during registration, while the private key is bound to the authenticator and is expected not to be exposed. It also describes the credential record that the relying party stores for later authentication ceremonies. 

Authentication

When the user signs in later:

  1. The relying party generates a fresh random challenge.
  2. The browser or app sends the challenge and relying-party information to the authenticator.
  3. The authenticator checks whether it has a credential scoped to that relying party.
  4. The user performs local verification, such as biometric, PIN, device unlock, or security-key touch.
  5. The authenticator signs the challenge and relevant context.
  6. The relying party verifies the signature using the stored public key.
  7. The relying party checks the challenge, origin, RP ID, user verification flags, and policy requirements before granting access.

WebAuthn depends on randomized challenges to prevent replay attacks, and the relying party must generate those challenges in a trusted environment and verify that the returned challenge matches. 

This is why passkeys are different from passwords. A password login proves identity by disclosing a shared secret. A passkey login proves possession of a private key without disclosing it.

Why Phishing Resistance Works

The important concept is origin binding or relying party binding.

A passkey created for one legitimate service is not supposed to work for an attacker’s lookalike domain. A fake site may fool the human eye, but it should not be able to get a valid passkey assertion for the real service’s relying party ID.

W3C WebAuthn notes that credentials are scoped to a specific relying party and that only that relying party, identified by its RP ID, can use the credential in authentication ceremonies. It also warns relying parties not to accept unexpected origins, because origin validation is an additional layer of protection. 

That is the practical security gain.

The protocol stops relying solely on user vigilance.

We should still train users. We should still harden browsers. We should still detect malicious domains. But the highest-value control is to prevent the stolen credential from existing in the first place.

User Presence vs. User Verification

Two terms get mixed together too often:

Concept Plain-English meaning Why it matters
User presence The user touched the key, approved the prompt, or was physically involved. Helps prove that authentication was not entirely silent.
User verification The authenticator locally verified the user with a PIN, biometric, or equivalent method. Provides stronger assurance that the right person, not merely the right device, approved the login.

WebAuthn authenticator data includes flags for User Present and User Verified. For enterprise deployments, user verification should be required for normal workforce access and especially for privileged access.

Do not settle for “the device was there” when the workflow needs “the authorized user unlocked the credential.”

Attestation: Knowing What Created the Key

Attestation answers a simple question:

What kind of authenticator created this credential, and do we trust that model for this use case?

For broad workforce adoption, strict attestation may not always be required. Many consumer passkey providers do not expose the same provenance details, and requiring attestation everywhere can create adoption friction.

For privileged users, administrators, financial approvers, developers, security staff, and high-risk workflows, attestation becomes much more important. In those cases, the organization may want to allow only approved hardware security keys, approved device-bound passkeys, or approved enterprise passkey providers.

Microsoft Entra allows attestation enforcement at the passkey profile level. When attestation is enabled, only device-bound passkeys are allowed and synced passkeys are excluded. 

That is the correct direction for high-risk access.

Use convenience where the risk allows it. Use hardware-backed assurance where the blast radius demands it.

Synced Passkeys vs. Device-Bound Passkeys

Not all passkeys carry the same operational risk.

Type What it means Good fit Risk notes
Synced passkey The credential can be synced across devices through a passkey provider, such as an OS/cloud keychain or password manager. Standard workforce, lower-risk SaaS, broad adoption, BYOD-friendly scenarios. Better usability and recovery, but introduces sync-fabric, sharing, restore, and account-recovery risks.
Device-bound passkey The private key remains tied to one device or authenticator. Admins, executives, finance, developers, security teams, regulated workflows. Stronger control and provenance, but higher support cost and lockout risk.
Hardware security key A roaming authenticator, often USB/NFC/BLE, with keys protected in dedicated hardware. Highest-risk users, break-glass accounts, privileged access, financial approvals. Requires inventory, backup keys, training, and lifecycle management.

NIST allows syncable authenticators in applications seeking up to AAL2, but AAL3 requires a phishing-resistant authenticator with a non-exportable key. NIST explicitly says syncable authenticators cannot be used at AAL3 because their private keys are inherently exportable. 

That gives us a clean enterprise rule:

Use synced passkeys where usability and broad risk reduction matter most. Use device-bound credentials or hardware security keys where privilege, regulation, or business impact requires stronger assurance.

The Big Deployment Mistake: Turning On Passkeys and Declaring Victory

The wrong strategy is simple:

“We enabled passkeys. We are passwordless now.”

No.

A passkey project is not just an IdP configuration change. It is an identity modernization project.

The common failures are predictable:

  1. Weak fallback methods remain enabled.
  2. Recovery workflows become the new attack path.
  3. Privileged users are treated the same as standard users.
  4. Legacy applications keep password paths alive.
  5. Enrollment is not monitored.
  6. Exceptions never expire.
  7. Help desk processes are not hardened.
  8. Service accounts are ignored.
  9. Token theft and session abuse are treated as unrelated problems.

Passkeys reduce credential compromise risk. They do not solve endpoint malware, stolen browser sessions, OAuth abuse, SaaS misconfiguration, vulnerable internet-facing systems, malicious insiders, or weak vendor access.

Identity security is a system. Passkeys are one of the strongest components we have, but they still have to be engineered into the system.

Enterprise Implementation Methodology

The enterprise goal should be stated plainly:

Move the organization from password-centric authentication to phishing-resistant authentication while reducing weak fallback methods, hardening recovery, and tiering controls by risk.

Phase 0: Define Scope, Risk Tiers, and Target State

Start with decisions, not tools.

Decide:

  • Which IdP or IdPs are authoritative?
  • Which users are highest risk?
  • Which applications can use SSO?
  • Which applications support native WebAuthn/FIDO2?
  • Which workflows require phishing-resistant authentication immediately?
  • Which users may use synced passkeys?
  • Which users must use device-bound passkeys or hardware keys?
  • What fallback methods are acceptable during transition?
  • What is the exception process?
  • What is the recovery process?
  • What logs must be collected?
  • What metrics will leadership see?

Then build a risk-tier model.

Tier Examples Recommended approach
Tier 0 / highest privilege Global admins, domain admins, IdP admins, cloud admins, PAM admins, break-glass accounts. Two approved device-bound credentials or hardware security keys; attestation required where possible; no SMS, TOTP, or push fallback.
Tier 1 / high risk Executives, finance, HR, developers, help desk, security team, wire/ACH approvers. Device-bound preferred; synced allowed only with managed device and strong conditional access; hardened recovery.
Tier 2 / standard workforce General staff using SaaS and productivity apps. Synced or platform passkeys allowed; user verification required; backup method required before enforcement.
Tier 3 / frontline/shared device Kiosks, shared workstations, shift users. Hardware keys, badge-integrated FIDO, named-user access, or carefully designed shared-device strategy.
Third parties Vendors, contractors, MSPs. Require phishing-resistant MFA for privileged or sensitive access; enforce federation and conditional access.
Service accounts Non-human accounts, integrations, automations. Do not use passkeys. Use managed identities, workload identity federation, certificates, scoped tokens, vaulting, and rotation.

The biggest lesson: do not flatten the organization. A payroll clerk, a warehouse kiosk user, a cloud administrator, and a break-glass account do not carry the same risk.

Phase 1: Inventory Authentication Surfaces

Before enforcement, inventory where authentication actually happens.

Minimum fields should include:

  • Application or system name
  • Business owner
  • Authentication path
  • IdP integration
  • Current MFA methods
  • WebAuthn/FIDO2 support
  • SSO capability
  • User population
  • Privilege level
  • Recovery path
  • Logging source
  • Legacy protocols
  • Exception owner
  • Exception expiration date

Pay special attention to legacy authentication. Basic auth, old VPN flows, app passwords, IMAP/POP/SMTP AUTH, ROPC, local admin portals, unmanaged SaaS accounts, and shadow IdPs can quietly preserve the password attack surface after leadership thinks the problem is fixed.

This is where many “passwordless” projects fail. The modern front door gets hardened, but the side doors stay open.

Phase 2: Choose the Enterprise Passkey Architecture

Most organizations will deploy passkeys through their primary identity provider.

Microsoft Entra ID

Microsoft Entra supports passkeys using FIDO2/WebAuthn concepts and describes both device-bound passkeys and synced passkeys. Microsoft also recommends FIDO2 security keys for highly regulated industries or users with elevated privileges, while describing synced passkeys as a convenient, lower-cost option for most users outside highly regulated or sensitive contexts. 

A good Entra pattern usually includes:

  • Separate passkey profiles for standard users and privileged users.
  • Device-bound/security-key requirements for administrators.
  • Attestation enforcement for high-risk profiles where feasible.
  • Conditional Access authentication strengths.
  • Managed device requirements for sensitive access.
  • At least two authenticators enrolled before enforcement.
  • Removal of SMS, voice, TOTP, and push fallback for privileged users.
  • Logging of registration, removal, sign-in, recovery, and policy changes.

Google Workspace

Google Workspace administrators can allow users to skip password sign-in challenges and use a passkey covering first and second-factor authentication. Google also notes that administrators can restrict passkeys to hardware security keys only and can monitor passkey enrollment and usage through the security investigation tool. 

A good Google Workspace pattern usually includes:

  • Enabling skip-password capability by organizational unit.
  • Restricting hardware security keys for privileged OUs where required.
  • Confirming users have enrolled backup methods before enforcement.
  • Monitoring passkey enrollment and successful passkey sign-ins.
  • Removing weaker fallback for high-risk users.
  • Aligning device management and account recovery policies.

Okta

Okta describes Passkeys/FIDO2 WebAuthn and Okta FastPass as phishing-resistant authenticators and supports app sign-in policies that require phishing-resistant possession factors. Okta also logs phishing-resistant authentication events, including declined phishing attempts. 

A good Okta pattern usually includes:

  • Enabling Passkeys/FIDO2 WebAuthn and/or Okta FastPass.
  • Creating authenticator enrollment policies by risk group.
  • Requiring phishing-resistant authenticators for sensitive apps.
  • Using app sign-in policies rather than broad, one-size-fits-all rules.
  • Integrating managed device posture where available.
  • Alerting on enrollment changes, recovery activity, and phishing-resistant authentication failures.

Phase 3: Pilot With the People Who Can Break the Program Safely

Pilot with IT, security, identity administrators, help desk, a small executive group, finance users, mobile users, and a few users who are likely to have edge cases.

Test:

  • New device enrollment
  • Lost device recovery
  • Hardware key enrollment
  • Mobile sign-in
  • Cross-device sign-in
  • VPN access
  • SaaS access
  • Admin portal access
  • Password reset flows
  • Help desk identity verification
  • Offboarding
  • Break-glass access
  • Legacy application behavior
  • Logging and SIEM correlation
  • User communications

The pilot is not just about whether passkeys work. It is about whether the organization can support them without creating a weaker recovery path than the password path it replaced.

Phase 4: Roll Out by Risk, Not by Org Chart

The rollout sequence should be boring and deliberate:

  1. Identity administrators and security team.
  2. Cloud administrators and PAM administrators.
  3. Break-glass accounts.
  4. Finance, payroll, HR, executives, and developers.
  5. Help desk and support teams.
  6. General workforce.
  7. Third parties with privileged or sensitive access.
  8. Remaining business applications through SSO modernization.

Do not start with “everyone by Friday.” Start with the users whose compromise would hurt the most and whose workflows you can monitor carefully.

Phase 5: Harden Recovery, Lifecycle, and Monitoring

Attackers follow the path of least resistance.

If passkeys close the front door, attackers will look at recovery, registration, device replacement, and help desk exceptions.

Recovery controls should include:

  • Strong identity verification for authenticator reset.
  • Separate procedures for standard users and privileged users.
  • Two-person approval for privileged recovery.
  • Out-of-band callback using known-good contact information.
  • No recovery approval based solely on email access.
  • Logging and alerting for passkey addition, removal, reset, and recovery.
  • Time-bound temporary access.
  • Post-recovery review.
  • Executive reporting on recovery volume and exceptions.

NIST’s usability guidance explicitly calls out the need to provide users information about what to do if an authenticator is lost or stolen and to consider alternative authentication options for loss, damage, or availability issues. 

The enterprise interpretation is simple: do not enforce passkeys until recovery is engineered.

Policy Baseline Language

Here is a practical policy statement to adapt:

The organization will transition workforce authentication from password-centric methods to phishing-resistant authentication using passkeys based on FIDO2/WebAuthn. Standard users may use approved synced or device-bound passkeys. Privileged, administrative, financial, and other high-risk users must use approved device-bound passkeys or hardware security keys. Passwords, SMS OTP, voice OTP, email OTP, TOTP, and push approval may be used only as temporary transition or exception methods where explicitly risk-accepted. Account recovery, passkey registration, passkey removal, and fallback authentication are security-sensitive workflows and must be logged, monitored, and governed.

Minimum technical requirements:

Control Standard
User verification Required.
User presence Required where applicable.
Passkey count Minimum two approved authenticators per user before enforcement.
Admin authentication Device-bound FIDO2/security key; attestation preferred or required.
Standard workforce Synced or device-bound passkeys based on risk.
Shared accounts Prohibited where feasible; replace with named accounts and PAM.
Service accounts No passkeys; use workload identity or managed secrets.
Recovery Documented, verified, logged, and alert-generating.
Logging Registration, sign-in, failure, recovery, removal, device change, and admin changes.
Exceptions Time-bound, owner-assigned, and risk-accepted.

Enterprise Risk Register

Risk Probability Impact Mitigation
Weak fallback remains enabled High High Remove SMS/TOTP/push for admins first; enforce phishing-resistant authentication strength; maintain an exception register.
Help desk becomes the new attack path High High Require strong identity verification, callback procedures, two-person approval for privileged recovery, and recovery-event alerting.
Users lose access due to device loss Medium Medium Require two authenticators; issue backup keys for high-risk users; document recovery.
Synced passkeys are restored or shared to unmanaged devices Medium Medium/High Use managed profiles, MDM, device compliance, passkey provider controls, and device-bound keys for high-risk groups.
Legacy apps block enforcement High Medium/High Inventory apps, front with SSO, modernize authentication, isolate, or risk-accept temporarily.
Token theft bypasses authentication strength Medium High Use device compliance, session protection, continuous access evaluation, EDR, browser/session controls, and rapid revocation.
Attestation gaps create uncertainty Medium Medium Require attestation for privileged groups; use approved authenticator lists; allow non-attested only for lower-risk users.
BYOD creates inconsistent security posture Medium Medium Separate standard and high-risk use cases; require compliant devices for sensitive access.
Break-glass accounts remain password-only Medium High Use hardware keys, strong vaulting, monitoring, emergency access review, and tested procedures.
Users misunderstand biometrics Medium Low/Medium Explain that biometrics stay local and are not sent to the website, application, or employer.

A Practical 12-Month Roadmap

0–30 Days: Planning and Readiness

  • Define passkey policy and risk tiers.
  • Inventory applications and authentication paths.
  • Identify privileged and sensitive user groups.
  • Decide approved authenticator types.
  • Configure pilot policies in the IdP.
  • Draft help desk and recovery runbooks.
  • Prepare user communications.
  • Procure hardware security keys for administrators and high-risk users.

31–60 Days: Pilot

  • Enroll IT, security, and admin pilot users first.
  • Require at least two authenticators per pilot user.
  • Validate registration, sign-in, recovery, mobile, VPN, and legacy app behavior.
  • Run phishing-resistant authentication tests.
  • Tune SIEM alerts and help desk workflows.
  • Document blockers and exceptions.

61–90 Days: Privileged Enforcement

  • Require device-bound passkeys or hardware security keys for administrators.
  • Disable SMS, TOTP, and push fallback for admin accounts.
  • Require phishing-resistant authentication for IdP admin portals, cloud consoles, PAM, EDR, backup consoles, VPN admin access, finance approvals, and security tools.
  • Review break-glass accounts.
  • Begin executive and finance enrollment.

91–180 Days: Workforce Expansion

  • Enable passkey sign-in for all users.
  • Require two authenticators before enforcement.
  • Retire weak MFA for sensitive applications.
  • Move remaining password-based applications behind SSO where possible.
  • Track adoption metrics weekly.
  • Publish exceptions to leadership and security governance.

181–365 Days: Password Reduction and Optimization

  • Reduce password prompts.
  • Remove legacy authentication protocols.
  • Decommission app passwords and basic auth.
  • Expand phishing-resistant authentication to third parties.
  • Review account recovery events quarterly.
  • Run tabletop exercises and red-team simulations against recovery and fallback paths.
  • Add passkey support requirements to procurement and vendor risk management.

Metrics Leadership Should See

A passkey program needs measurement. Otherwise it becomes another “we turned it on” control.

Track:

  • Percent of users with at least one passkey.
  • Percent of users with at least two authenticators.
  • Percent of privileged users using device-bound credentials.
  • Password sign-ins by application.
  • Passkey sign-ins by application.
  • Failed passkey attempts.
  • Recovery events.
  • Passkey removals.
  • New authenticator registrations.
  • Weak MFA usage.
  • Exceptions by owner and expiration date.
  • Legacy authentication attempts.
  • High-risk users without compliant authentication.
  • Third-party users without phishing-resistant authentication.
  • Admin sign-ins that did not meet policy.

The dashboard should not be complicated. It should answer one question:

Are we actually reducing credential risk, or did we just add a new option?

What Passkeys Do Not Solve

This is the part vendors sometimes skip.

Passkeys do not fix:

  • Compromised endpoints.
  • Stolen session tokens.
  • Malware running in the user context.
  • OAuth consent abuse.
  • Overprivileged SaaS integrations.
  • Weak device management.
  • Poor logging.
  • Vulnerable internet-facing systems.
  • Help desk social engineering.
  • Weak account recovery.
  • Shared accounts.
  • Unmanaged vendor access.
  • Excessive privilege.
  • Poor offboarding.
  • Business process fraud.

That is not a criticism of passkeys. It is a reminder that identity security is layered.

Passkeys make it much harder to steal and replay credentials. That is a huge win. But attackers adapt. Once the password is gone, they will move toward recovery abuse, token theft, endpoint compromise, malicious OAuth grants, social engineering of support teams, and exploitation of systems that sit outside the modern IdP.

So build the rest of the program.

The Bottom Line

Passkeys are a major improvement because they remove the reusable password from the authentication ceremony.

They replace a shared secret with public-key cryptography, origin binding, local user verification, and challenge-response authentication. That is a structural improvement, not a cosmetic one.

But the right enterprise approach is not “turn on passkeys for everyone and declare victory.”

The right approach is:

  1. Use passkeys for broad workforce passwordless authentication.
  2. Use device-bound passkeys or hardware security keys for privileged and regulated users.
  3. Remove weak fallback methods.
  4. Harden recovery and lifecycle management.
  5. Measure adoption and residual risk.
  6. Tie identity hardening to endpoint security, session protection, vulnerability management, vendor access, and incident response.

Passkeys should be part of a rational identity security program.

Not hype.

Not magic.

Just better engineering.

More Information and Assistance

At MicroSolved, Inc., we help organizations move from security intentions to operational reality. Passkeys are a strong control, but the success of a passkey program depends on architecture, policy, implementation sequencing, recovery design, monitoring, and user communication.

MicroSolved can help your organization:

  • Assess your current authentication architecture.
  • Inventory password, MFA, SSO, and legacy authentication paths.
  • Build a passkey deployment roadmap.
  • Define risk tiers for standard, privileged, executive, financial, developer, and third-party users.
  • Design policy for synced passkeys, device-bound passkeys, and hardware security keys.
  • Harden account recovery and help desk workflows.
  • Configure SIEM monitoring and identity alerts.
  • Test fallback paths through tabletop exercises and adversarial simulations.
  • Build executive dashboards for identity risk reduction.
  • Integrate phishing-resistant authentication into broader security governance.

If you are planning a passkey rollout, struggling with legacy authentication, or unsure how to reduce password risk without creating new recovery risk, reach out to MicroSolved, Inc. We would be glad to help you think it through.

Contact MicroSolved at +1.614.351.1237 or info@microsolved.com.

Relax. We’re on watch.

References

  • FIDO Alliance — Passkeys and passwordless authentication. 
  • W3C — Web Authentication: An API for accessing Public Key Credentials, Level 3. 
  • NIST SP 800-63B — Authentication and Lifecycle Management. 
  • Microsoft Learn — Passkeys/FIDO2 authentication in Microsoft Entra ID. 
  • Google Workspace Admin Help — Allow users to skip passwords at sign-in. 
  • Okta Help — Phishing-resistant authentication. 
  • Microsoft Digital Defense Report 2025. 
  • Verizon 2026 Data Breach Investigations Report. 

AI tools were used as a research assistant for this content, but human moderation and writing are also included. Images are AI-generated.

Rational Security in the AI Era: How Attackers Are Evolving and How We Must Respond

Posted on by
Reply

The weaponization of artificial intelligence by cybercriminals and nation-state actors has crossed a critical inflection point. We no longer live in a world where we can rely solely on traditional perimeters; the threat landscape has fundamentally shifted into what we might call “Extremistan,” where the speed and scale of attacks demand a completely new level of resilience.

SadKitty

At MicroSolved, our mission is to provide rational cybersecurity for an irrational world. To do that effectively, we must look unflinchingly at the data.

The Problem and the Metrics

The numbers tell a stark story of industrialization at machine speed. According to recent threat reports, AI-enabled adversaries increased their attack volume by 89% year-over-year. More concerning is the velocity: the average eCrime breakout time has collapsed to just 29 minutes, with the fastest recorded intrusion moving from initial access to lateral movement in a staggering 27 seconds.

The financial impact is equally severe. The FBI IC3 recorded over 22,000 AI-related complaints with adjusted losses exceeding $893 million in 2025 alone, including tens of millions lost to AI-enabled Business Email Compromise (BEC). AI is accelerating attack speeds by 4x, making human-speed incident response no longer viable.

Continue reading →

Stop Patching Solely by Severity. Start Patching by Exploitation.

Posted on by

If your patch SLAs are still solely driven by CVSS base score, i.e., Critical in 7 days, High in 30, Medium “when we get to it”; you are optimizing for the wrong variable. The math stopped working a while ago, 2025 made it obvious, and 2026 is making it painful.

Roughly 48,000 CVEs were published in 2025, up about 20% from ~40,000 in 2024. So far in 2026, there are over 15,000 (as of mid-May), and we may well see well over the number from 2025 by the end of the year. Around 39% of those were rated Critical or High in 2025, and about 45% of 2026 CVEs are.

Worse, severity is a poor predictor of what is actually attacked. Only ~2% of published CVEs are ever exploited in the wild (768 of ~40k in 2024). CISA’s KEV catalog covers ~0.5% of all CVEs. So a severity-only program spends most of its effort on vulnerabilities no attacker will ever touch, while the handful that matter sit somewhere in the queue ranked by a number that doesn’t correlate with exploitation.

Continue reading →

The Evidence Supply Chain: How CISOs Build a Cyber Materiality Data Plane Before the Incident

Posted on by
Reply

A ransomware incident does not wait for the organization chart to catch up.

At 8:17 a.m., the SOC sees encryption activity on a file server. At 8:31, operations says the plant is still running. At 8:44, finance says revenue recognition may be affected if order processing stays down past noon. At 9:02, legal asks whether customer data was accessed. At 9:18, the forensic team says it is too early to tell. At 9:23, a vendor says the outage may have started in their environment. At 9:41, communications asks whether they should prepare a holding statement.

By hour two, everyone is working hard.

But they are not necessarily working from the same reality.

That is the problem.

Cyber materiality is often discussed as a decision problem. When does a cyber event become a board-level business event? When does it become reportable? When does it become material to investors, customers, regulators, lenders, or strategic partners?

Those are important questions. Public companies, for example, must disclose material cybersecurity incidents on Form 8-K within four business days after determining materiality, including the material aspects of the incident’s nature, scope, timing, and impact or reasonably likely impact.

But underneath that decision sits a deeper problem:

Continue reading →

Cyber Materiality Engineering: How CISOs Pre-Decide When Risk Becomes a Board Event

Posted on by
Reply

A ransomware incident does not stay technical for very long.

For about the first fifteen minutes, it may look like a security operations problem. A strange alert. A locked server. A suspicious authentication chain. A vendor portal behaving badly. A handful of systems no longer responding the way they should.

Then the blast radius starts to widen.

Operations wants to know whether they can keep running. Finance wants to know whether revenue recognition, cash movement, reserves, or forecasts are exposed. Legal wants to know whether notification clocks have started. The CEO wants to know what can be said, to whom, and when. The board wants to know whether this is “material.” Investors may eventually ask the same thing, only with less patience and more lawyers.

This is where many organizations discover that their cyber incident response plan is not really an enterprise decision plan. It tells people who to call. It tells the SOC how to preserve evidence. It may even have a communications tree and a sample press statement.

But it often does not answer the question that matters most in the first few hours:

Continue reading →

AI Agents Are Already Working for You. Who’s Managing Them?

Posted on by
Reply

AI Agents Are Not Applications. They Are Digital Workers.

Most organizations are adopting AI agents faster than they are learning how to govern them.

That is the problem.

A chatbot that answers questions is one thing. An AI agent that can access business data, use tools, trigger workflows, generate artifacts, make recommendations, or alter enterprise state is something else entirely.

At that point, the organization is no longer just deploying software.

It is introducing a new kind of operational actor.

That actor needs identity.

It needs boundaries.

It needs oversight.

It needs evidence.

It needs a human owner.

It needs a kill switch.

In other words, AI agents must be managed more like digital workers than ordinary applications.

AIAgentBanner

Continue reading →

Why My AI Agents Needed CaneCorso as a Security Control Plane

Posted on by
Reply

AI agents are powerful because they can read, reason, summarize, decide, and act across a wide range of information sources.

That is also what makes them dangerous.

The more useful an agent becomes, the more likely it is to consume data I do not fully trust. Emails. Newsletters. RSS feeds. API responses. Documents sent as attachments. Social media. YouTube transcripts. Scraped search results. Web pages. Translated content. Random bits of text pulled from places where I do not control the author, the formatting, the intent, or the payload.

That is a very different security model than the one most of us are used to.

In traditional applications, we spend a lot of time separating code from data, users from administrators, trusted networks from untrusted networks, and internal systems from the internet. With LLMs and agents, all of those boundaries start to blur. Instructions, context, content, and intent all arrive in the same stream. The model has to reason over that stream, and the agent has to decide what to do with the result.

That is exactly why I wanted a security control plane in front of my own AI agents.

For me, that control plane became CaneCorso™.

CaneCorsoAI

Continue reading →

Cyber Risk Is Enterprise Value Risk : A Practical Portfolio Approach for VC and PE Firms

Posted on by
Reply

For venture capital and private equity executives, cyber security is no longer just an IT issue. It is a valuation issue, a governance issue, a revenue issue, and a portfolio resilience issue.

GenSec

There was a time when cyber security could be treated as a technical matter.

It lived with the IT team. It showed up in diligence as a paragraph buried deep in a report. It became important only when a customer asked a hard question, a regulator came knocking, or something on the network caught fire.

That time is over.

For venture capital and private equity firms, cyber risk has become enterprise value risk. It affects valuation. It affects revenue quality. It affects debt, insurance, customer trust, regulatory posture, exit readiness, and the ability of management teams to execute without being pulled into avoidable chaos.

More importantly, cyber risk is no longer limited to the portfolio company.

The investment firm itself is a high-value target.

Deal flow, confidential financials, legal strategy, investment committee material, banking relationships, limited partner communications, M&A plans, board materials, and executive correspondence all create a concentration of sensitive information. Attackers understand this. So do regulators, insurers, strategic buyers, enterprise customers, and increasingly, boards.

The uncomfortable truth is this:

Many investment firms still manage cyber risk as a fragmented collection of one-off assessments, inconsistent vendor reports, annual questionnaires, and “we’ll fix it after close” assumptions.

That approach does not scale. It does not give partners a clear view of exposure. It does not give operating teams a consistent way to prioritize improvement. And it certainly does not create the kind of defensible evidence that boards, buyers, customers, and limited partners expect when the questions get serious.

MicroSolved’s value proposition for VC and PE firms is simple:

Help reduce cyber risk, protect enterprise value, and improve portfolio resilience through practical, expert-led security assurance that scales from the fund to the portfolio.

That sounds like a mouthful, so let’s unpack it.

Continue reading →