Security momentum needs flywheels, not static maturity scores

At a glance

What this is: This is an analysis of why security teams should measure momentum with flywheels instead of relying only on maturity scores and lagging metrics.

Why it matters: It matters because IAM, NHI, and broader security programmes need measurement models that show whether controls are compounding risk reduction, not just documenting compliance state.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Abstract Security's interview on security flywheels and momentum measurement

Context

Security momentum is the gap between having controls in place and knowing whether those controls are reinforcing one another over time. In identity and security programmes, static maturity models can show compliance state, but they rarely show whether privileged access, secrets governance, and detection workflows are becoming easier to operate or harder to bypass.

For IAM and NHI teams, that distinction matters because many control decisions create feedback loops. Better lifecycle management can reduce risk, improve audit evidence, and free capacity for more targeted remediation. The article’s starting point is typical for senior security leadership, but the useful insight is that measurement should expose drag and compounding effects, not just scorecards.

Key questions

Q: How should security teams measure whether security controls are creating momentum?

A: Measure momentum by pairing a leading indicator with a lagging outcome for each major control loop. For example, track telemetry coverage alongside detection speed, or entitlement review completion alongside remediation time. If the leading signal improves but the outcome does not, the loop has drag and the investment is not compounding.

Q: Why do maturity scores often miss the real state of a security programme?

A: Maturity scores show whether a capability exists, but they rarely show whether it is reinforcing other controls or creating operational friction. A programme can look mature on paper while still being slow to remediate, hard to operate, or dependent on manual work that erodes its value.

Q: What do security teams get wrong about appsec metrics?

A: They often measure the number of vulnerabilities found instead of the speed and consistency of remediation. High finding counts can reflect better detection, not better security. The more useful signals are time to remediate, closure rates, and whether teams are fixing issues in the workflow that produced them.

Q: How do teams know if IAM lifecycle controls are working?

A: They should be able to prove that accounts are provisioned and removed on schedule, that access changes are logged, and that stale entitlements are rare. If deprovisioning is incomplete or audit evidence is fragmented, lifecycle control is failing even when the front-end access experience looks smooth.

Technical breakdown

Why maturity scores miss security momentum

Maturity frameworks such as NIST CSF and ISO-style assessments are useful for benchmarking capability, but they are snapshots. They tell you whether a control exists, not whether the control is accelerating better outcomes in adjacent parts of the programme. A flywheel model adds direction and feedback: a stronger guardrail can improve telemetry quality, which improves response, which in turn strengthens the guardrail. That is more useful for executive decision-making than a one-time score because it shows whether the programme is becoming easier to operate and harder to defeat.

Practical implication: use maturity scores for baseline reporting, but add loop-based measures that show whether controls are reinforcing one another.

Leading indicators versus lagging indicators in security

Leading indicators are the signals that momentum is building, such as telemetry coverage, pre-commit scanning, or audit issues closed on time. Lagging indicators show business impact, such as MTTR, residual risk, fewer late-stage defects, or improved customer trust. The problem is not that lagging metrics are wrong, but that they arrive too late to guide investment in the right place. A good flywheel connects both, so teams can see which actions create compounding value and which ones merely generate activity.

Practical implication: pair one operational leading indicator with one outcome metric for every control loop you track.

What creates drag in security programmes

Drag is any friction that slows the loop, such as alert fatigue, false positives, tooling overhead, manual evidence collection, or developer resistance. In identity programmes, drag often appears when governance steps are too heavy to sustain or when entitlement reviews generate work but not risk reduction. The point is not to eliminate every friction point, but to identify which ones block compounding effects. That shifts attention from generic improvement to targeted redesign of the places where effort is being wasted.

Practical implication: map each programme loop for specific drag points and remove the ones that break feedback before adding more tooling.

NHI Mgmt Group analysis

Security momentum is now a governance problem, not just a measurement problem. Static maturity models can prove that controls exist, but they do not show whether those controls are compounding risk reduction across the programme. That matters in identity-heavy environments where access decisions, evidence collection, and response workflows influence each other. Practitioners should treat momentum as a governance signal, not a reporting flourish.

Flywheels are a better mental model for NHI governance than isolated control checks. Secret rotation, access review, and detection quality are not independent events when workloads, service accounts, and AI systems depend on them together. If one loop improves another, the programme gains resilience; if one step creates manual drag, the whole system slows. The useful conclusion is to measure the reinforcement effect, not just the control.

Fragmented identity operations create drag that can hide behind good-looking metrics. A team may close audits on time while still carrying excessive manual work, stale privileges, or slow remediation. That is especially true in NHI and machine identity programmes, where volume and speed can overwhelm review-based governance. Practitioners should ask whether the operating model reduces friction or merely documents it.

“Compounding resilience” is the right named concept for modern security leadership. The article’s core insight is that security value emerges when one control strengthens the next, creating a reinforcing loop instead of a series of disconnected tasks. That idea is especially relevant to IAM, PAM, and NHI governance because lifecycle decisions, privilege control, and telemetry all feed back into one another. Teams should design for compounding outcomes, not just control completion.

Flywheel thinking should reshape how boards evaluate security investment. Executives do not need another scorecard that proves effort. They need evidence that spending on identity, detection, or remediation is making later work faster, cheaper, and more defensible. That changes the conversation from compliance theatre to operational leverage. Practitioners should present control loops as a business system, not as a collection of isolated metrics.

What this signals

Compounding resilience is the operating model security teams should now optimise for. When identity and secrets controls shorten remediation cycles, improve evidence quality, and reduce manual work, the programme gains leverage instead of simply adding more process. That is where lifecycle discipline starts to matter for executive credibility, not just audit readiness.

Security leaders should expect more pressure to prove that controls change outcomes, not only posture. In identity-heavy environments, the real signal is whether better governance reduces friction across provisioning, review, rotation, and offboarding. The article points toward a model where measurements must show acceleration across the loop, not just compliance at a point in time.

For practitioners

• Map one control loop end to end Pick a high-value loop such as detection to response or access review to remediation. Define the leading indicator, the lagging indicator, the accelerant, and the drag point so the team can see where momentum is created or lost.
• Replace isolated metrics with paired measures For every major security control, track one leading signal and one outcome signal. That makes it easier to tell whether the activity is producing compounding value or just generating reporting volume.
• Identify and remove the biggest drag point first Look for manual steps, false-positive-heavy workflows, and evidence-gathering overhead that slow the loop. Remove the highest-friction bottleneck before adding more tooling or more review steps.
• Use lifecycle evidence to show security momentum In IAM and NHI programmes, show how provisioning, rotation, and offboarding improvements change downstream detection, audit effort, and remediation speed. That makes the business impact visible instead of implied.

Key takeaways

• Static maturity scores can hide whether a security programme is actually gaining momentum.
• Identity and secrets controls create value when they reinforce one another, not when they are measured in isolation.
• Teams should prioritise loop-based metrics that expose drag, acceleration, and downstream impact.

Key terms

• Security Flywheel: A security flywheel is a reinforcing loop in which one control improvement strengthens the next one, creating compounding benefit over time. In practice, it links leading indicators, operational actions, and business outcomes so teams can see whether the programme is accelerating or slowing down.
• Leading indicator: A leading indicator is a measure that helps predict or influence a future outcome before the final result is visible. For identity teams, it can show whether a control is getting weaker or stronger early enough to prompt action, which makes it useful for prevention rather than post-incident reporting.
• Lagging indicator: A lagging indicator records what has already happened, so it is best for understanding results after the fact. In identity management, examples include completed reviews, detected leaks, or turnover-like outcomes, which are useful for trend analysis but cannot by themselves stop access risk from growing.
• Drag Point: A drag point is a source of friction that slows a security loop and reduces the benefit of otherwise good controls. It can be manual work, false positives, process overhead, or resistance from developers and operators. Identifying drag points helps teams redesign for momentum rather than volume.

What's in the full article

Abstract Security's full article covers the operational detail this post intentionally leaves for the source:

• The specific flywheel examples Jess Jimenez uses to connect detection, response, and confidence in practice.
• The way leading indicators and lagging indicators are paired to show whether security investment is compounding.
• The discussion of accelerants and drag points that helps teams decide where automation or process redesign will matter most.
• The leadership guidance on presenting momentum-based measures to boards and executives.

👉 The full Abstract Security post expands the flywheel examples, leadership framing, and metric categories behind the model.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to broader security operations and governance outcomes.