Credits: what they are and how they are consumed
Last updated: October 19, 2026
Your Strike plan is measured in credits. Each run consumes credits from your plan. How many it consumes depends on the testing type you configured.
Testing types and how each one consumes credits
When you configure a Threat Emulation, you choose between three testing types. All of them consume credits from the same plan:
Testing type | What it does | How it consumes credits |
|---|---|---|
Full security | Tests the entire surface included in the scope, with the recurrence you configured | Based on the paths in scope, the depth, and the number of runs per year |
Focused | Performs a one-time run on a specific target | A fixed amount per run |
Change-based | Runs automatically when there are changes in your repository | A fixed amount for each run triggered by a PR or a release |
Full security
Consumption is calculated with three variables:
Paths in scope × depth × runs per year
Paths in scope: the number of paths included in the Threat Emulation. If you exclude paths, consumption goes down.
Depth: Medium multiplies by 1 and Deep multiplies by 2.
Runs per year: these depend on the recurrence. Monthly equals 12 runs per year, quarterly 4, and semiannual 2. With recurrence turned off, it is a single run.
Example: a Threat Emulation with 40 paths in scope, Deep depth, and quarterly recurrence consumes 40 × 2 = 80 credits per run, that is, 320 credits per year.
Human hacking. If you turn on the Human hacking switch, each run adds a human review, which has a fixed value in credits. That value is multiplied by the number of runs per year. For example, with monthly recurrence, in How it is calculated you will see × 12 human reviews.
Focused
A Focused Threat Emulation runs only once, it is not recurring. Each Focused run consumes a fixed amount of credits, from the same plan as the rest of your Threat Emulations.
Change-based
In a Change-based Threat Emulation, each change in your repository triggers a run based on the trigger you configured: for each PR or for each release.
Each run consumes a fixed amount of credits, which is the same for PRs and releases. It does not depend on the size of the change: a small PR and a large one consume the same. When you configure it, the platform shows you that amount per run.
This means total consumption over a period depends on how many PRs or releases are created in your repository. Credits come from the same plan as the rest of your Threat Emulations, not from a separate pool.
Other modules and services
In addition to Threat Emulations, these modules and services also consume credits from your plan:
Strike Cloud: when you activate the module, a number of credits is deducted once per year.
Projects: when quoting each project, the Strike team tells you how many credits it will consume.
Where to see your credits
When configuring a Threat Emulation. While you define the scope, the testing type, the depth, and the recurrence, the platform shows an estimate of consumption that is recalculated with every change. In How it is calculated you can see the calculation details.
In your plan section, in Settings. There you can see:
The total credits in your plan and the validity dates.
Available credits, projected credits (what is already scheduled), and consumed credits.
Consumption broken down by testing type or by Threat Emulation.
When credits are consumed
In Threat Emulations, credits are consumed when Strike's AI agent starts the run. Creating or configuring a Threat Emulation does not consume credits.
Action | Does it consume credits? |
|---|---|
Scheduled Full security run | Yes |
Human hacking turned on | Yes, one human review per run |
Additional run outside the recurrence | Yes |
Focused run | Yes |
Change-based run | Yes |
Canceled run | Yes |
Strike Cloud activation | Yes, once per year |
Projects | Yes, based on the quote for each project |
Pre-flight Check | No |
Automatic retest | No |
What happens if you run out of credits
If your plan runs out of credits, Threat Emulations are paused automatically and the platform shows a message. To resume testing, contact your CSM to add credits to your plan.
Frequently asked questions
Why does one Threat Emulation consume more credits than another?
It depends on the testing type. In Full security, consumption depends on the number of paths in scope, the depth, the recurrence, and whether Human hacking is turned on. In a Change-based Threat Emulation, it depends on how many PRs or releases trigger runs.
How can I reduce consumption?
In Full security you can exclude paths from the scope, choose Medium depth, or use a less frequent recurrence. Changes apply from the next run.
Does a Change-based Threat Emulation have its own credits?
No. It consumes from the same plan as the rest of your Threat Emulations.
Does the Pre-flight Check consume credits?
No. Credits are only consumed once the run starts.
If I cancel a run, do I get the credits back?
No. The credits for a canceled run are consumed anyway. For more details, see How to pause a Threat Emulation or cancel a run.