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

Posted on September 10, 2026 by Brent Huston

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.

1. AI Changes the Economics of an Attack Before It Changes the Objective

AI is most useful to attackers when it compresses work.

Reconnaissance can be summarized. Public vulnerability information can be translated into testable ideas. Phishing lures can be localized for a target’s language, role, industry, and current concerns. Malware can be debugged. Stolen data can be classified. Infrastructure can be configured. Failed steps can be revised without waiting for a specialist to return.

This is important because many defensive assumptions quietly depend on attacker friction.

We assume a small criminal group cannot personalize messages for thousands of targets.

We assume an inexperienced operator will make obvious technical mistakes.

We assume the time between vulnerability disclosure and reliable exploitation will give us room to patch.

We assume the volume of stolen data will slow an attacker before the most valuable records are identified.

AI weakens each of those assumptions.

Microsoft Threat Intelligence reported in March that most observed malicious AI use still centered on producing text, code, or media. Attackers were using it to draft lures, translate content, summarize stolen data, generate or debug malware, and scaffold scripts or infrastructure. Human operators generally retained control over objectives, targeting, and deployment decisions. (Microsoft Threat Intelligence, March 6, 2026)

OpenAI’s February threat report made a similar point: malicious actors typically combine AI with traditional tools, websites, social accounts, and other platforms rather than conducting an entire operation inside one model. (OpenAI, February 25, 2026)

The first defensive lesson is therefore simple:

Do not look only for an AI artifact. Look for an attack chain whose cost and cycle time have changed.

An AI-written email may not carry a reliable linguistic signature. AI-assisted malware may still use familiar persistence and command-and-control techniques. AI-summarized stolen data still has to leave the environment. The defender’s best opportunity may be the behavior around the content, not proof of how the content was produced.

Security teams should ask:

Which attack steps used to require scarce expertise?
Which controls assume the attacker will be slow, noisy, or inconsistent?
Which defensive queues already move more slowly than the exposure they manage?
Where could an attacker use AI to test, fail, adapt, and try again at low cost?

The answer will usually point to a handful of urgent bottlenecks: exposed systems, identity recovery, fraud verification, vulnerability triage, detection engineering, and containment approval.

2. Agentic Autonomy Is Real, but It Is Uneven

The industry tends to make one of two errors.

The first is dismissal: AI is only producing better phishing emails.

The second is exaggeration: fully autonomous systems are already discovering unknown vulnerabilities, compromising enterprises, and completing every objective without human direction.

The evidence supports a more disciplined position.

Agentic systems are beginning to perform meaningful portions of real attack workflows. They can observe results, choose the next action, call tools, correct errors, and continue toward an objective. That is more consequential than generating a block of code in a chat window.

At the same time, autonomy varies by actor, task, tooling, access, and model reliability. In its September report, Google described operational agentic credential-harvesting activity, but also said it had not yet observed threat actors deploy fully autonomous zero-day exploitation pipelines against targets in the wild. Its observations instead showed a gradual maturation: adversaries were using AI to accelerate n-day exploit development, refine payloads, and assemble multi-stage chains. (Google Threat Intelligence Group, September 8, 2026)

Anthropic reached a related conclusion after mapping 832 accounts banned for malicious cyber activity between March 2025 and March 2026 to MITRE ATT&CK. Its analysis found AI use moving deeper into post-compromise activity. It also argued that the more durable signal of a dangerous actor is not simply the number of techniques used, but the scaffolding built around the model to chain attack stages together with less human input. (Anthropic, June 3, 2026)

This changes threat modeling.

Security teams should stop treating autonomy as a yes-or-no label. Instead, examine the attacker’s control loop:

What can the system observe?
Which decisions can it make?
Which tools or credentials can it use?
How does it determine whether an action succeeded?
What causes it to stop, escalate, or change tactics?

The faster that loop runs, the less time defenders have between initial signal and material harm.

That makes defensive latency a security control.

Teams need high-confidence detections for identity changes, token use, privilege escalation, abnormal cloud activity, suspicious repository access, and unusual data movement. They also need preauthorized, bounded containment actions that can slow an attack without waiting for an improvised executive meeting.

The objective is not to automate every response. Some actions can disrupt production, destroy evidence, or help the attacker understand what the defender knows.

The objective is to decide in advance which actions can safely happen at machine speed, which require human judgment, and how quickly that judgment must arrive.

3. AI Is Both an Attacker Tool and an Attack Surface

Most discussions about AI-driven attacks focus on what an adversary can do with a model.

Security teams must also consider what an adversary can do to the organization’s AI systems.

Models, prompts, agent instructions, source code, API credentials, cloud compute, vector stores, development tools, model gateways, and connected data sources now have value. They can be stolen, manipulated, poisoned, hijacked, or used as paths into other systems.

Google reported Q2 2026 incidents involving theft of proprietary models, prompts, skills, code, and AI research, along with campaigns that targeted AI credentials and victim cloud resources for unauthorized model workloads. It also described malicious open-source packages and project files designed to influence AI coding assistants or interfere with LLM-based security scanning. (Google Threat Intelligence Group, September 8, 2026)

This creates two connected threat models.

The first is AI for the attack: the adversary uses AI to accelerate reconnaissance, social engineering, exploit development, credential harvesting, post-compromise work, or data analysis.

The second is AI as the attack path: the adversary targets the AI supply chain, manipulates content consumed by an agent, steals model or service credentials, poisons instructions, or abuses the tools and permissions connected to an AI workflow.

A security program that watches only for AI-generated phishing sees only the first few feet of the problem.

The AI environment should be governed like privileged production infrastructure. At minimum, security teams should know:

Which models, agents, coding assistants, gateways, and AI services are in use.
Which identities and API credentials they use.
Which tools, repositories, data stores, and production systems they can reach.
Which untrusted content can influence their behavior.
Where prompts, instructions, skills, memory, and configuration are stored.
Whether tool calls and administrative changes are logged.
How an AI service or agent can be isolated, suspended, or reconstituted.

The same principle applies to synthetic media and impersonation. In July, the FBI warned about scammers using AI-generated videos and spoofed sites to impersonate FBI personnel and revictimize people who had already reported fraud. The practical defense was independent verification through known official channels—not confidence that a person could visually identify every fake. (FBI Internet Crime Complaint Center, July 20, 2026)

That is a useful operating rule for enterprises as well:

When a request can move money, change access, expose sensitive information, or alter production, verify the authority and the transaction through a path the request itself did not supply.

Do not make perfect deepfake detection the control on which the business depends.

Use the Three-Question Test

For every significant incident, tabletop exercise, threat model, or intelligence review, ask three questions:

Compression

Which parts of the attack became faster, cheaper, more personalized, or easier to repeat because of AI?

Autonomy

Which observations, decisions, and actions could be chained together without waiting for a human operator?

Exposure

Which AI assets, credentials, tools, data sources, and trust relationships could become targets or execution paths?

These questions are more useful than asking whether an attack is “AI-powered.”

That label does not tell the incident commander what to contain. It does not tell the vulnerability team what to patch first. It does not tell the IAM team which recovery path to harden. It does not tell the board whether the organization’s risk has materially changed.

Compression, autonomy, and exposure do.

What Security Teams Should Do This Week

Start small and make the work concrete.

Update one attack scenario. Take a familiar credential-theft, ransomware, fraud, or supply-chain scenario and identify where AI could compress the attacker’s work.
Find one defensive delay that matters. Measure the time from the first credible signal to the first action that meaningfully constrains the attacker.
Inventory the AI control surface. Identify production agents, coding assistants, model credentials, connected tools, repositories, and sensitive data paths.
Instrument the control loop. Log identity use, tool calls, configuration changes, unusual compute consumption, repository access, and consequential agent actions.
Rehearse independent verification. Test a high-consequence request involving a convincing executive, vendor, help-desk, or finance impersonation.

None of this requires abandoning the security fundamentals.

Phishing-resistant authentication still matters. Least privilege still matters. Vulnerability prioritization still matters. Segmentation, logging, egress control, secure software development, tested recovery, and practiced incident response still matter.

AI does not repeal those controls.

It changes the speed and scale at which their weaknesses can be discovered, combined, and exploited.

The question security leaders should ask is no longer:

Was AI involved in this attack?

The better questions are:

Where did AI compress the attack chain, what did it allow the attacker to automate, and which AI systems became part of the path?

Teams that can answer those questions will be able to adapt without chasing every dramatic headline.

Teams that cannot may discover that the attacker did not need a fundamentally new technique.

It only needed to perform the old ones faster than the organization could respond.

More Information and Assistance

MicroSolved, Inc. can help organizations:

Assess AI-enabled threat exposure and attack paths.
Threat-model AI agents, coding assistants, and connected workflows.
Review identity, API credential, data-access, and tool-use controls.
Test AI-accelerated fraud, credential theft, supply-chain, and incident-response scenarios.
Design practical detection, containment, and recovery improvements.

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

Relax. We’re on watch.

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

Introducing The Security Leader’s Operating System

Posted on September 3, 2026 by Brent Huston

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.

Protect the Work Only the Leader Can Do

Some work genuinely belongs with the security leader.

Setting risk appetite, challenging assumptions, translating technical exposure into business decisions, communicating during consequential events, developing people, and accepting residual risk cannot simply be optimized away.

But that work is often crowded out by management exhaust: status collection, repetitive reporting, preventable escalations, meeting preparation, evidence retrieval, routing questions, and processes that exist largely because they have always existed.

The guide introduces practical ways to distinguish leader-only work from work that can be removed, transferred, redesigned, or supported by better systems.

It includes:

A Money, Attention, and Time workload scan
The Eisenhower Matrix mapped into EDSAM
TaskGrid as an example of integrating urgency, importance, agency, commitments, planning horizons, and EDSAM dispositions
Information security workload playbooks
A recurring operating cadence
A 30-day reset
Capacity and decision tools
Field-ready worksheets and checklists
A NIST Cybersecurity Framework 2.0 scope check

AI Can Reduce Work—or Industrialize the Wrong Work

Modern LLMs, GPTs, skills, assistants, and agents make this conversation more urgent.

These tools can retrieve information, summarize evidence, compare documents, prepare decision packets, draft communications, and move bounded work through repeatable processes.

They can also accelerate bad processes, obscure missing context, accumulate excessive authority, and create new infrastructure that someone must maintain.

That is why the guide applies EDSAM before automation.

It explores how to divide work among humans, models, and deterministic systems; how to establish capability levels and autonomy budgets; and how to preserve accountable human judgment when AI-enabled workflows can create real consequences.

The important question is not simply, “Can AI perform this task?”

The better sequence is:

Should this work exist?
Who should own its outcome?
What is the smallest useful result?
Which parts are predictable enough to automate?
What judgment, authority, or relationship must remain human?

A Field Guide, Not a Theory Book

This is intended to be used with the work already in front of you.

Choose one recurring meeting. One report. One approval queue. One source of preventable escalation. One hour of work that only you can perform.

Then apply the system.

A saved hour is useful. A redesigned workflow that prevents the same demand from returning every week is leverage. A clearer decision boundary makes the entire team stronger.

My broader goal is to leave behind a legacy of useful knowledge—methods that other people can test, challenge, improve, and carry forward. I hope this guide becomes part of that working library.

Download the Field Guide

You can download The Security Leader’s Operating System here:

Download The Security Leader’s Operating System

As you work through it, I would be interested to hear what you eliminate, delegate, simplify, automate, or deliberately maintain first.

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

Posted on August 31, 2026 by Brent Huston

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.

Incident Response Has a Hidden Assumption

Most incident-response plans assume the defensive machinery will survive the incident.

The identity provider will authenticate responders. The privileged-access system will issue administrative credentials. The cloud management plane will accept containment commands. The SIEM will provide reliable telemetry. The ticketing platform will maintain the timeline. Email, chat, conferencing, and document-sharing systems will allow the response team to coordinate.

Those systems are treated as infrastructure surrounding the incident rather than as potential components of the incident.

That is a dangerous assumption.

In a recent State of Security post, I argued that controls that look separate on an architecture diagram may actually be “branches of the same tree.” They may share an identity provider, administrative tenant, logging pipeline, automation layer, DNS infrastructure, certificate authority, or cloud control plane. When one of those shared foundations fails, several supposedly independent controls can fail with it. (State of Security)

The next question is harder:

What is the smallest defensive system the organization must be able to operate after that tree falls?

This is not conventional disaster recovery. It is not simply a matter of restoring the SIEM, activating a backup tenant, or retrieving an emergency password.

It is degraded-mode security operations.

The Control Plane Can Fail by Lying

Security teams usually test failures as availability problems.

The identity provider is down. The SIEM is unreachable. The ticketing platform will not load. The primary cloud region is unavailable.

Those are relatively clean failures. They are visible, bounded, and easy to describe during a tabletop exercise.

Adversarial failure is different.

A compromised identity provider may continue issuing tokens. A hostile administrator may alter conditional-access policies while leaving the service operational. A logging pipeline may continue displaying data while silently omitting selected events. A collaboration platform may preserve most messages while exposing the incident channel to the attacker. An automation platform may continue executing containment playbooks after its credentials or logic have been subverted.

The system is not down.

It is lying.

That distinction changes the recovery problem. An unavailable system can sometimes be restored. An untrustworthy system must first be excluded from the response path.

NIST’s cyber-resiliency work provides the right foundation for thinking about this. It frames resiliency around four outcomes: anticipating adverse conditions, withstanding them, recovering from them, and adapting afterward. It also applies that thinking to shared services, common infrastructure, and systems of systems—not merely individual applications. (NIST Computer Security Resource Center)

A resilient security program therefore cannot define success only as preventing compromise or restoring systems. It must be able to continue essential defensive operations while some of its own systems are unavailable, degraded, or hostile.

Start With Inversion

The normal planning question is:

How do we keep the security control plane available?

That is necessary, but incomplete.

Invert the problem:

Assume the primary security control plane is unavailable or cannot be trusted. How do we still defend the organization?

Assume that:

The primary identity provider cannot be trusted.
Existing administrative sessions may belong to the attacker.
The privileged-access platform is inaccessible.
Centralized telemetry is incomplete.
Normal collaboration and ticketing systems are exposed.
Managed responder workstations may be under hostile administrative control.
Cloud automation may be executing unauthorized changes.
DNS, certificate, key-management, or time services may be unreliable.
One or more key responders cannot be reached.

Now ask what responders must still be able to do.

Not which products must be restored.

Not which dashboards executives expect to see.

Not which recovery checklist should be opened first.

What capabilities must exist for the organization to remain defensible?

Define the Minimum Viable Defensive System

A Minimum Viable Defensive System is the smallest deliberately independent collection of people, authority, identities, devices, communications, telemetry, containment mechanisms, evidence storage, and recovery materials that allows the organization to continue defending itself when its normal security control plane is unavailable or untrusted.

It is not a second full-sized SOC.

It is not a duplicate of every production security tool.

It is not a collection of individually labeled “break-glass” features.

It is a composed operating system for degraded defense.

At minimum, it must provide six capabilities.

Capability	Minimum viable state	Evidence that it is independent
Authenticate	Authorized responders can establish identity and emergency authority using protected credentials and trusted administrative devices.	The path does not require the primary identity provider, PAM platform, corporate network, normal endpoint-management plane, or primary email account.
Communicate and coordinate	Responders can establish a secure command channel, assign roles, reach critical internal and external parties, and maintain a decision and action log.	Accounts, provider, authentication, network path, and recovery information do not depend on the primary collaboration environment.
Observe	Responders can obtain trustworthy information from critical systems and identify gaps, delay, or tampering in normal telemetry.	Collection, storage, access, keys, and administrative authority do not all share the suspected failure domain.
Contain	Responders can revoke access, disable identities, isolate assets, stop dangerous automation, alter routes or policies, and protect critical systems.	Emergency containment does not require normal SSO, normal PAM approval, the primary SOAR platform, or access to the normal ticketing workflow.
Preserve evidence	Responders can store relevant logs, configuration data, images, exports, notes, and decision records with integrity and provenance.	Primary administrators cannot silently alter or delete the evidence, and responders retain access to keys, timestamps, capacity, and custody procedures.
Reconstitute	Responders can rebuild roots of trust and restore defensive services from known-good materials in a defined order.	Configurations, credentials, keys, backups, tooling, and administrative access do not depend entirely on the environment being rebuilt.

These are capabilities, not products.

A security team may satisfy them through a mixture of cloud-native controls, offline materials, separate accounts, alternative providers, clean devices, manual procedures, direct system access, and preauthorized decision rights.

NIST makes a similar architectural point in its resiliency guidance: survivability comes from combinations of technology, architectural choices, engineering practices, operational procedures, and people—not from one product or control.

Break Glass Is Not an Account

Organizations often point to an emergency administrative account as proof that degraded-mode access has been addressed.

That is only one link in the chain.

Consider an emergency account that:

Is stored in the normal PAM platform.
Uses the normal identity provider for authentication.
Requires a managed laptop that cannot be unlocked without normal SSO.
Can be used only from the corporate network.
Depends on the normal DNS and certificate infrastructure.
Requires an approval recorded in the normal ticketing system.
Sends its alerts to the normal SOC mailbox.

The account exists.

The emergency capability does not.

Break glass is not an account. It is an end-to-end operating path.

Microsoft’s emergency-access guidance recommends multiple cloud-only accounts, authentication methods that differ from normal administrative authentication, secure storage, monitoring, and recurring validation. AWS similarly describes pre-created emergency identities and roles, dedicated emergency access arrangements, hardware authentication, and periodic testing for situations in which the centralized identity provider is unavailable or compromised. (Microsoft Learn)

Those are valuable design ingredients. The security program still has to compose them into a functioning response system.

The responder must be able to retrieve the credential, authenticate, use a trusted device, reach the management interface, execute an authorized action, record that action, observe its effect, and preserve the resulting evidence.

Testing only the login proves only the login.

Independence Is a Property of the Whole Path

Two tools can be different and still fail together.

A secondary messaging platform is not independent if it uses the same identity provider.

A backup SIEM is not independent if it receives data through the same collectors.

A separate cloud account is not independent if the compromised organization administrator can assume control over it.

An immutable log store is not useful during the incident if access to its decryption keys depends on the failed key-management plane.

A responder laptop is not clean if it must contact the suspect device-management service before allowing an administrator to sign in.

An alternate network path is not alternate if it converges on the same DNS, certificate, firewall-management, or telecommunications dependency.

This is why fallback design must be scenario-specific. Nothing is universally independent. It is independent only relative to a defined failure.

NIST’s guidance on diversity and redundancy warns that apparent alternatives can converge on the same underlying foundation. It specifically treats diversity of command, control, and communications paths—including out-of-band paths—as a resiliency technique, and notes that redundancy can be undermined when duplicated capabilities share common resources or homogeneous components.

CISA guidance has likewise emphasized out-of-band incident communications, separate management paths, and logging aggregated into protected out-of-band locations. These practices reduce the chance that the compromised environment can blind or isolate the response team. (CISA)

Again, those mechanisms are necessary.

They are not sufficient until they work together.

Restore Capabilities, Not Products

During a compound failure, organizations tend to restore whatever system has the most visible outage, the loudest executive sponsor, or the clearest recovery runbook.

That can produce the wrong order.

The goal is not to make the security stack look normal as quickly as possible. The goal is to restore trustworthy defensive agency.

A practical priority sequence looks like this.

1. Establish trusted command

The organization needs an incident commander, an emergency authority model, authenticated responders, a protected communications channel, and a functioning decision record.

Without trusted command, every subsequent action is debatable. Responders do not know who is authorized, which instructions are legitimate, or whether the attacker is participating in the response.

This layer should also provide access to an offline or separately protected contact roster covering executives, legal counsel, insurers, outside responders, critical vendors, law enforcement contacts, and communications personnel.

2. Establish a trustworthy view

Responders must determine what they can still observe and which sources remain credible.

This does not require immediately rebuilding the entire SIEM. It may involve direct access to native audit sources, an independently protected log archive, network telemetry, cloud snapshots, system exports, or read-only queries through emergency accounts.

The first question is not, “Are logs arriving?”

It is, “What evidence do we have that these logs are complete, current, and resistant to alteration by the suspected adversary?”

Evidence preservation begins here. Observation and preservation should not be separated into distant phases. The data available during the first hour may not remain available later.

3. Regain safe containment capability

Once responders have enough confidence to act, they need a limited but reliable way to constrain the event.

That may include:

Revoking sessions and tokens.
Disabling identities.
Isolating accounts, workloads, subscriptions, or network segments.
Blocking known infrastructure.
Suspending compromised automation.
Protecting backups and logging repositories.
Restricting administrative paths.
Moving critical services into a predefined defensive posture.

Containment paths should be narrow, preauthorized, observable, and reversible where practical.

They should not depend on the same orchestration layer whose trust is in question.

4. Reconstitute roots of trust

Only after responders have trusted command, sufficient visibility, and safe agency should they begin rebuilding the normal control plane.

Reconstitution must follow dependency order.

Identity may need to be restored before PAM. Key management may need to be restored before protected logging. Trusted administrative endpoints may need to be rebuilt before cloud policy is changed. Logging may need to be reestablished before production workloads are reconnected.

Restoring dependent tools before their foundations are trustworthy creates the appearance of recovery without its substance.

This is a priority model, not a waterfall. Observation, evidence preservation, and containment will often proceed in parallel. The point is to prevent teams from restoring familiar products while critical defensive capabilities remain absent.

Measure Time to Defensible State

Traditional recovery planning uses recovery-time objectives to express how long a system can remain in recovery before unacceptable harm occurs. That is useful for determining when an identity platform, logging service, or collaboration system must return. (NIST Computer Security Resource Center)

It does not answer what defenders can do while those systems remain unavailable.

A security program should add another measure:

Time to Defensible State

Time to Defensible State is the elapsed time between declaring the primary defensive control plane unavailable or untrustworthy and validating that the Minimum Viable Defensive System is operating through independent paths.

A defensible state might require proof that:

Emergency authority has been invoked.
Required responders have authenticated independently.
A secure command channel is operating.
A decision and action record is being maintained.
At least one trustworthy telemetry path is available.
Responders can execute and verify an emergency containment action.
Evidence can be deposited into an independently protected repository.
The team understands which normal services remain prohibited.

“Someone successfully logged in” is not a defensible state.

“We opened the backup chat room” is not a defensible state.

The state is reached only when the capabilities operate together.

Organizations should measure the component times as well:

Time to recognize and declare control-plane degradation.
Time to establish trusted responder identity.
Time to establish out-of-band command.
Time to obtain the first trustworthy telemetry.
Time to execute the first validated containment action.
Time to preserve the first evidentiary artifact.
Time to begin controlled reconstitution.
Maximum duration the degraded system can operate.

That last measure matters.

A fallback that works for 20 minutes but cannot support a twelve-hour investigation is not sufficient. Capacity, credential lifetime, battery life, communications access, evidence-storage volume, staffing, vendor support, and shift turnover are all part of the design.

Test Compound Failure, Not Components

Most organizations test their emergency mechanisms one at a time.

The emergency administrator logs in.

The backup conference bridge works.

The log archive accepts a test event.

The incident-response binder opens.

The cloud backup restores.

Every component passes.

Then the system fails during the exercise because nobody can retrieve the emergency credential without the PAM system, the clean laptop requires the unavailable identity provider, and the alternate communications channel does not include legal counsel or the cloud team.

Component success is not system success.

A meaningful exercise should begin with a compound condition such as:

The identity provider is suspected of compromise. Existing administrative sessions cannot be trusted. The centralized logging query plane is unavailable, although some collection continues. Normal email, chat, ticketing, and PAM systems are prohibited. The cloud management environment may contain unauthorized policy changes.

Then make the team perform the work.

Retrieve the emergency materials using the real custody process.

Start the designated administrative devices.

Use the actual alternate network path.

Authenticate to the necessary systems.

Generate a known event and prove it appears in the independent telemetry path.

Contain a sacrificial asset.

Preserve an artifact and validate its integrity.

Reach an external participant.

Maintain the incident log.

Operate long enough to perform a shift handoff.

Exit degraded mode, reconcile all emergency actions, rotate credentials, and restore monitoring.

Do not allow the exercise controller to hand the team imaginary access, pretend that a credential was retrieved, or declare a containment action successful without executing a safe equivalent.

Every simulated shortcut conceals a dependency.

NIST’s current incident-response guidance treats preparation, response, and recovery as integrated parts of cybersecurity risk management rather than as a separate binder activated after detection. Compound-failure testing is one way to turn that integration into operational evidence. (NIST Computer Security Resource Center)

The Fallback Creates Its Own Risk

An independent defensive system is powerful.

That also makes it dangerous.

Emergency identities may hold standing privilege. Alternative communications channels may escape normal monitoring. Offline credentials can become stale or be mishandled. Direct administrative paths can bypass approval systems. Separate evidence stores may contain highly sensitive information. Dormant devices may miss critical patches.

The fallback cannot simply be hidden and forgotten.

It requires its own controls:

Dual custody for the most powerful emergency materials.
Tamper-evident storage and access records.
Narrowly scoped emergency roles.
Independent monitoring of every activation.
Regular credential, key, and device validation.
Immediate review and rotation after use.
Defined activation and termination authority.
Reconciliation of emergency actions into normal records.
Periodic review for new shared dependencies.

This is a second-order tradeoff.

The organization creates exceptional access to survive the loss of normal access controls. It must then protect that exceptional access without reconnecting it to the same control plane it was designed to bypass.

There is no product setting that resolves that tension. It must be engineered and governed.

A Practical Design Standard

A security program should not claim degraded-mode readiness until it can produce six things.

1. A declared defensive minimum

The organization has explicitly defined what authentication, communication, observation, containment, evidence preservation, and reconstitution mean in its environment.

2. A dependency topology

Each capability has been traced through its identities, devices, networks, providers, administrators, keys, data sources, and human custodians.

Shared failure domains are visible.

3. Independence claims tied to scenarios

The organization does not say that a system is simply “independent.” It states which failures it is independent from and provides evidence supporting that claim.

4. Activation and exit criteria

Responders know who can declare the primary control plane untrusted, what changes when that declaration occurs, and what evidence is required before normal systems can be used again.

5. Measured recovery of defensive capability

The organization has established a target Time to Defensible State and measured it during an end-to-end exercise.

6. Evidence of sustained operation

The fallback has demonstrated that it can support a realistic incident duration, including staffing changes, evidence growth, credential use, containment actions, external coordination, and eventual reconciliation.

This turns degraded-mode response from a collection of reassuring statements into a testable design standard.

Small. Separate. Boring. Measured.

The Minimum Viable Defensive System should be small enough to understand.

It should be separate enough to survive the named failure.

It should be boring enough to operate under stress.

It should be measured often enough that leadership knows whether it is real.

Centralization is not inherently bad. Modern security programs need centralized identity, logging, administration, orchestration, and collaboration.

But centralized efficiency creates concentrated dependency.

A mature program does not pretend those dependencies will always survive. It plans for the moment when the normal tools are unavailable, the dashboards are questionable, and the attacker may be using the same administrative machinery as the defenders.

The question is no longer:

Do we have break-glass accounts?

The question is:

Can we prove that authorized responders can authenticate, communicate, observe, contain, preserve evidence, and begin reconstitution when the primary security control plane is unavailable or hostile—and can they do it within a measured period?

Until the answer is yes, the organization is resilient only while its assumptions hold.

Security programs must do more than defend the business.

They must remain capable of defending it while their own machinery is failing.

More Information and Assistance

MicroSolved, Inc. can help organizations:

Map security-control dependencies and shared failure domains.
Define a Minimum Viable Defensive System.
Design independent emergency identity, communications, administrative, logging, and evidence paths.
Establish degraded-mode activation and recovery procedures.
Run compound-failure tabletop and live validation exercises.
Define and measure Time to Defensible State.

Contact MicroSolved at info@microsolved.com or +1.614.351.1237. Relax. We’re on watch.

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

Architecture Ages. Security Programs Should Plan for That

Posted on August 24, 2026 by Brent Huston

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

Posted on August 17, 2026 by Brent Huston

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.

Posted on August 10, 2026 by Brent Huston

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 August 3, 2026 by Brent Huston

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 July 31, 2026 by Brent Huston

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 July 13, 2026 by Brent Huston

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 June 29, 2026 by Brent Huston

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 →