TL;DR: 85% of organisations increased security spending this year, yet 56% of security professionals still say budgets are insufficient, exposing a detection-to-resolution mismatch rather than a simple funding problem, according to Pixee. The real constraint is remediation capacity, and that makes automation, consolidation, and exploitability-driven triage more urgent than adding another scanner.
At a glance
What this is: Pixee argues that security spend is rising while remediation capacity, not detection, has become the limiting factor behind growing backlogs and unresolved risk.
Why it matters: For IAM, NHI, and broader security practitioners, this matters because governance breaks when teams can discover issues faster than they can remediate them, turning visibility into backlog instead of reduced exposure.
By the numbers:
- 85% of organisations increased security spending this year, according to Pixee.
- 88% plan to spend even more next year, according to Pixee.
- 56% of security professionals do not believe their budgets are sufficient to counter the risks they face, according to Pixee.
Context
Security budgets can rise without improving security if the operating model still treats discovery as the main problem and remediation as an afterthought. In this article, the key issue is a governance gap between the rate at which organisations surface risk and the rate at which they can actually resolve it.
That gap matters across identity and broader cyber programmes because visibility only creates value when it is matched by action. For NHI, IAM, and security operations teams, the practical test is whether tooling reduces exposure or simply produces more queues, alerts, and unresolved findings.
Key questions
Q: What breaks when security tools generate more fixes than teams can review?
A: The review queue becomes the control failure point. Teams either rubber-stamp changes, which weakens assurance, or ignore them, which leaves vulnerabilities unresolved. Over time, the organisation trains itself to distrust the remediation channel, so even high-quality fixes have to work against an established pattern of dismissal.
Q: Why do higher security budgets still leave remediation behind?
A: Because budget often flows to discovery tools, monitoring layers, and staffing for triage instead of to the workflow, ownership, and automation needed to close findings. If the organisation funds more detection capacity than resolution capacity, it increases the volume of problems without increasing its ability to eliminate them.
Q: What are the signs that a security programme is drowning in tool noise?
A: Common signs include duplicate findings across platforms, large percentages of alerts going unexamined, slow movement from discovery to fix, and analysts spending more time reconciling outputs than reducing exposure. When teams cannot distinguish signal from repetition, the stack has become a workload generator rather than a control system.
Q: How should teams decide whether to invest in more tools or more automation?
A: They should prioritise the option that shortens the path from discovery to closure. If the main constraint is remediation capacity, adding more detection only widens the gap. Automation is the better bet when the organisation already knows what to fix but lacks the throughput to fix it consistently.
Technical breakdown
Detection capacity is outpacing remediation capacity
Modern security stacks are often tuned to find more issues, not to resolve them faster. That creates an imbalance: scanners, telemetry, and triage workflows expand while engineering time, automation, and ownership for fixes remain constrained. The result is a system that can surface risk at scale but cannot convert that visibility into reduced exposure at the same speed. In practice, the bottleneck shifts from discovery to resolution, and every additional finding competes with an already saturated backlog.
Practical implication: measure whether your control stack accelerates fixes, not just findings.
Tool sprawl turns security into a noise problem
When organisations add overlapping tools, they often increase duplicate alerts, inconsistent findings, and manual correlation work. That does not just make dashboards busier. It lowers the signal-to-noise ratio so that high-risk issues are harder to distinguish from low-value output, especially when teams are already short on remediation capacity. Tool sprawl is therefore an operational risk, not just a procurement issue, because every disconnected workflow adds friction to the fix path.
Practical implication: deduplicate findings before they enter remediation queues.
Exploitability-driven triage changes what gets fixed first
A useful response to backlog pressure is to prioritise vulnerabilities by whether they are actually reachable in the target environment. Reachability analysis, authentication boundaries, and segmentation help separate theoretical exposure from issues that can be exploited in practice. That does not remove the need to fix problems, but it helps teams spend scarce remediation capacity on the findings that matter most. This is especially relevant where identity controls, network boundaries, or workload permissions constrain attack paths.
Practical implication: route remediation by exploitability rather than raw scanner volume.
Threat narrative
Attacker objective: The attacker objective is to exploit the organisation’s unresolved exposure faster than its remediation process can close it.
- Entry occurs when unresolved vulnerabilities remain in the environment long enough to be discovered and targeted, while detection teams continue to generate more findings than the organisation can clear.
- Escalation happens when noisy tooling and manual triage delay action on the issues most likely to be exploited, allowing an attacker to move from exposure to usable access before remediation catches up.
- Impact is cumulative: the organisation accumulates security debt, extends its exposure window, and weakens confidence in the controls that were supposed to reduce risk.
NHI Mgmt Group analysis
Security debt is the real governance problem here: when organisations discover more issues than they can fix, they are not failing at visibility, they are failing at control ownership. A mature programme should treat unresolved findings as operational debt with an explicit service level, not as a permanent side effect of better scanning. The practitioner conclusion is to govern backlog reduction as a security outcome, not a hygiene task.
Detection-only investment creates false reassurance: adding scanners and dashboards can make the organisation look more covered while leaving the exposure window unchanged. That is a governance failure because it rewards volume of findings rather than reduction of attack surface. The field needs to stop treating information flow as equivalent to risk reduction. The practitioner conclusion is to tie budget approval to time-to-fix, not tool count.
Exploitability is the named concept that should reset prioritisation: findings that cannot be reached in the current architecture should not consume the same remediation priority as reachable exposure. This does not eliminate the issue, but it changes the order in which scarce engineering time is spent. The practitioner conclusion is to align triage with attack path reality, not with scanner output density.
Security operations now need a resolution layer, not just a detection layer: the article shows that the missing capability is not another signal source, but a mechanism that converts findings into fixes at scale. That is where automation, ownership, and workflow design matter most. The practitioner conclusion is to build remediation throughput as a first-class governance metric.
Budget growth without capacity growth is a structural mismatch: if spending rises mainly in detection categories, teams simply produce a larger queue of unresolved issues. That pattern is visible across AppSec, cloud security, and identity programmes whenever the fix path is underfunded. The practitioner conclusion is to rebalance investment toward the part of the lifecycle that actually closes risk.
From our research library:
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Detection-heavy security programmes now create their own bottleneck: if the organisation keeps adding discovery capacity without a matching fix path, risk reporting becomes faster than risk reduction. For security leaders, the next planning cycle should ask which parts of the stack actually close exposure and which only reveal it.
Exploitability-driven triage is the practical way to cut through backlog pressure: not every finding deserves the same remediation urgency, especially when architecture already blocks many theoretical paths. For practitioners, the governance question is whether prioritisation reflects attacker reach, or merely scanner volume.
For practitioners
- Rebalance spend toward remediation throughput Shift budget review from tool acquisition to the proportion of spend that reduces open findings, closes exposed paths, or automates fixes. Track whether new investment shortens the time between discovery and resolution.
- Measure backlog by exploitability Classify findings by whether they are reachable in the current environment, then prioritise the issues that combine exposure with realistic attack paths. This prevents theoretical noise from consuming the fix queue.
- Consolidate overlapping security tools Inventory duplicate scanners, dashboard layers, and correlation workflows that create repeated findings without improving resolution. Remove tools that add noise faster than they add actionable coverage.
- Automate high-volume remediations first Target recurring, low-complexity fixes where automation can reduce queue pressure, such as standard misconfigurations, repetitive code findings, or policy violations with clear remediation logic.
- Assign explicit ownership for open findings Give each class of finding a named remediation owner and a service-level target so that discovered issues are not left floating between security, engineering, and operations.
Key takeaways
- Security programmes fail when they optimise for finding issues faster than they can fix them.
- The article shows that budget growth alone does not solve a remediation backlog if resolution capacity stays flat.
- Teams need to prioritise exploitability, automation, and ownership if they want spending to translate into lower exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article is about discovery outrunning remediation across vulnerability workflows. |
| Recommendation — Use CIS-7 to make vulnerability remediation throughput a measured operational control. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management | The article centres on vulnerability handling as a governance and operational maturity issue. |
| Recommendation — Apply PR.IP-12 to tie vulnerability discovery directly to closure metrics and ownership. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The piece discusses scanning volume, alert noise, and the limits of discovery without remediation. |
| Recommendation — Use RA-5 with response ownership so scanning output feeds measurable remediation action. | ||
| MITRE ATT&CK | TA0001;TA0004;TA0040 — Initial Access; Privilege Escalation; Impact | Unresolved exposure increases the window for adversary entry, escalation, and operational impact. |
| Recommendation — Map unremediated exposure to TA0001, TA0004, and TA0040 to prioritise exploitable findings. | ||
Key terms
- Detection-Resolution Gap: The detection-resolution gap is the imbalance between how quickly security teams identify issues and how quickly they can correct them. In practice, it is a throughput problem that turns visibility into backlog when alerts, findings, and vulnerabilities arrive faster than fixes.
- Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
- Exploitability-Led Triage: Exploitability-led triage is a remediation method that prioritises weaknesses based on whether they are reachable and can be chained into real attack paths. It is more effective than raw backlog ranking because it ties effort to actual exposure, not just issue count.
- Tool Sprawl: Tool sprawl is the accumulation of overlapping systems that each solve part of the same identity or operations problem. In practice, it creates duplicate workflows, inconsistent policy enforcement, and more manual reconciliation, which weakens confidence in access decisions and slows down secure scaling.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in the context of practical identity control. It helps practitioners connect identity risk to the broader security programme they are responsible for.
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org