Mobilization (in CTEM)

What is mobilization in CTEM?

Mobilization is the fifth and final phase of continuous threat exposure management: getting validated exposures actually remediated by the teams that own them. It covers ownership, routing, approval, execution and proof of closure — everything between knowing what should be fixed and it being fixed.

Key takeaways

• Mobilization is where CTEM programs stall. Scoping, discovery, prioritization and validation all produce artifacts security controls. Mobilization requires work from teams that do not report to security.
• It is an organizational problem wearing a technical costume. The blockers are ownership, change windows, risk of breakage and competing priorities, not the absence of a list.
• Ownership is the precondition. An exposure that cannot be attributed to a current, accountable owner cannot be mobilized at all, only escalated.
• Friction is the design constraint. Every step that asks an owner to leave their existing workflow reduces the probability the fix happens.
• It ends in proof, not in dispatch. A closed ticket is not a closed exposure. Patches fail silently, deployments roll back, and controls get bypassed.

Why it matters

Gartner's CTEM framing is widely adopted and the first four phases are well served by tooling. Mobilization is not, and the evidence shows it: the median time to fully remediate a CISA KEV vulnerability is 43 days, and only 26% are ever fully fixed (Verizon 2026 DBIR). Those numbers describe organizations that already know which vulnerabilities matter most — KEV is the least ambiguous priority list in security.

That is the diagnosis. When the highest-confidence, most-publicised, government-catalogued exposures still take six weeks and mostly do not complete, the missing capability is not better identification.

Where mobilization sits in the CTEM cycle

Gartner's continuous threat exposure management framework describes a five-phase cycle. Mobilization is the last of them, and the only one whose output is a change in the environment rather than a change in what the security team knows.

• Scoping. Deciding which parts of the business are in the program — attack surfaces, business systems, third parties — rather than defaulting to whatever the scanners already cover.
• Discovery. Finding the assets, identities, repositories and services inside that scope, including the ones no inventory records.
• Prioritization. Ordering what was found by likelihood and business impact, so effort concentrates where it changes the outcome.
• Validation. Confirming that the prioritized exposures are genuinely exploitable in this environment, and that the controls already deployed would not stop the technique.
• Mobilization. Getting the validated exposures fixed by the teams that own them, and confirming that they closed.

What mobilization actually requires

• An owner who is current. Not the person recorded at provisioning. The team that has actually been raising and closing work against this asset or repository.
• A fix that fits their process. IT works in patch cycles and change windows; developers work in pull requests and sprints; cloud teams rebuild rather than patch. One exposure, several different correct artifacts.
• A credible request. A large share of vulnerabilities are resolved by the owner's routine cadence anyway. Subtracting those is what makes the remaining requests worth the owner's attention.
• Coverage for the gap. Most things cannot be fixed immediately. Something has to reduce risk between the decision and the change window.
• Verification. Confirmation that the patch applied, the pull request merged and deployed, and the finding is gone from the next scan.

Why the handoff is the failure point

Security sees everything and controls nothing. A security team cannot patch a box or merge a pull request itself, so every exposure has to cross an organizational boundary to be closed. Each crossing is a place the work can stop: a ticket in the wrong queue, an owner who left, a change that needs a window nobody has requested, a fix nobody can confirm is safe.

The tooling market has largely optimized the wrong side of that boundary. A better dashboard improves security's view of the queue; it does nothing to the owner's cost of acting. The move that works is the opposite one — meet the owner inside the process they already run instead of asking them to adopt a new one.

A worked example: one exposure, four delivery paths

Consider a single vulnerable library — a widely used serialisation or TLS package — that turns up on the standard workstation image, on a fleet of internal application servers, inside a container base image, and in the dependency manifest of a customer-facing service. One CVE, one severity score, one entry in the KEV catalog. Four completely different pieces of work.

On the workstations the fix is a package version bumped in the endpoint management tool and picked up in the next patch cycle, and nobody needs to be asked. On the servers it is a change record, a maintenance window and a restart, owned by an infrastructure team whose window is monthly. In the container estate nothing is patched at all: the base image is rebuilt, the tag is bumped and the workloads are redeployed, which is a platform-team pipeline change. In the application it is a version bump in a manifest, a pull request, a test suite that has to pass and a release train.

Mobilization is the discipline of producing four correct artifacts from one finding and tracking four independent closures. A program that emits one ticket per CVE into one queue has already lost three of the four, and the exposure stays open in three of the four places.

Measuring mobilization

Discovery-side metrics — findings identified, coverage percentage, mean time to detect — say nothing about mobilization and can improve while it gets worse. The metrics that describe this phase are closure-side: time from validated exposure to verified closure, the proportion of validated exposures that reach an accountable owner, the proportion confirmed closed rather than marked closed, and the size of the exposure window on the items that could not be fixed immediately.

Each of those is uncomfortable to publish, which is a reasonable sign that they are the right ones.

FAQ

Is mobilization just remediation with a different name? It is broader. Remediation is the change itself. Mobilization includes finding the owner, routing the work into their process, covering the interval before the change ships, and verifying it landed.

Who owns mobilization — security or IT? Neither alone, which is the difficulty. Security owns the decision about what must be fixed; the asset or code owner owns the execution. Mobilization is the quality of the interface between them.

Can mobilization be automated? Parts of it. Ownership attribution, impact analysis and change preparation automate well. The approval and the change window generally stay with the owner, and most organizations want it that way.

Sources

• Gartner, continuous threat exposure management (CTEM) framework and phase definitions, 2022-2026.
• Verizon, 2026 Data Breach Investigations Report.
• Cybersecurity and Infrastructure Security Agency, Binding Operational Directive 22-01 and the Known Exploited Vulnerabilities Catalog, 2021.
• NIST, SP 800-40 Revision 4: Guide to Enterprise Patch Management Planning, 2022.
• Axelos, ITIL 4 change enablement practice guidance, 2019.