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

Three Field Guides for the Security Problems Showing Up Right Now

Over the last several months, we have released three longer-form guides around problems we keep seeing in real environments:

  • The Antifragile SOC Book
  • The AI Agents Management Framework
  • The Security Leader’s Operating System

They cover different areas, but they share a common theme: how to operate effectively as complexity, automation, and pressure increase.

Books

Why We Created These Materials

These guides did not begin as content projects.

They came from working problems.

Over the years, we have accumulated a lot of models, processes, questions, and operating approaches that we use when helping organizations solve difficult security problems. Some came from client work, some from research, and plenty came from lessons learned the hard way.

Much of that knowledge lived in conversations, notes, presentations, and experience.

We decided it was time to write more of it down.

Not as theory, and not as another collection of cybersecurity predictions.

As practical field material people can use, challenge, adapt, and apply.

Continue reading

The Top Three Things Security Teams Need to Understand About AI-Driven Attacks

The easiest mistake security teams can make about AI-driven attacks is to imagine a completely new species of adversary.

That is not what most organizations are facing.

The objectives remain familiar: steal credentials, gain access, persist, move laterally, collect data, commit fraud, extort the victim, or conduct espionage. What AI changes is the economics of the attack. It reduces the time, expertise, and attention required to move from one step to the next.

That distinction matters because it tells defenders where to act.

Google Threat Intelligence Group reported this week that it has observed adversaries moving beyond basic prompting into agentic workflows and AI-enabled automation. In one Q2 2026 case, a threat actor used an AI coding chatbot and agent instructions to help plan, build, and execute a mass credential-harvesting campaign in less than six hours. The framework automated scanning, troubleshooting, and IP rotation with limited human involvement. (Google Threat Intelligence Group, September 8, 2026)

That does not mean every attacker has become an autonomous machine. It means the constraints that used to slow attackers down are weakening.

OnlineScammer

Security teams need to understand three things.

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

Architecture Ages. Security Programs Should Plan for That

Every security architecture has an expiration date.

Most organizations simply do not know when it arrives.

An architecture may have been carefully designed, properly documented, and well defended when it was introduced. It reflected the business, technology, threat environment, and operational assumptions of its time.

Then the organization changed.

It adopted cloud services. It acquired another company. Employees became more distributed. Vendors received deeper access. Applications became API-driven. Automation expanded. AI entered business workflows. Identity became the connective tissue between systems that no longer shared a traditional perimeter.

The architecture did not suddenly fail.

It aged.

80sIBM

Continue reading

The Hidden Cost of “Temporary” Security Exceptions

Nothing is more permanent than a temporary security exception.

The emergency administrator account created during a production outage remains active months later.

The firewall opening approved for a launch is never removed.

The vendor access granted for troubleshooting quietly becomes the normal support model.

The policy exception accepted until a legacy application is replaced survives three budget cycles.

None of these conditions usually begins with negligence.

They begin with urgency.

That is precisely why they are dangerous.

E compliance

Exceptions Are Designed for the Present

A security exception is a decision to tolerate a known weakness because another business need is temporarily more important.

That may be entirely reasonable.

Continue reading

Stop Measuring Security Controls. Measure Decision Latency.

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

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

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

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