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

Posted on June 10, 2026 by Brent Huston

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:

The user starts registration through an approved enrollment path.
The relying party sends registration options to the browser or application.
The browser or app calls the WebAuthn API.
The authenticator creates a new public/private key pair scoped to that relying party.
The private key stays in the authenticator or passkey provider.
The public key, credential ID, user handle, flags, and optional attestation data are returned.
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:

The relying party generates a fresh random challenge.
The browser or app sends the challenge and relying-party information to the authenticator.
The authenticator checks whether it has a credential scoped to that relying party.
The user performs local verification, such as biometric, PIN, device unlock, or security-key touch.
The authenticator signs the challenge and relevant context.
The relying party verifies the signature using the stored public key.
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:

Weak fallback methods remain enabled.
Recovery workflows become the new attack path.
Privileged users are treated the same as standard users.
Legacy applications keep password paths alive.
Enrollment is not monitored.
Exceptions never expire.
Help desk processes are not hardened.
Service accounts are ignored.
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:

Identity administrators and security team.
Cloud administrators and PAM administrators.
Break-glass accounts.
Finance, payroll, HR, executives, and developers.
Help desk and support teams.
General workforce.
Third parties with privileged or sensitive access.
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:

Use passkeys for broad workforce passwordless authentication.
Use device-bound passkeys or hardware security keys for privileged and regulated users.
Remove weak fallback methods.
Harden recovery and lifecycle management.
Measure adoption and residual risk.
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 June 3, 2026 by Brent Huston

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 →

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

Posted on May 26, 2026 by Brent Huston

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 →

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

Posted on May 11, 2026 by Brent Huston

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.

Continue reading →

Rethinking Account Lockouts: Why 15 Minutes Isn’t a Strategy

Posted on April 6, 2026 by Brent Huston

There’s a moment in almost every security program where someone asks a deceptively simple question:

“Is 15 minutes a standard account lockout duration?”

The short answer? No.
The more honest answer? It’s common—but often wrong for the environment it’s deployed in.

And I’ve seen more than a few organizations learn that the hard way.

3Errors

The Myth of the “Standard” Lockout

If you go looking for authoritative guidance—from Center for Internet Security, FFIEC, or CISA—you’ll notice something interesting:

They don’t tell you what number to use.

Instead, they consistently emphasize:

Risk-based decision making
Balancing usability and security
Detecting and responding to threats—not just blocking them

That’s not an accident. It’s an acknowledgment that static controls like lockouts are blunt instruments in a very dynamic threat landscape.

What We Actually See in the Real World

Across environments—financial services, healthcare, SaaS, manufacturing—the patterns are pretty consistent:

Setting	Typical Range
Failed attempts before lockout	3–10
Lockout duration	5–30 minutes
Most common default	10–15 minutes

So yes, 15 minutes sits comfortably in the middle.

But “common” and “effective” are not the same thing.

Where 15 Minutes Breaks Down

1. It Punishes Users More Than Attackers

A 15-minute lockout sounds reasonable—until you multiply it.

A clinician locked out mid-shift
A call center agent missing SLAs
A trader unable to access systems during market hours

Now multiply that by repeated lockouts from cached credentials, mobile devices, or service accounts.

You don’t just have a security control—you have an operational problem.

2. It Doesn’t Stop Modern Attacks

Attackers have evolved. Most environments haven’t.

Today’s common attack patterns:

Password spraying (low-and-slow, avoids thresholds)
Credential stuffing (valid credentials, no lockout triggered)

A longer lockout duration doesn’t meaningfully impact either.

If anything, it gives a false sense of security while the real attack path goes untouched.

What Actually Works: A Layered Approach

This is where the conversation needs to shift—from “what’s the right number?” to “what’s the right strategy?”

1. Lockouts Are Supporting Controls—Not Primary Defenses

If you’re relying on lockouts as your main protection, you’re already behind.

At a minimum, you should be pairing with:

MFA everywhere it’s technically feasible
Conditional access (device, location, behavior)
Authentication throttling and smart detection

2. Tune for Risk, Not Defaults

A more balanced configuration tends to look like:

5–10 failed attempts
5–10 minute lockout
Reset counter after a defined cooldown window

This reduces user friction while still slowing down brute-force attempts.

More importantly—it acknowledges that lockouts are a speed bump, not a wall.

3. Progressive Delays Beat Hard Lockouts

One of the most underutilized strategies is progressive delay:

Attempts 1–2 → no delay
Attempts 3–5 → 30–60 second delay
Continued attempts → increasing delay

This approach:

Degrades attacker efficiency
Preserves user productivity
Avoids helpdesk spikes

It’s a far more surgical control than a blanket 15-minute lockout.

4. Detection Over Punishment

Modern security programs don’t just block—they observe.

You should be:

Logging all failed authentication attempts
Alerting on patterns (spraying, geographic anomalies)
Correlating identity signals across systems

Lockouts should be one signal among many—not the primary response.

Implementing This in Active Directory

Let’s get practical.

In on-prem Active Directory, you’re working primarily with Group Policy.

Recommended Baseline

In your domain or fine-grained password policy:

Account lockout threshold: 5–10 attempts
Account lockout duration: 5–10 minutes
Reset account lockout counter after: 10–15 minutes

Where to Configure

Group Policy Management Console (GPMC)
- Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy

Advanced Considerations

Use Fine-Grained Password Policies (FGPP) for high-risk accounts (admins, service accounts)
Monitor Event IDs:
- 4625 (failed logon)
- 4740 (account locked out)
Feed logs into your SIEM for correlation and alerting

Implementing This in Microsoft 365

In Microsoft 365, the model shifts significantly.

You don’t directly control “lockout duration” in the same way—because the platform is already applying smart lockout behavior.

Smart Lockout (Azure AD / Entra ID)

Automatically tracks failed attempts
Uses adaptive thresholds
Differentiates between familiar and unfamiliar locations

What You Should Do Instead

1. Enable and Enforce MFA

Conditional Access → Require MFA for all users (with staged rollout if needed)

2. Configure Conditional Access Policies

Block legacy authentication
Require compliant devices
Apply geographic restrictions where appropriate

3. Monitor Identity Signals

Azure AD Sign-in logs
Risky sign-ins and users
Integration with Defender for Identity / Sentinel

4. Tune Smart Lockout (if needed)

Default threshold is typically sufficient
Adjust only if you have a strong operational reason

The Bottom Line

A 15-minute lockout isn’t wrong.

It’s just incomplete.

✔️ It’s common
❌ It’s not a standard
⚠️ It can create more operational pain than security value

The real shift is this:

Stop treating account lockouts as a primary control. Start treating them as part of a layered identity defense strategy.

Because in today’s environment, the goal isn’t just to block access.

It’s to understand it.

* 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.

Update on PromptDefense Suite and AI Security Research

Posted on March 23, 2026 by Brent Huston

Last week, I discussed why and some of how we built the new PromptDefense Suite.

This week, we are discussing the product’s future internally and how we might go to market. This is mainly due to two new capabilities we have built into the product.

The first is an API and workflow automation mechanism. This allows organizations to stand up a single instance of PromptDefense and then use it to protect multiple AI/agent workflows. The code no longer has to be embedded directly in the project; instead, all defensive capabilities and logging can be accessed via an API instance. The API is robust and supports API key restrictions that tie into a rules engine, so that different workflows can have different trust models and actions pre-assigned in an audit-friendly way.

Secondly, we have developed a licensing mechanism that covers protected workflows and skips the per-seat, per-token models that seemed too confusing for most firms looking for these kinds of tools. They told us they wanted a simpler licensing approach, and we developed a new licensing mechanism to make it easy, manageable, and auditable. Our testers have been calling it a win!

As we continue with the beta-testing process and lock down our decisions about where the product is going, the news that drove us to create it continues to flow in. More of our clients are working on agents and AI-integrated workflows, which require this level of protection. While we continue to develop PromptDefender, we are also working to develop and release extended frameworks for AI model, agent, and product management, along with policies, procedures, and vendor risk assessment tools for these frameworks, for our vCISO clients. We’re also busy researching ongoing compliance implementation for AI workflows and agents, and should have more on that shortly.

In the meantime, if you want to discuss AI or agent security, risk management, or other relevant topics, please reach out. We would love to talk with you and help align our modernization capabilities with your emerging needs. You can always email us at info@microsolved.com or call us at +1-614-351-1237.

As always, thanks for reading. Stay safe out there, and stay tuned for more updates.

From Alert Volume to Signal Yield: An Economic Framework for Measuring SOC Effectiveness

Posted on March 2, 2026 by Brent Huston

Six months after a major alert-reduction initiative, a SOC director proudly reports a 42% decrease in daily alerts. The dashboards look cleaner. The queue is shorter. Analysts are no longer drowning.

Leadership applauds the efficiency gains.

Then reality intervenes.

A lateral movement campaign goes undetected for weeks. Analyst burnout hasn’t meaningfully declined. The cost per incident response remains stubbornly flat. And when the board asks a simple question — “Are we more secure now?” — the answer becomes uncomfortable.

Because while alert volume decreased, risk exposure may not have.

This is the uncomfortable truth: alert volume is a throughput metric. It tells you how much work flows through the system. It does not tell you how much value the system produces.

If we want to mature security operations beyond operational tuning, we need to move from counting alerts to measuring signal yield. And to do that, we need to treat detection engineering not as a technical discipline — but as an economic system.

AppSec

The Core Problem: Alert Volume Is a Misleading Metric

At its core, an alert is three things:

A probabilistic signal.
A consumption of analyst time.
A capital allocation decision.

Every alert consumes finite investigative capacity. That capacity is a constrained resource. When you generate an alert, you are implicitly allocating analyst capital to investigate it.

And yet, most SOCs measure success by reducing the number of alerts generated.

The second-order consequence? You optimize for less work, not more value.

When organizations focus on alert reduction alone, they may unintentionally optimize for:

Lower detection sensitivity
Reduced telemetry coverage
Suppressed edge-case detection
Hidden risk accumulation

Alert reduction is not inherently wrong. But it exists on a tradeoff curve. Lower volume can mean higher efficiency — or it can mean blind spots.

The mistake is treating volume reduction as an unqualified win.

If alerts are investments of investigative time, then the right question isn’t “How many alerts do we have?”

It’s:

What is the return on investigative time (ROIT)?

That is the shift from operations to economics.

Introducing Signal Yield: A Pareto Model of Detection Value

In most mature SOCs, alert value follows a Pareto distribution.

Roughly 20% of alert types generate 80% of confirmed incidents.
A small subset of detections produce nearly all high-severity findings.
Entire alert families generate near-zero confirmed outcomes.

Yet we often treat every alert as operationally equivalent.

They are not.

To move forward, we introduce a new measurement model: Signal Yield.

1. Signal Yield Rate (SYR)

SYR = Confirmed Incidents / Total Alerts (per detection family)

This measures the percentage of alerts that produce validated findings.

A detection with a 12% SYR is fundamentally different from one with 0.3%.

2. High-Severity Yield

Critical incidents / Alert type

This isolates which detection logic produces material risk reduction — not just activity.

3. Signal-to-Time Ratio

Confirmed impact per analyst hour consumed.

This reframes alerts in terms of labor economics.

4. Marginal Yield

Additional confirmed incidents per incremental alert volume.

This helps determine where the yield curve flattens.

The Signal Yield Curve

Imagine a curve:

X-axis: Alert volume
Y-axis: Confirmed incident value

At first, as coverage expands, yield increases sharply. Then it begins to flatten. Eventually, additional alerts add minimal incremental value.

Most SOCs operate blindly on this curve.

Signal yield modeling reveals where that flattening begins — and where engineering effort should be concentrated.

This is not theoretical. It is portfolio optimization.

The Economic Layer: Cost Per Confirmed Incident

Operational metrics tell you activity.

Economic metrics tell you efficiency.

Consider:

Cost per Validated Incident (CVI)
Total SOC operating cost / Confirmed incidents

This introduces a critical reframing: security operations produce validated outcomes.

But CVI alone is incomplete. Not all incidents are equal.

So we introduce:

Weighted CVI
Total SOC operating cost / Severity-weighted incidents

Now the system reflects actual risk reduction.

At this point, detection engineering becomes capital allocation.

Each detection family resembles a financial asset:

Some generate consistent high returns.
Some generate noise.
Some consume disproportionate capital for negligible yield.

If a detection consumes 30% of investigative time but produces 2% of validated findings, it is an underperforming asset.

Yet many SOCs retain such detections indefinitely.

Not because they produce value — but because no one measures them economically.

The Detection Portfolio Matrix

To operationalize this, we introduce a 2×2 model:

	High Yield	Low Yield
High Volume	Core Assets	Noise Risk
Low Volume	Precision Signals	Monitoring Candidates

Core Assets

High-volume, high-yield detections. These are foundational. Optimize, maintain, and defend them.

Noise Risk

High-volume, low-yield detections. These are capital drains. Redesign or retire.

Precision Signals

Low-volume, high-yield detections. These are strategic. Stress test for blind spots and ensure telemetry quality.

Monitoring Candidates

Low-volume, low-yield. Watch for drift or evolving relevance.

This model forces discipline.

Before building a new detection, ask:

What detection cluster does this belong to?
What is its expected yield?
What is its expected investigation cost?
What is its marginal ROI?

Detection engineering becomes intentional investment, not reactive expansion.

Implementation: Transitioning from Volume to Yield

This transformation does not require new tooling. It requires new categorization and measurement discipline.

Step 1 – Categorize Detection Families

Group alerts by logical family (identity misuse, endpoint anomaly, privilege escalation, etc.). Avoid measuring at individual rule granularity — measure at strategic clusters.

Step 2 – Attach Investigation Cost

Estimate average analyst time per alert category. Even approximations create clarity.

Time is the true currency of the SOC.

Step 3 – Calculate Yield

For each family:

Signal Yield Rate
Severity-weighted yield
Time-adjusted yield

Step 4 – Plot the Yield Curve

Identify:

Where volume produces diminishing returns
Which families dominate investigative capacity
Where engineering effort should concentrate

Step 5 – Reallocate Engineering Investment

Focus on:

Improving high-impact detections
Eliminating flat-return clusters
Re-tuning threshold-heavy anomaly models
Investing in telemetry that increases high-yield signal density

This is not about eliminating alerts.

It is about increasing return per alert.

A Real-World Application Example

Consider a SOC performing yield analysis.

They discover:

Credential misuse detection: 18% yield
Endpoint anomaly detection: 0.4% yield
Endpoint anomaly consumes 40% of analyst time

Under a volume-centric model, anomaly detection appears productive because it generates activity.

Under a yield model, it is a capital drain.

The decision:

Re-engineer anomaly thresholds
Improve identity telemetry depth
Increase focus on high-yield credential signals

Six months later:

Confirmed incident discovery increases
Analyst workload becomes strategically focused
Weighted CVI decreases
Burnout declines

The SOC didn’t reduce alerts blindly.

It increased signal density.

Third-Order Consequences

When SOCs optimize for signal yield instead of alert volume, several systemic changes occur:

Board reporting becomes defensible.
You can quantify risk reduction efficiency.
Budget conversations mature.
Funding becomes tied to economic return, not fear narratives.
“Alert theater” declines.
Activity is no longer mistaken for effectiveness.
Detection quality compounds.
Engineering effort concentrates where marginal ROI is highest.

Over time, this shifts the SOC from reactive operations to disciplined capital allocation.

Security becomes measurable in economic terms.

And that changes everything.

The Larger Shift

We are entering an era where AI will dramatically expand alert generation capacity. Detection logic will become cheaper to create. Telemetry will grow.

If we continue to measure success by volume reduction alone, we will drown more efficiently.

Signal yield is the architectural evolution.

It creates a common language between:

SOC leaders
CISOs
Finance
Boards

And it elevates detection engineering from operational tuning to strategic asset management.

Alert reduction was Phase One.

Signal economics is Phase Two.

The SOC of the future will not be measured by how quiet it is.

It will be measured by how much validated risk reduction it produces per unit of capital consumed.

That is the metric that survives scrutiny.

And it is the metric worth building toward.

* 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.

The Hidden Cost of Compliance: Why “Checkbox Security” Fails Modern Organizations

Posted on February 9, 2026 by Brent Huston

In today’s threat landscape, simply “checking the boxes” isn’t enough. Organizations invest enormous time and money to satisfy regulatory frameworks like PCI DSS, HIPAA, ISO 27001, GDPR, and NIS2—but too often they stop there. The result? A false sense of cybersecurity readiness that leaves critical vulnerabilities unaddressed and attackers unchallenged.

Compliance should be a foundation—not a finish line. Let’s unpack why checkbox compliance consistently fails modern enterprises and how forward-looking security leaders can close the gap with truly risk-based strategies.

Compliance vs. Security: Two Sides of the Same Coin?

Compliance and security are related—but they are emphatically not the same thing.

Compliance is about adherence to external mandates, standards, and audits.
Security is about reducing risk, defending against threats, and protecting data, systems, and business continuity.

Expecting compliance alone to prevent breaches is like believing that owning a fire extinguisher will stop every fire. The checklists in PCI DSS, HIPAA, or ISO standards are minimum controls designed to reduce loss—not exhaustive defenses against every attacker tactic.

“Compliance is not security.” — Security thought leaders have said this many times, and it rings true as organizations equate audit success with risk reduction.

Checkbox Security: Why It Fails

A compliance mindset often devolves into a checkbox mentality—complete documentation, filled-in forms, and green lights from auditors. But this approach contains several fundamental flaws:

1. Compliance Standards Lag Behind Evolving Threats

Most regulatory frameworks are reactive, built around known threats and past incidents. Cyber threats evolve constantly; sticking strictly to compliance means protecting against yesterday’s risks, not today’s or tomorrow’s.

2. Checklists Lack Contextual Risk Prioritization

Compliance is binary—yes/no answers. But not all controls have equal impact. A firewall might be present (box ticked), yet the organization might ignore the most actively exploited vulnerabilities like unpatched software or phishing risk.

3. Audit Success Doesn’t Equal Real-World Security

Auditors assess documentation and evidence of controls; they rarely test adversarial resilience. A compliant organization can still suffer devastating breaches because compliance assessments aren’t adversarial and don’t simulate real attacks.

Real-World Proof: Breaches Despite Compliance

Arguments against checkbox compliance sound theoretical—until you look at real breaches. Examples of organizations meeting compliance requirements yet being breached are widespread:

PCI DSS Compliance Breaches

Despite strict PCI requirements for safeguarding cardholder data, many breached organizations were technically compliant at the time of compromise. Researchers even note that no fully compliant organization examined was breach-free, and compliance fines or gaps didn’t prevent attackers from exploiting weak links in implementation.

Healthcare Data Risks Despite HIPAA

Even with stringent HIPAA requirements, healthcare breaches are rampant. Reports show thousands of HIPAA violations and data exposures annually, demonstrating that merely having compliance frameworks doesn’t stop attackers.

The Hidden Costs of Compliance-Only Security

When organizations chase compliance without aligning to deeper risk strategy, the costs go far beyond audit efforts.

1. Opportunity Cost

Security teams spend incredible hours on documentation, standard operating procedure updates, and audit response—hours that could otherwise support vulnerability remediation, threat hunting, and continuous monitoring.

2. False Sense of Security

Executives and boards often equate compliance with safety. But compliance doesn’t guarantee resilience. That false confidence can delay investments in deeper controls until it’s too late.

3. Breach Fallout

When conformity fails, consequences extend far beyond compliance fines. Reputational damage, customer churn, supply chain impacts, and board-level accountability can dwarf regulatory penalties.

Beyond Checkboxes: What Modern Security Needs

To turn compliance from checkbox security into business-aligned risk reduction, organizations should consider the following advanced practices:

1. Continuous Risk Measurement

Shift from periodic compliance assessments to continuous risk evaluation tied to real business outcomes. Tools that quantify risk exposure in financial and operational terms help prioritize investments where they matter most.

2. Threat Modeling & Adversary Emulation

Map attacker tactics relevant to your business context, then test controls against them. Frameworks like MITRE ATT&CK can help organizations think like attackers, not auditors.

3. Metrics That Measure Security Effectiveness

Move away from compliance metrics (“% of controls implemented”) to outcome metrics (“time to detect/respond to threats,” “reduction in high-risk exposures,” etc.). These demonstrate real improvements versus checkbox completion.

4. Integration of Security and Compliance

Security leaders should leverage compliance requirements as part of broader risk strategy—not substitutes. GRC (Governance, Risk, and Compliance) platforms can tie compliance evidence to risk dashboards for a unified view.

How MicroSolved Can Help

At MicroSolved, we’ve seen these pitfalls firsthand. Organizations often approach compliance automation or external consultants expecting silver bullets—but without continuous risk measurement and business context, security controls still fall short.

MicroSolved’s approach focuses on:

Risk-based security program development
Ongoing threat modeling and adversary testing
Metrics and dashboards tied to business outcomes
Integration of compliance frameworks like PCI, HIPAA, ISO 27001 with enterprise risk strategies

If your team is struggling to move beyond checkbox compliance, we’re here to help align your cybersecurity program with real-world risk reduction—not just regulatory requirements.

➡️ Learn more about how MicroSolved can help bridge the gap between compliance and true security effectiveness.

Conclusion: Compliance Is the Floor, Not the Ceiling

Regulatory frameworks remain essential—they set the minimum expectations for protecting data and privacy. But in a world of rapidly evolving threats, compliance alone can’t be the endpoint of your cybersecurity efforts.

Checkbox security gives boards comfort, but attackers don’t check boxes—they exploit gaps.

Security leaders who integrate risk measurement, continuous validation, and business alignment into their compliance programs not only strengthen defenses—they elevate security into a source of competitive advantage.

* 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.

Defending Small Credit Unions in the Age of AI-Driven Synthetic Fraud

Posted on February 2, 2026 by Brent Huston

We’ve seen fraud evolve before. We’ve weathered phishing, credential stuffing, card skimming, and social engineering waves—but what’s coming next makes all of that look like amateur hour. According to Experian and recent security forecasting, we’re entering a new fraud era. One where AI-driven agents operate autonomously, build convincing synthetic identities at scale, and mount adaptive, shape-shifting attacks that traditional defenses can’t keep up with.

For small credit unions and community banks, this isn’t a hypothetical future—it’s an urgent call to action.

The Rise of Synthetic Realities

Criminals are early adopters of innovation. Always have been. But now, 80% of observed autonomous AI agent use in cyberattacks is originating from criminal groups. These aren’t script kiddies with GPT wrappers—these are fully autonomous fraud agents, built to execute entire attack chains from data harvesting to cash-out, all without human intervention.

They’re using the vast stores of breached personal data to forge synthetic identities that are indistinguishable from real customers. The result? Hyper-personalized phishing, credential takeovers, and fraudulent accounts that slip through onboarding and authentication checks like ghosts.

Worse yet, quantum computing is looming. And with it, the shift from “break encryption” to “harvest now, decrypt later” is already in motion. That means data stolen today—unencrypted or encrypted with current algorithms—could be compromised retroactively within a decade or less.

So what can small institutions do? You don’t have the budget of a multinational bank, but that doesn’t mean you’re defenseless.

Three Moves Every Credit Union Must Make Now

1. Harden Identity and Access Controls—Everywhere

This isn’t just about enforcing MFA anymore. It’s about enforcing phishing-resistant MFA. That means FIDO2, passkeys, hardware tokens—methods that don’t rely on SMS or email, which are easily phished or intercepted.

Also critical: rethink your workflows around high-risk actions. Wire transfers, account takeovers, login recovery flows—all of these should have multi-layered checks that include risk scoring, device fingerprinting, and behavioral cues.

And don’t stop at customers. Internal systems used by staff and contractors are equally vulnerable. Compromising a teller or loan officer’s account could give attackers access to systems that trust them implicitly.

2. Tune Your Own Data for AI-Driven Defense

You don’t need a seven-figure fraud platform to start detecting anomalies. Use what you already have: login logs, device info, transaction patterns, location data. There are open-source and affordable ML tools that can help you baseline normal activity and alert on deviations.

But even better—don’t fight alone. Join information-sharing networks like FS-ISAC, InfraGard, or sector-specific fraud intel circles. The earlier you see a new AI phishing campaign or evolving shape-shifting malware variant, the better chance you have to stop it before it hits your members.

3. Start Your “Future Threats” Roadmap Today

You can’t wait until quantum breaks RSA to think about your crypto. Inventory your “crown jewel” data—SSNs, account histories, loan documents—and start classifying which of that needs to be protected even after it’s been stolen. Because if attackers are harvesting now to decrypt later, you’re already in the game whether you like it or not.

At the same time, tabletop exercises should evolve. No more pretending ransomware is the worst-case. Simulate a synthetic ID scam that drains multiple accounts. Roleplay a deepfake CEO fraud call to your CFO. Put AI-enabled fraud on the whiteboard and walk your board through the response.

Final Thoughts: Small Can Still Mean Resilient

Small institutions often pride themselves on their close member relationships and nimbleness. That’s a strength. You can spot strange behavior sooner. You can move faster than a big bank on policy changes. And you can build security into your culture—where it belongs.

But you must act deliberately. AI isn’t waiting, and quantum isn’t slowing down. The criminals have already adapted. It’s our turn.

Let’s not be the last to see the fraud that’s already here.

* 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.

AI in Cyber Defense: What Works Today vs. What’s Hype

Posted on January 28, 2026 by Brent Huston

Practical Deployment Paths

Artificial Intelligence is no longer a futuristic buzzword in cybersecurity — it’s here, and defenders are being pressured on all sides: vendors pushing “AI‑enabled everything,” adversaries weaponizing generative models, and security teams trying to sort signal from noise. But the truth matters: mature security teams need clarity, realism, and practicable steps, not marketing claims or theoretical whitepapers that never leave the lab.

The Pain Point: Noise > Signal

Security teams are drowning in bold AI vendor claims, inflated promises of autonomous SOCs, and feature lists that promise effortless detection, response, and orchestration. Yet:

Budgets are tight.
Societies face increasing threats.
Teams lack measurable ROI from expensive, under‑deployed proof‑of‑concepts.

What’s missing is a clear taxonomy of what actually works today — and how to implement it in a way that yields measurable value, with metrics security leaders can trust.

AISecImage

The Reality Check: AI Works — But Not Magically

It’s useful to start with a grounding observation: AI isn’t a magic wand.
When applied properly, it does elevate security outcomes, but only with purposeful integration into existing workflows.

Across the industry, practical AI applications today fall into a few consistent categories where benefits are real and demonstrable:

1. Detection and Triage

AI and machine learning are excellent at analyzing massive datasets to identify patterns and anomalies across logs, endpoint telemetry, and network traffic — far outperforming manual review at scale. This reduces alert noise and helps prioritize real threats.

Practical deployment path:

Integrate AI‑enhanced analytics into your SIEM/XDR.
Focus first on anomaly detection and false‑positive reduction — not instant response automation.

Success metrics to track:

False positive rate reduction
Mean Time to Detect (MTTD)

2. Automated Triage & Enrichment

AI can enrich alerts with contextual data (asset criticality, identity context, threat intelligence) and triage them so analysts spend time on real incidents.

Practical deployment path:

Connect your AI engine to log sources and enrichment feeds.
Start with automated triage and enrichment before automation of response.

Success metrics to track:

Alerts escalated vs alerts suppressed
Analyst workload reduction

3. Accelerated Incident Response Workflows

AI can power playbooks that automate parts of incident handling — not the entire response — such as containment, enrichment, or scripted remediation tasks.

Practical deployment path:

Build modular SOAR playbooks that call AI models for specific tasks, not full control.
Always keep a human‑in‑the‑loop for high‑impact decisions.

Success metrics to track:

Reduced Mean Time to Respond (MTTR)
Accuracy of automated actions

What’s Hype (or Premature)?

While some applications are working today, others are still aspirational or speculative:

❌ Fully Autonomous SOCs

Vendor claims of SOC teams run entirely by AI that needs minimal human oversight are overblown at present. AI excels at assistance, not autonomous defense decision‑making without human‑in‑the‑loop review.

❌ Predictive AI That “Anticipates All Attacks”

There are promising approaches in predictive analytics, but true prediction of unknown attacks with high fidelity is still research‑oriented. Real‑world deployments rarely provide reliable predictive control without heavy contextual tuning.

❌ AI Agents With Full Control Over Remediations

Agentic AI — systems that take initiative across environments — are an exciting frontier, but their use in live environments remains early and risk‑laden. Expectations about autonomous agents running response workflows without strict guardrails are unrealistic (and risky).

A Practical AI Use Case Taxonomy

A clear taxonomy helps differentiate today’s practical uses from tomorrow’s hype. Here’s a simple breakdown:

Category	What Works Today	Implementation Maturity
Detection	Anomaly/Pattern detection in logs & network	Mature
Triage & Enrichment	Alert prioritization & context enrichment	Mature
Automation Assistance	Scripted, human‑supervised response tasks	Growing
Predictive Intelligence	Early insights, threat trend forecasting	Emerging
Autonomous Defense Agents	Research & controlled pilot only	Experimental

Deployment Playbooks for 3 Practical Use Cases

1️⃣ AI‑Enhanced Log Triage

Objective: Reduce analyst time spent chasing false positives.
Steps:
1. Integrate machine learning models into SIEM/XDR.
2. Tune models on historical data.
3. Establish feedback loops so analysts refine model behaviors.
Key metric: ROC curve for alert accuracy over time.

2️⃣ Phishing Detection & Response

Objective: Catch sophisticated phishing that signature engines miss.
Steps:
1. Deploy NLP‑based scanning on inbound email streams.
2. Integrate with threat intelligence and URL reputation sources.
3. Automate quarantine actions with human review.
Key metric: Reduction in phishing click‑throughs or simulated phishing failure rates.

3️⃣ SOAR‑Augmented Incident Response

Objective: Speed incident handling with reliable automation segments.
Steps:
1. Define response playbooks for containment and enrichment.
2. Integrate AI for contextual enrichment and prioritization.
3. Ensure manual checkpoints before broad remediation actions.
Key metric: MTTR before/after SOAR‑AI implementation.

Success Metrics That Actually Matter

To beat the hype, track metrics that tie back to business outcomes, not vendor marketing claims:

MTTD (Mean Time to Detect)
MTTR (Mean Time to Respond)
False Positive/Negative Rates
Analyst Productivity Gains
Time Saved in Triage & Enrichment

Lessons from AI Deployment Failures

Across the industry, failed AI deployments often stem from:

Poor data quality: Garbage in, garbage out. AI needs clean, normalized, enriched data.
Lack of guardrails: Deploying AI without human checkpoints breeds costly mistakes.
Ambiguous success criteria: Projects without business‑aligned ROI metrics rarely survive.

Conclusion: AI Is an Accelerator, Not a Replacement

AI isn’t a threat to jobs — it’s a force multiplier when responsibly integrated. Teams that succeed treat AI as a partner in routine tasks, not an oracle or autonomous commander. With well‑scoped deployment paths, clear success metrics, and human‑in‑the‑loop guardrails, AI can deliver real, measurable benefits today — even as the field continues to evolve.

* 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.