200 days into the frontier: What we know and what to do now

More than 200 days into the Super Intelligence era, the implications for business are becoming clearer. Technology is accelerating offense and complexity faster than many enterprises can reduce accumulated risk. Capabilities once limited by specialized expertise are becoming more accessible. Vulnerability discovery and attack automation are moving at warp speed. Remediation is not. At the same time, the frontier’s rapid advancement is increasing dependence on hardware, data centers, telecommunications, water and power. We are all increasingly interconnected, which means resilience ultimately depends on how well the whole ecosystem works together.

Earlier this year, we shared 10 actions that enterprises can take to strengthen cyber resilience. Those actions remain important foundations. What is now clearer is that AI magnifies risks accumulated over time. Complexity itself has become a security risk.

We are already seeing that critical vulnerabilities can trigger urgent, large-scale remediation efforts. Technology that is outdated or unsupported can become a liability overnight. And as companies race to deploy AI agents, security has to advance with it.

For CEOs, the imperative is clear: Change assumptions, shorten decision cycles and build resilience. Reduce accumulated technology risk while ensuring that products and infrastructure being built today are secure and resilient by design.

Change assumptions

Practices and risks that were acceptable in a former technology environment may no longer be tolerable. When technology and threats move faster, tolerance for avoidable risk has to change too. Outdated technology, internet-facing systems and remediation timelines designed for a slower environment can become liabilities with little warning.

Leaders need to reset risk appetite, make exceptions explicit, fund the necessary change and establish accountability across product, technology, security, operations and suppliers.

That does not mean treating every problem as equally urgent. It means acting decisively where exposure and potential impact are greatest and directing resources accordingly.

Make technology currency non-negotiable

Challenge the notion that stable technology is safe technology. Software or hardware can continue to operate while becoming progressively harder to protect. When vendors or software maintainers stop supporting older technology, security patches will stop too. This is known as end of support (EOS). EOS is predictable. Accepting the risk is a choice.

PHP illustrates the issue. When serious vulnerabilities emerged, security fixes were provided only for the current version. Organizations running older versions had to move to current or remove the dependency. The same principle applies to unsupported programming platforms, open-source libraries, operating systems and aging hardware.

Unsupported technology should be treated as a time-sensitive business liability. Any exception should have an accountable owner, funding, compensating controls and a dated exit plan.

Start with a complete, current inventory of software and hardware. Then prioritize by asking three questions:

How exposed is it? Can it be reached directly from the internet?
Can we protect it? Can it still receive timely security fixes?
What is the impact? Could compromise or failure affect customers, disrupt critical operations or impede recovery?

Know where outdated or EOS technology exists, which exceptions have been accepted, who owns them, what compensating controls are operating and when each item will be uplifted or replaced.

Fortify the front door

Keeping perimeter technology patched is necessary, but not sufficient. Firewalls, virtual private network gateways and other remote-access technologies connect internal systems to the internet. Because they are directly reachable, a serious vulnerability can give attackers a path into the enterprise.

Recent Citrix vulnerabilities underscored that risk, but the architectural issue extends beyond any single product. Patching the vulnerability in front of you addresses today’s exposure. If critical technology remains directly exposed to the internet, the next vulnerability can recreate the same risk.

Companies should reduce direct exposure and add layers of protection. An independent authentication layer can prevent unauthenticated traffic from reaching the underlying service, making vulnerabilities harder to discover or exploit.

Know what sits at the front door of the enterprise, why it must remain exposed and whether it is current and supported.
Reduce direct exposure and place independent authentication controls in front of sensitive services.
Strengthen monitoring, segmentation and containment, while avoiding designs in which the protective layer becomes a single point of failure.

Build security in, not on

In a technology environment, architecture is one of the company’s most consequential security decisions. Product speed and security should not be presented as opposites. Security and resilience requirements should inform market launch, scale and partner selection before architecture becomes difficult or expensive to change.

Management teams should understand how a product could be attacked or misused, limit unnecessary access, protect sensitive data and test security throughout development. Unresolved material risk should have clear ownership.

Make security and resiliency part of the requirements for going to market and for selecting critical technology partners.
Require material architectural risks to be surfaced early, with a decision owner and a funded path to resolution.
Design so that one weakness cannot place critical operations at risk.

Put hard boundaries around AI agents

Frontier technologies are moving from answering questions to taking action. Agents can increasingly interact with enterprise systems, access information and execute tasks with limited human involvement. Capability, however, should not automatically determine authority.

Before expanding what agents can do, establish what they cannot do. Access should be based on the task, not on the theoretical reach of the model. Human oversight should be proportional to consequence: a reversible, low-impact action warrants a different control than moving money, changing production systems or communicating with a customer.

Give agents only the access required for the task and enforce limits on the systems, data and actions available to them.
Make agents identifiable, monitor their actions in real time and preserve traceability for investigation and recovery.
Maintain the ability to restrict or stop an agent quickly.
Reassess boundaries as capabilities, use cases and dependencies change.

Shorten decision cycles

Frontier technology is compressing the time between vulnerability discovery, potential exploitation and the need to respond. Governance must be able to move at the speed of the threat. Speed does not mean bypassing governance or accepting uncontrolled change. It is the product of governance designed before the crisis begins.

Redesign governance for speed

Traditional escalation paths, approval processes and change windows can become risks if they prevent an organization from acting quickly enough. During a significant event, the relevant decision-makers should be clear, escalation thresholds understood, emergency authorities defined and required evidence available quickly. Companies also need the ability to test and deploy critical fixes safely and at speed. Teams should not have to invent a decision process during the incident.

Leaders must also be prepared to reprioritize. When new exposure materially changes potential impact, planned work needs to give way and resources need to move with the risk. Risk acceptance should be owned and time-bound.

Separate decision speed from execution speed

An organization may decide in hours and still require days or weeks to act. It may need to establish which systems are affected, locate accountable owners, test a patch, secure a change window, coordinate suppliers, deploy across a complex estate and confirm that remediation succeeded.

Decision speed and execution speed require separate measures. Faster approval has little value if asset data is incomplete, testing capacity is constrained or deployment cannot scale safely. Both the operating model and the technology estate must support rapid action.

CEOs should ask whether cyber incident-response teams have the access and authority to act at the speed of an attack, or whether they depend on layers of coordination and approval. When a critical service is exposed and cannot be fixed, teams may also need clear authority to isolate it or take it offline to prevent greater harm.

Define decision rights and emergency authorities in advance so teams can act in hours, not weeks.
Predefine when an exposed service should be isolated, reduced or taken offline if a timely fix is not available.

Include suppliers in response readiness

Even the strongest internal process depends on technology suppliers to identify vulnerabilities, communicate them quickly and make fixes available. A supplier can determine how quickly the company responds.

Companies should know which providers could become rate-limiting dependencies, whether notification and escalation expectations are contractual, and what options exist if a timely fix is unavailable. An affected service may need to be isolated, replaced or operated temporarily in a reduced state.

Define notification, escalation and remediation expectations with critical suppliers.
Exercise supplier communications and decision paths before an event.
Establish alternatives for situations in which a fix is late, incomplete or unavailable.

Exercise decisions, not only technical responses

Exercises should test more than whether a technical team can apply a patch. They should test whether the enterprise can establish exposure, provide executives with decision-useful information, activate emergency authorities, evaluate competing business impacts and deploy safely at scale.

Validate whether suppliers respond as expected and whether an affected service can be isolated or reduced.
Exercise leadership decisions, including redirecting resources and changing priorities in hours, not weeks.
Test customer, regulatory and contractual obligations alongside technical remediation.
Capture delayed decisions, missing evidence and the capabilities that failed to scale.
Exercise scenarios requiring action in hours, not weeks, and be prepared to redirect resources as exposure and potential impact change.

Build resilience

Companies cannot predict or prevent every technology disruption. Resilience is the ability to absorb a shock, maintain critical operations and recover with confidence.

Build physical resilience into digital growth

Every digital service ultimately depends on something physical: hardware, data centers, telecommunications, water and power. AI is increasing dependence on, and demand for, this infrastructure. At the same time, attacks, geopolitical events, energy constraints, supplier concentration and long hardware replacement lead times can create additional points of failure.

Companies should understand where single points of failure exist: critical dependencies whose loss could disrupt an essential service without a readily available alternative. That could be a data center, source of power, telecommunications provider, critical hardware component or supplier.

The question is whether the business could continue operating if one suddenly became unavailable. Cyber and physical resilience can no longer be managed separately.

Identify the physical dependencies behind critical services.
Reduce concentration and build redundancy where the potential impact warrants it.
Understand hardware replacement lead times and establish viable alternatives before they are needed.

Identify and reduce single points of failure

The disciplined response has three steps: identify the dependency, evaluate the business impact of its loss and act where the potential impact warrants it.

Identify: Map the technology, infrastructure, facilities, data and suppliers behind the most critical services.
Evaluate: Determine how long each service can tolerate the dependency being unavailable and what customers or operations would be affected.
Act: Reduce concentration, build redundancy, secure alternatives or create a credible recovery path.

Not every dependency requires full duplication. Investment should reflect potential impact, recovery objectives, replacement lead times and the practicality of alternatives. The CEO’s role is to ensure that the largest concentrations are visible and that accepted exposure is deliberate

Prioritize the dependencies whose loss would have the greatest business impact and fund the appropriate redundancy, alternatives or recovery path.
Make accepted exposure explicit, owned and time-bound.

Design for resilience. Prove it works.

Continuity plans cannot compensate for architecture that allows one weakness, supplier failure or infrastructure disruption to put critical operations at risk. Resilience must be built into products and services, then proven through testing.

Design critical services to contain failure, preserve essential functions and recover without relying on the component that failed. Use segmentation and containment to limit impact, build redundancy where warranted, design for graceful degradation and establish viable alternatives that can be activated within the required business timeframe.

Then test it. Plans and executive assurance do not demonstrate resilience. Testing does. Exercise failover and recovery under realistic conditions and prove that critical operations can continue, data can be restored and used, and alternate systems, providers or facilities can carry the required workload.

Testing should expose where reality falls short of design: how long recovery actually takes, which services miss their targets, what constraints emerge and what remains unresolved.

The goal is not to prove that disruption can always be prevented. It is to prove that the company can take a hit, keep its most critical operations running and recover with confidence.

Build resilience to contain failure and preserve essential operations.
Test recovery under realistic disruption scenarios, including loss of key technology, infrastructure or suppliers.
Use recovery performance to expose gaps and strengthen architecture, controls and investment.

What comes next

The pace will not slow. More capable models will accelerate vulnerability discovery and exploitation. As these capabilities become more widely available, the volume and complexity of cyber and technology events will increase.

Organizations must change with the environment. There is no room for complacency. Assumptions, timelines and controls that worked before need to evolve.

Reset the tempo. Identify material risks early, understand the potential impact and be prepared to shift priorities and resources when the risk changes. Move faster on what matters most. The organizations that succeed will not be those that predict every threat. They will be those that reduce accumulated risk, make decisions faster, contain failures when they occur and recover before disruption becomes a crisis.

Disclaimer: This content is provided for informational purposes only and does not constitute professional, technical, or legal advice. JPMorganChase and its directors, officers, employees, and agents make no representation or warranty as to the accuracy or completeness of the information. To the fullest extent permitted by law, JPMorganChase shall not be liable for any loss or damage arising from the use of, or reliance on, this content, or from any errors or omissions in it.