Author Archives: Brent Huston

About Brent Huston

I am the CEO of MicroSolved, Inc. and a security evangelist. I have spent the last 20+ years working to make the Internet safer for everyone on a global scale. I believe the Internet has the capability to contribute to the next great leap for mankind, and I want to help make that happen!

Stop Measuring Security Controls. Measure Decision Latency.

Posted on by
Reply

The attacker already made a decision.

Your organization is still scheduling the meeting.

For years, security programs have measured the presence and performance of controls. We count vulnerabilities, patching percentages, phishing failures, endpoint coverage, open findings, audit exceptions, and incident response times.

These metrics can be useful.

They can also create the illusion that security outcomes are primarily determined by control quality.

In many consequential events, the organization does not fail because it lacks information or technology.

It fails because it cannot make a confident decision quickly enough.

Cyberleader

Continue reading →

Security Debt Compounds Faster Than Technical Debt

Posted on by
Reply

Organizations rarely wake up insecure.

They slowly inherit yesterday’s exceptions.

A firewall rule is added to support an urgent launch. A service account is created for an integration that will supposedly be replaced next quarter. A vendor receives elevated access during troubleshooting. A legacy application remains connected because the migration became more difficult than expected.

Each decision appears manageable in isolation.

Over time, they begin to interact.

That is when security debt starts to compound.

Thinking

Security Debt Is More Than Unpatched Software

Technical debt generally refers to the future cost created when teams choose a faster or easier implementation today.

Continue reading →

Your Biggest Security Risk Might Be Organizational Complexity

Posted on by
Reply

Every security team adds tools to reduce risk.

A new endpoint platform closes a visibility gap. A cloud security product addresses configuration drift. An identity tool improves access governance. Another dashboard gives executives a consolidated view of the environment.

Individually, each decision makes sense.

Collectively, those decisions can create a security program that is difficult to understand, expensive to operate, and nearly impossible to change safely.

Eventually, the tools intended to reduce risk become part of the risk.

GenSec

Complexity Is an Attack Surface

We usually describe the attack surface in technical terms: exposed services, vulnerable applications, unmanaged devices, excessive privileges, and external dependencies.

But organizations also have an operational attack surface.

Continue reading →

Your Security Controls May Be Less Independent Than You Think

Posted on by
Reply

Most enterprise security programs still measure strength by counting controls.

MFA is deployed. EDR is deployed. Logging is centralized. Privileged access is monitored. Cloud guardrails are active. The dashboard shows broad framework coverage, so leadership concludes that the organization has defense in depth.

That conclusion may be wrong.

The problem is not necessarily that the controls are weak. The problem is that several supposedly independent controls may rely on the same underlying service.

An identity provider may authenticate administrators to the EDR console, SIEM, cloud environment, ticketing system, and incident-response platform. A centralized telemetry pipeline may supply detection data to multiple tools. Several controls may reside in the same cloud account, depend on the same DNS or time service, or be managed through one administrative plane.

On a control matrix, these appear to be separate layers.

In the actual system, they may be branches of the same tree.

Continue reading →

Vendor Evidence Is Now a Cyber Materiality Risk

Posted on by
Reply

A cybersecurity incident does not care where your data lives.

It does not care that the affected application is vendor-managed. It does not care that the logs are in a SaaS console your team cannot access. It does not care that the data-flow diagram is maintained by procurement, that customer-impact details live with a managed service provider, or that the outage timeline depends on a third-party support ticket.

But your materiality decision may care very much.

Public companies must disclose material cybersecurity incidents on Form 8-K within four business days after determining that the incident is material. The SEC’s rule also requires disclosure of the material aspects of the incident’s nature, scope, timing, and impact or reasonably likely impact, and the materiality determination must be made without unreasonable delay after discovery.

That creates a practical problem many organizations have not fully internalized:

The disclosure clock may be yours, but the evidence may belong to someone else.

That is not just a legal nuance.

It is an operational design problem.

It is a governance problem.

Continue reading →

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.

Continue reading →

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.

Continue reading →

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.

Continue reading →

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 →

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 →