Authentication Is Not the Finish Line: Secure the Token Lifecycle

A user signs in with a passkey. The authentication is phishing-resistant. The identity provider records a successful challenge. Every dashboard says the login worked as designed.

Hours later, an attacker reuses a stolen session token.

No password is entered. No push notification appears. No new authentication ceremony occurs. The application sees a valid artifact and accepts it.

Both facts can be true at the same time: the authentication was strong, and the session was compromised.

That is the identity problem security programs need to address next.

Passkeys, hardware security keys, conditional access, and stronger account recovery are essential. They protect the process of establishing identity. But modern applications rarely ask a person or workload to prove identity again for every action. They rely on tokens and assertions that carry the result of an earlier decision across applications, APIs, clouds, and sessions.

The security boundary therefore does not end at login. It moves with the token.

NIST and CISA made that point operational in the final September 2026 release of NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse. The report addresses the keys that create trust, the systems that validate it, the lifetime of tokens, session monitoring, revocation, workload identity, and the division of responsibility between cloud providers and their customers.

The practical lesson is straightforward:

Treat every token as a live authorization decision, not as a receipt proving that authentication once succeeded.

An award winning portrait of a beautiful red headed woman bokeh lights in background cinematic lighting realistic very sharp 8k 3d render

Continue reading →

Introducing The Security Leader’s Operating System

There is one sentence I hear from information security leaders more than almost any other:

“I don’t have time to do what I need to do.”

The problem usually isn’t motivation, discipline, or effort. Security leaders already work hard. The deeper problem is that their ability to handle difficult work attracts more difficult work.

Questions, approvals, exceptions, vendor reviews, audit requests, incidents, meetings, unfinished decisions, and executive concerns all flow toward the person who has demonstrated that they can carry them. Eventually, being able to handle almost anything becomes the reason the leader has time to think about almost nothing.

I wrote The Security Leader’s Operating System to help change that.

Thinking

Security Leaders Don’t Need Another Productivity Trick

Most productivity systems concentrate on organizing work after it has already been accepted.

This field guide starts earlier.

Before deciding where a task belongs, it asks whether that work should exist in its current form at all. It applies the EDSAM mental model:

  • Eliminate work that does not need to happen.
  • Delegate outcomes that do not require the leader’s authority or judgment.
  • Simplify work until it produces the smallest useful result.
  • Automate the predictable parts of the work that remains.
  • Maintain only what must remain under the leader’s direct care.

The objective is not to help security leaders process an endlessly growing queue more quickly. It is to redesign the system so that less work requires the leader in the first place.

Continue reading →

When the Security Control Plane Fails: Build a Minimum Viable Defensive System

At 2:13 a.m., the SOC receives an alert involving a cloud administrator.

At 2:16, analysts lose access to the SIEM because authentication depends on the identity provider now under investigation.

At 2:19, the incident collaboration channel disappears.

At 2:23, the on-call engineer discovers that the break-glass credentials are stored in the privileged-access platform—which also authenticates through the suspect identity provider.

At 2:27, the cloud console still shows green status indicators, but nobody can establish whether the logs are complete, delayed, or manipulated.

By 2:35, the organization has two incidents.

The first is the security event.

The second is the loss of its ability to respond to the security event.

That second incident is the one most response plans do not adequately address.

3Errors

Incident Response Has a Hidden Assumption

Continue reading →

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

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

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

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?

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 →

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

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

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

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:

  1. A probabilistic signal.

  2. A consumption of analyst time.

  3. 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:

  1. Board reporting becomes defensible.
    You can quantify risk reduction efficiency.

  2. Budget conversations mature.
    Funding becomes tied to economic return, not fear narratives.

  3. “Alert theater” declines.
    Activity is no longer mistaken for effectiveness.

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