AI cybersecurity tools are creating bigger vulnerability backlogs

AI cybersecurity is creating a new remediation challenge for enterprises

AI-powered cybersecurity tools can increase vulnerability alerts by as much as eightfold. For large enterprises, that creates a problem: security teams can discover weaknesses far faster than their organizations can investigate and repair them. The technology may work exactly as intended while the company accumulates more unresolved security findings than its existing teams can handle.

The pressure is growing because attackers are also using AI to move faster. Bain analysis estimates that the time required for a typical cyberattack has fallen from approximately four weeks to about 18 hours. Enterprises therefore face two developments at once: attacks are accelerating, while more capable defenses are revealing weaknesses that require engineering work.

Leading organizations are already responding with larger remediation budgets, changes to security staffing, and greater involvement from developers. Remediation means correcting a vulnerability or reducing the risk it creates. As AI increases the volume of findings, that work depends more heavily on engineering capacity, technology architecture, and supplier relationships.

Bain, which provides cybersecurity consulting and advisory services and therefore has a commercial interest in enterprise security investment, argues that companies need to change how they manage these responsibilities. Its analysis points toward a broader shift in cybersecurity spending, with greater emphasis on the resources and decisions needed to eliminate discovered weaknesses.

AI is finding vulnerabilities faster than companies can repair them

Large companies deploying frontier AI to strengthen their cybersecurity defenses have seen vulnerability alert volumes rise by up to eight times, according to Bain. Each finding may require validation, assessment, assignment to a responsible team, and corrective action. When discovery outpaces those activities, unresolved findings accumulate.

A rising alert count can reflect better visibility into weaknesses that already existed. Security teams learn about vulnerabilities that earlier tools missed, giving them more opportunities to prevent attacks. But that information becomes useful only when organizations can identify the most dangerous findings and address them before attackers exploit them.

The time available to respond is shrinking as AI changes offensive cybersecurity. Attackers with limited programming expertise can now conduct operations with sophistication previously associated with nation-state capabilities. Experienced attackers can compress campaigns that once took weeks into hours, while automation allows fraud operations to run around the clock.

AI also makes established attack methods more effective. Phishing campaigns can generate highly personalized messages at scale, including messages that use QR codes to direct victims to malicious destinations. Voice cloning and real-time video impersonation create additional ways to deceive employees and compromise business processes. High-profile incidents involving frontier AI model testing have further demonstrated the pressure on defenses that rely on human response times.

Beyond these attacks, increasingly autonomous AI agents introduce another category of risk. These software systems can pursue objectives and take actions with limited human involvement, creating opportunities for improper behavior even when their assigned goals are legitimate. Traditional security processes may struggle to anticipate every action an agent could take or the consequences that follow.

Faster attacks and expanding AI workloads make effective defensive scanning increasingly important. Yet broader detection also creates more work for the people responsible for correcting vulnerabilities. Enterprises need a way to distinguish findings that demand immediate action from those that can wait.

Comprehensive scanning requires Risk-Based prioritization

One response to alert overload would be to scan fewer systems. That would reduce the findings teams must process, but it would also leave substantial weaknesses undiscovered. According to findings highlighted by Bain, more than half of an organization’s vulnerabilities exist outside its critical applications.

Focusing scans on the most valuable applications could therefore overlook a majority of vulnerabilities. Attackers can exploit weaknesses in supporting infrastructure and connected systems, even when those systems are considered less important to the business. Enterprises need coverage across legacy platforms, application programming interfaces (APIs), authentication systems, infrastructure, and software dependencies.

Connections between these systems make broad visibility especially important. A weakness in an authentication system may expose several services, while a vulnerable API can provide access to sensitive information or functions within a critical application. Older infrastructure can also remain connected to modern applications long after its original business purpose has changed.

As applications and dependencies evolve, scanning must continue across the environment. Wider coverage produces findings that security analysts must validate, assess, and assign to system owners. AI can accelerate discovery, but the decisions that follow still require security expertise and knowledge of the affected systems.

Leading organizations are addressing this workload by evaluating vulnerabilities against four connected criteria:

These criteria help security teams decide which corrections will reduce the greatest exposure. A vulnerability with high theoretical severity may be less urgent when attackers cannot realistically reach the affected component. Another weakness may demand immediate attention because it is easily exploited and provides access to several important services.

Systemic dependencies can make seemingly minor components especially consequential. A shared software component may support multiple applications, so compromising it could disrupt several business processes. Blast radius describes the extent of that potential damage, helping teams understand how an attack could affect systems beyond the vulnerable component.

Prioritization also changes how organizations interpret their vulnerability backlog, the collection of findings awaiting remediation. Counting unresolved alerts measures workload, but the number alone cannot show how much exposure the company carries. Thousands of low-impact findings may require a different response from a smaller group of vulnerabilities that attackers can readily exploit in critical infrastructure.

Broad scanning and risk-based prioritization work together. Scanning establishes where weaknesses exist, while prioritization determines which ones should receive limited remediation resources first. Once those decisions are made, the organization still needs people with the technical authority and available time to complete the fixes.

The remediation workload is changing security staffing and engineering priorities

The additional work is already affecting cybersecurity budgets. Bain reports that leading enterprises advancing their AI-enabled security capabilities have typically increased remediation spending by double-digit percentages. These increases reflect the personnel and technical effort needed to turn larger volumes of findings into completed corrections.

Higher spending follows from the work involved. Security teams must investigate findings, identify system owners, coordinate changes, and confirm that vulnerabilities have been resolved. Organizations adopting more capable scanning therefore need to budget for the work generated by better detection, alongside the technology itself.

Some leading enterprises have responded by redirecting as much as 20% to 25% of their cybersecurity personnel from other responsibilities toward remediating vulnerabilities identified by AI-powered scans, according to Bain. They have brought in external partners to maintain regular security operations. This allows internal specialists to concentrate on the new findings while established monitoring and defensive activities continue.

Moving up to a quarter of the cybersecurity workforce changes how the department operates. Security employees already support incident response, monitoring, governance, and other defensive responsibilities. Reassigning them creates a capacity gap in those activities, so external support becomes part of the cost of expanding remediation.

Other organizations are increasing dedicated staffing. Bain describes one leading enterprise that tripled the size of its remediation team to handle the additional work. A larger team can investigate more findings, coordinate corrections, and manage complicated cases, but its effectiveness still depends on whether the people controlling affected systems can implement the changes.

For application vulnerabilities, that responsibility often falls to software developers. Infrastructure engineers may need to update configurations, while DevOps teams, employees responsible for connecting software development with deployment and operations, must help test and release changes into production. Those teams also have commitments to new features, service reliability, and routine maintenance.

Remediation capacity therefore depends on engineering schedules. A security team may identify a critical vulnerability and establish its urgency, yet the weakness can remain unresolved if the responsible engineers cannot make time to fix it. Adding security analysts will have limited effect when the constraint lies in development or infrastructure teams.

Some large enterprises are making vulnerability reduction a more explicit engineering responsibility. At one organization cited by Bain, its chief information security officer (CISO) described stricter enforcement of an existing internal guideline requiring developers to spend approximately 30% of their time on proactive vulnerability management. The guideline reserves engineering capacity for identifying and correcting weaknesses before they become urgent incidents.

That allocation is specific to the organization, and the appropriate balance depends on each enterprise’s technology and operating requirements. The broader decision is to treat vulnerability management as planned engineering work. Developers have time to maintain the security of systems they build, while engineering managers must account for remediation when assigning other work.

Developer involvement matters especially when vulnerabilities originate in application design or software dependencies. Security specialists can establish the risk, but developers often understand which corrections are technically feasible and how they affect existing functionality. Their participation allows weaknesses to be addressed through regular development and maintenance processes.

DevOps teams face a related challenge when fixes must reach production. A completed code change may still require testing, deployment scheduling, and coordination with other services. Leading organizations are therefore working to accelerate critical patch deployment, reducing the delay between identifying an urgent exposure and correcting the affected system.

Faster deployment requires clear ownership throughout the process. Security teams establish urgency, developers and infrastructure specialists prepare corrections, and operations teams manage their release. When responsibility is unclear or engineering capacity is unavailable, findings can remain unresolved even after the required technical changes are understood.

Automation can ease some of this workload. Leading organizations are beginning to automate simpler remediation tasks while retaining human oversight. Repetitive, well-understood corrections are suitable candidates because automation can reduce manual effort and free specialists to concentrate on more complicated vulnerabilities.

Automated changes still need safeguards because corrections can affect production applications and infrastructure. A technically valid patch may introduce compatibility problems or disrupt dependent services. Organizations must therefore determine which changes can be performed automatically and which require human review before deployment.

These responses address different limits on remediation capacity. Dedicated teams increase the number of findings that can be processed, while automation reduces repetitive work. Developer and DevOps involvement enables corrections within applications and infrastructure, and external partners help sustain routine security operations when internal staff are reassigned.

The next constraint appears when an organization has enough people to perform a fix but lacks sufficient control over the affected technology. Some systems are difficult to change safely, while others belong to suppliers. Those weaknesses require different decisions from the staffing and process improvements used to manage routine remediation.

Legacy technology and external suppliers create harder remediation problems

Bain’s analysis identifies legacy platforms, network infrastructure, and software-as-a-service (SaaS) providers among the most concentrated and difficult-to-remediate AI-related security exposures. These areas present challenges because organizations may face technical obstacles or depend on external companies to make corrections.

The analysis compares technology categories by their concentration of risk and organizations’ ability to resolve identified weaknesses. It also considers how many surveyed CISOs selected each category as their most consequential unresolved exposure.

The comparison covers six areas:

In Bain’s assessment, legacy platforms, the network layer, and external software providers combine concentrated risk with limited control over remediation. They also account for the largest groups of CISOs identifying them as their most material unresolved exposure.

Modern cloud-native platforms, which are built to operate using cloud infrastructure and services, sit at the opposite end of the comparison. Bain places them in a relatively favorable position for risk concentration and remediation difficulty, with the smallest group of CISOs selecting them as their most consequential unresolved exposure. In-house code and open-source dependencies present different trade-offs involving direct control, compatibility, and maintenance.

These differences matter because remediation depends on the architecture and ownership of the affected technology. A company can schedule changes to software it develops internally, provided engineers have enough capacity. Legacy infrastructure may be much harder to alter, while supplier-controlled systems require cooperation from organizations outside the enterprise.

Legacy systems turn technical debt into security exposure

Legacy platforms show how technology architecture can limit remediation. Enterprises often continue operating older systems because important applications and business processes depend on them. Patching becomes difficult when software is fragile, complex, or connected to components that are no longer maintained.

When immediate correction is impractical, organizations may introduce temporary technical safeguards to reduce exposure. These measures can limit the likelihood or consequences of exploitation while teams investigate longer-term options. But repeated reliance on temporary protections allows underlying weaknesses to persist.

Bain therefore argues that accumulated technical debt should be treated as an active cybersecurity exposure. Technical debt refers to the future maintenance and change costs created by earlier technology decisions, including continued dependence on aging systems. When those systems become difficult to secure, the debt also creates problems for vulnerability remediation.

Reducing this exposure may require retiring or replacing technology that can no longer be patched sustainably. Such decisions often involve substantial investment because the affected platforms support important business operations. Security teams can identify the risk, but executives responsible for technology budgets and business continuity must authorize the necessary changes.

Network infrastructure creates another form of concentrated exposure. Network components connect applications, users, and services, so weaknesses can affect several systems at once. Correcting them may require changes with broad operational consequences, making testing and deployment more complicated than fixing an isolated application.

For both legacy platforms and network infrastructure, technical flexibility affects how quickly the organization can respond. Additional remediation personnel can investigate weaknesses and prepare changes, but the underlying architecture determines how safely those changes can be implemented.

Supplier-controlled software requires continuous oversight

External suppliers create a different limit because the enterprise may have little direct authority over the vulnerable technology. Critical SaaS platforms can be deeply integrated with internal processes, identity systems, and sensitive information. Yet the supplier controls much of the underlying software and infrastructure.

When a weakness originates in that environment, the customer depends on the vendor to investigate and implement a correction. The enterprise can assess the consequences and request action, but its ability to eliminate the vulnerability may depend on the supplier’s priorities and technical capacity.

AI is making this relationship harder to manage. Suppliers may release changes to models and software daily, while many enterprise oversight processes still rely on questionnaires and periodic assessments. A review completed at the start of a contract can become outdated as a vendor introduces new functionality or changes how its systems operate.

New AI capabilities can also change the enterprise’s exposure during an existing supplier relationship. A vendor might alter how information is processed, introduce connections to additional systems, or depend on new external services. Those changes can affect security requirements even when the original product and contract remain in place.

Fourth-party relationships add another layer of dependency. A fourth party is a supplier used by one of the enterprise’s own vendors. These companies may provide technology or services essential to the contracted product, creating security exposure even without a direct contractual relationship with the enterprise.

Managing these dependencies requires better visibility into how suppliers operate and change their systems. Enterprises need continuous assessment for vendors closely integrated with business operations, backed by contractual requirements that make relevant changes visible.

Bain recommends stronger contractual mechanisms, including timely notification of security breaches and material technology changes. Agreements can also require preapproval before vendors introduce new AI deployments, where appropriate, and establish penalties for contractual violations.

These requirements make supplier governance an ongoing responsibility. Procurement, technology, security, and legal teams must coordinate when a vendor changes its systems during an active contract. They also need enough information about fourth-party relationships to identify where consequential exposure may originate.

AI agents add new requirements for security governance

The visibility and ownership problems seen in supplier relationships also apply to AI agents operating inside enterprises. Agents are software systems that use AI to perform tasks and take actions with varying degrees of independence. As companies introduce more agents and AI workloads, they create additional permissions, system connections, and security responsibilities.

Many organizations already struggle to establish how many agents they operate, who owns them, and what actions those agents are authorized to perform. Some also lack reliable ways to disable an agent when its behavior becomes unsafe. These gaps make monitoring and incident response harder because security teams need to know which systems exist before they can control them consistently.

The risk grows more complicated when agents interact with applications, infrastructure, and external services. Their permissions determine which resources they can access, while their configuration influences the actions they can take. Weak controls can allow an agent to behave improperly while pursuing an otherwise legitimate task.

Managing these systems requires enterprises to discover their AI workloads and agents, strengthen their configurations, and monitor their behavior. Security processes must also support threat detection and incident response when an agent creates or encounters a security problem.

Governance, risk management, and compliance controls need to account for the actions agents are permitted to perform. Clear ownership establishes who approves permissions, reviews behavior, and responds to incidents. Reliable shutdown mechanisms give organizations a way to stop unsafe activity when normal monitoring and intervention are insufficient.

Some enterprises have delayed these efforts while waiting for vendors to provide complete solutions. Bain instead advocates combining internally developed controls, purchased technology, and external partnerships. This approach allows companies to address immediate governance weaknesses while adjusting their systems as AI security capabilities develop.

The same flexibility matters across legacy systems, infrastructure, and supplier relationships. Security teams need visibility into weaknesses, but the organization must also have authority to modify systems, restrict agents, and require action from vendors. Where budgets are limited, platforms are difficult to change, or contractual leverage is weak, unresolved vulnerabilities can persist despite increasingly capable detection tools.

These constraints bring cybersecurity remediation into decisions controlled by technology executives and business leadership. A security department can identify exposure and recommend corrective action, but replacing infrastructure, allocating engineering time, and renegotiating supplier agreements require broader authority.

AI cybersecurity investment requires executive accountability

When remediation depends on engineering schedules, infrastructure investment, and supplier decisions, responsibility must extend to the executives controlling those resources. Bain recommends holding chief information officers (CIOs) and chief technology officers (CTOs) accountable for accumulated vulnerability debt alongside cybersecurity leadership. Vulnerability debt is the collection of unresolved weaknesses that continue to expose an organization to security risk.

This approach changes how responsibility is divided. CISOs identify risks, establish security requirements, and communicate priorities. CIOs, CTOs, and engineering leaders must ensure that the teams responsible for affected systems have the resources and authority to implement corrections.

For an enterprise with a backlog of critical vulnerabilities, the first management question is why those weaknesses remain unresolved. Some may require additional remediation personnel or faster patch deployment. Others depend on development work, infrastructure replacement, or intervention with an external supplier.

Executive accountability means making the decisions needed to remove those obstacles. A CISO may establish that a legacy platform presents unacceptable exposure, but the CIO or CTO may control the budget and technical resources required to replace it. Similarly, engineering leaders determine whether developers can allocate enough time to urgent remediation.

Board oversight must reflect these responsibilities. Some leading organizations have already increased the frequency of cybersecurity reporting, and Bain recommends detailed vulnerability reports at least monthly, potentially weekly. Direct board access for the CISO can help ensure that serious unresolved exposures and resource constraints reach the people able to authorize corrective action.

More frequent reporting is useful when it connects security findings to operational decisions. Boards need to understand which consequential vulnerabilities remain open, how remediation is progressing, and whether critical patches are reaching production quickly enough. Reports should also identify resource shortages and weaknesses that require executive intervention.

These measures help distinguish better detection from progress in reducing exposure. An increase in discovered vulnerabilities may indicate that scanning coverage has expanded. A persistent concentration of unresolved high-risk findings, however, can point to insufficient engineering capacity, difficult technology dependencies, or delays in management decisions.

Board reporting should therefore give executives enough information to act on the causes of unresolved exposure. When remediation requires additional personnel, infrastructure investment, or supplier intervention, the relevant decision should be visible alongside the security risk it addresses.

Governance also needs to keep pace with changes in AI technology. Vendor software can be updated frequently, agents can receive additional permissions, and new vulnerabilities can emerge across connected systems. Oversight processes based mainly on infrequent reviews may struggle to respond before those changes affect enterprise security.

Continuous supplier assessment and control over contractual changes consequently become executive responsibilities. Organizations need clear authority to evaluate new AI deployments by vendors, respond to material changes during contracts, and escalate concerns when suppliers fail to meet agreed security requirements.

Investment planning must account for the same operational realities. Bain recommends treating AI cybersecurity modernization as a multiyear commitment that balances technology spending with skilled personnel and operating resources. Scanning capabilities, automation, engineering participation, and external support all affect how quickly an enterprise can resolve the vulnerabilities it discovers.

That commitment also creates a timing decision. Developing remediation processes, reallocating engineering capacity, strengthening supplier agreements, and improving governance take organizational effort. Bain warns that every month of delayed preparation gives competitors additional time to strengthen their defenses.

Enterprises that begin these changes earlier can develop the staffing arrangements, engineering processes, and management controls needed to use more capable AI security tools effectively. For executives, the immediate investment challenge is to determine how much additional remediation work the organization can absorb, who will perform it, and which structural constraints require funded decisions before the next increase in vulnerability discovery.

Final thoughts

AI-powered cybersecurity tools are changing the economics of enterprise security. Organizations can now identify vulnerabilities at a pace that often exceeds their ability to correct them. For business leaders, the challenge is no longer simply improving threat detection. It is ensuring that investments in AI security translate into measurable reductions in exposure.

That requires treating remediation as a business and technology priority rather than a responsibility confined to security teams. CIOs and CTOs must account for the engineering capacity, infrastructure investments, and supplier relationships needed to resolve vulnerabilities. CISOs must establish clear priorities based on exploitability, business impact, and the consequences of leaving weaknesses unresolved.

The financial implications extend beyond cybersecurity budgets. More comprehensive scanning can increase demand for developers, infrastructure specialists, external partners, and technology modernization. Executives must decide where additional spending will reduce the greatest risk and where existing operating models need to change.

For boards and senior leadership, the most useful measure of progress is not how many vulnerabilities AI tools discover, but how effectively the organization reduces its most consequential exposures. That means tracking remediation timelines, assigning clear ownership, and addressing the technical and organizational constraints that prevent critical fixes.

As AI accelerates both attacks and defensive capabilities, the gap between vulnerability discovery and remediation will become an increasingly important measure of enterprise security readiness. Organizations that align detection capabilities with engineering resources, executive accountability, and sustained investment will be better positioned to turn AI cybersecurity spending into meaningful risk reduction.