Blog

Fortifying the enterprise: 10 actions to take now for AI-ready cyber resilience

By the JPMorganChase Global Technology Leadership Team

April 17, 2026

AI is already changing the economics of cyber risk: adversaries are scaling attacks, compressing the time from vulnerability discovery to exploitation and increasing the volume of threats that enterprises face each day. Patch and remediation cycles are accelerating, often exceeding an organization’s capacity for change, leaving them exposed to automated discovery and exploitation by cyber attackers.

The resilience to operate through this technological change requires urgency, discipline, and rigorous execution of foundational security practices. It requires explicit choices to modernize, contain, or exit software and systems, which will 1) reduce the volume of technical debt, and 2) embed security into automated software development and change management practices. This will also help to ensure the easy path is the safe path for development and technology teams. A security-minded organization that trains and educates its technologists and can create capacity to adapt with speed is foundational. After that, the below are some of the top actions an organization can take to build stronger cyber resilience.    

A comprehensive cybersecurity program requires dedicated efforts beyond what is described here. For focus, these are the highest value tasks we should be doing today to prepare for an environment where vulnerabilities will be discovered and exploited at increased volume and speed. Achieving these outcomes is always a work in progress with various stages of maturity toward the goal of continuous improvement.

Run the Latest Software Versions: Legacy systems that run outdated software pose a significant risk, with unpatched flaws in end-of-life software being a primary attack vector.  It’s often difficult to upgrade software when you are multiple versions behind, slowing down your process to react to newly discovered vulnerabilities. 

  • Treat reducing technical debt as an immediate priority and manage it with senior-level oversight. Given the expected volume of newly discovered vulnerabilities, fixes for legacy systems and software may no longer be made available.
  • Replace network and compute hardware before it reaches end of life. Track end-of-life timelines, budget proactively for replacements, and during decommissioning enforce secure data deletion and compliant disposal.
  • Upgrade any unsupported operating systems or enterprise software to supported releases.
  • Upgrade all open-source dependencies to the current stable (community validated) release.  It is important to ensure updates receive community validation and are free from malicious tampering and targeted software supply chain attacks.  Conversely, older packages may not get fixes for newly discovered vulnerabilities.
  • Acquire open source software through a managed, trusted artifact repository.  Use tools to evaluate open source for vulnerabilities.

Manage Assets and Software Components with Reference Data: You cannot fix what you don't know about. Incomplete or inaccurate asset inventories leave blind spots that attackers will find before you do.

  • Maintain a comprehensive, continuously updated inventory of all hardware, software and cloud assets across the enterprise, including shadow technology and developer-provisioned resources.
  • Catalog all software components, including open source using a software bill of materials (SBOM) for every application in your portfolio.
  • Enrich asset records with ownership, business criticality, internet exposure, and data classification so that vulnerability and incident response teams can prioritize with context.
  • Integrate asset and software component data into vulnerability management, change management, and incident response workflows so that when a new threat emerges you can answer "where are we exposed?" in minutes, not days.
  • Regularly reconcile asset inventories with discovery scanning to identify and remediate drift, orphaned resources, and unmanaged endpoints. Automate these processes.

Build and Operate a Robust Vulnerability Management Program: Discovering and remediating known vulnerabilities quickly is foundational, particularly for perimeter-facing software and hardware assets where exploitation is often automated and immediate.

  • Fix known vulnerabilities now, in order of criticality, starting with internet-facing systems to reduce the existing backlog and create capacity for the accelerating volume of new disclosures.
  • Test patches and updates before being integrated into production environments to minimize operational disruption and outages.
  • Establish SLA-driven remediation vulnerability fix and patching timelines tiered by severity and exposure, with the most aggressive targets for critical and internet facing assets. Fix critical internet facing vulnerabilities at the fastest pace you can. When you set a new record, beat it.
  • Scan continuously, not periodically, integrate vulnerability scanning into software development pipelines, cloud workload deployments, and change management processes so that new exposures are identified at the speed of change. If you use AI development tools, use them to scan for vulnerabilities in your code. The latest generally available models are very effective at finding and fixing issues.
  • Correlate vulnerability data with asset criticality, application context and reachability, threat intelligence, and exploit availability to focus effort where risk is highest rather than chasing volume indiscriminately. Use the Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities list (CISA KEV).
  • Where possible, use perimeter controls (i.e. web application firewalls) to mitigate exposure and block attempted attacks while you fix vulnerable software.
  • Report vulnerability aging, remediation velocity, and exception volumes to senior leadership regularly; treat persistent exceptions as risk acceptances that require executive accountability.

Stress Test Incident Response and Resiliency Plans: Plans that have not been exercised under realistic conditions will fail under real pressure. Resilience is proven in practice, not in documentation.

  • Conduct tabletop exercises and live simulations, with scenarios that specifically test the ability to recover from destructive attacks, ransomware, and supply chain compromises.
  • Validate that backup and recovery procedures actually work by performing full restoration tests of critical systems to known-good states, measuring recovery time against business tolerance.
  • Include senior business leadership and legal, communications, and third-party stakeholders in exercises so that decision-making under pressure is rehearsed, not improvised during a real incident.
  • Test assumptions about network segmentation, failover, and manual workarounds. Identify single points of failure and dependencies that only surface during simulated disruption.
  • After every exercise, track and fix findings with rigor. The value of the exercise is in closing the gaps it reveals.

Know Your Major SaaS and Outsourced Dependencies: Critical business processes increasingly rely on third-party platforms and services, a compromise or outage at a key provider is your incident to manage, regardless of where the fault lies.

  • Identify and maintain a current register of all SaaS, cloud, and outsourced service providers that support critical business functions, data processing, or technology operations.
  • Share this dependency information across technology, risk, and business continuity teams so that concentration risk and cascading failure scenarios are visible and understood.
  • Assess each critical provider's security posture, incident response capabilities, and resilience plans; ask direct questions about their patching cadence, access controls, and breach notification commitments.
  • Establish contractual requirements for timely security notifications, right-to-audit provisions, and defined recovery objectives, and verify these commitments are being met, not just documented.
  • Develop contingency and exit plans for your most critical dependencies; know how you would operate, even in a degraded state, if a key provider were unavailable or compromised for an extended period.

Optimize Change Management for Speed: The patching and deployment processes that were designed for quarterly release cycles are now a liability. Every day of delay between a fix being available and a fix being deployed is a day of unnecessary exposure.

  • Map the end-to-end lifecycle of a security patch from vendor release to production deployment; identify every handoff, approval gate, and testing queue that adds latency.
  • Invest in automated testing, staged rollout, and rollback capabilities that allow changes to move to production with confidence and speed, reducing reliance on manual validation cycles.
  • Establish emergency change pathways for critical security patches that can bypass non-essential gates while preserving auditability and safety, speed and control are not mutually exclusive.
  • Measure and report mean-time-to-patch for critical vulnerabilities as a key operational metric; set explicit improvement targets and hold delivery teams accountable.
  • Embed security tooling directly into software build and delivery pipelines; vulnerability analysis, open source dependency scanning, and security configuration checks should run automatically so that security is a built-in quality gate, not a bottleneck.

Aggressively Filter Outbound Traffic from Production Systems: Most production systems have no legitimate need to reach the open internet, restricting outbound traffic creates strong immunity from software supply chain attacks, command-and-control callbacks, and data exfiltration.

  • Implement allow-list-based outbound web traffic filtering for production environments wherever possible; default-deny is dramatically more effective than trying to block known-bad destinations.
  • For systems that require outbound connectivity, restrict access to specific, approved endpoints and protocols, broad internet access from production should be treated as an exception requiring justification and senior approval.
  • Monitor and alert on anomalous outbound traffic patterns, including queries to unusual domains, unexpected data volumes, and connections to newly registered infrastructure.
  • Recognize that this single control would have substantially mitigated the impact of incidents like Log4Shell, SolarWinds, and numerous supply chain compromises, the return on investment is disproportionately high relative to the effort.
  • Test outbound filtering rules regularly and maintain them as part of change management; stale or overly broad exceptions erode the value of the control over time.
  • Segment your end-user environment with more permissive internet access away from production systems.

Remove Standing Privileges from Employee Entitlements: A compromised employee workstation should not automatically provide an attacker with credentials to production systems. Standing privileged access is one of the most reliably exploited paths from initial compromise to critical impact.

  • Implement a privileged access management system with vaulted credentials and/or just-in-time entitlement provisioning for all production maintenance and administrative tasks.
  • Eliminate persistent administrative accounts on endpoints and servers. No employee should have always-on access to sensitive systems as part of their default profile.
  • Require multi-factor authentication and session recording for all privileged access, with time-bound sessions that automatically expire and require re-authorization.
  • Regularly audit and certify entitlements to ensure that access rights reflect current roles and responsibilities; remove orphaned accounts and accumulated or excessively privileged permissions aggressively.
  • Extend the same discipline to service accounts and machine identities, these are frequently overlooked, over-privileged, and among the first credentials targeted in a breach.

Manage Remote Access and Segment Where Possible: Flat networks and broadly shared environments allow attackers to move laterally with ease. Architecting for containment ensures that a single point of compromise does not become an enterprise-wide event.

  • Use strong multifactor access for all remote connectivity, where external devices are joining the network only allow trusted verified devices.
  • Use segmentation when connecting environments of different trust, and where systems do not need persistent connectivity to each other.
  • Authenticate and authorize every connection between systems, and do not assume that traffic originating inside the perimeter is trustworthy.
  • Where possible, design applications and infrastructure so that a compromise in one environment, business unit, or region cannot cascade into others.
  • Regularly test effectiveness of these controls through red team exercises and penetration testing to verify that expectations are realized under adversarial conditions, not just in architecture diagrams.

Embed Security into the AI Development and Deployment Lifecycle: AI is simultaneously a threat accelerant and transformative capability to help you do more work faster. However, organizations must secure their own use of AI with the same rigor (or more!) than any critical system.

  • Incorporate security early into product, technology and AI system design through threat modeling. When using AI to develop software, provide secure reference architectures as context and skills.
  • Treat AI models, training and context data, and inference pipelines as high-value assets that require access controls, integrity monitoring, and audit logging commensurate with their business impact.
  • Validate that AI-generated code, configurations, and recommendations are subject to the same security review and testing standards as human-authored artifacts before they reach production.
  • Assess and monitor third-party AI services and embedded AI features in SaaS platforms for data handling practices, model provenance, and security controls, AI supply chain risk is an extension of software supply chain risk.
  • Establish governance and red-teaming practices for AI systems to identify adversarial manipulation, data poisoning, and prompt injection risks before they are exploited in production.
  • Recognize that adversaries are using AI to accelerate reconnaissance, craft more convincing social engineering, and automate exploitation, invest in AI-augmented defensive capabilities to match the pace of the threat.

Interested in more insight from JPMorganChase?

FOR INFORMATIONAL PURPOSES ONLY