Credits: what they are and how they are consumed
Last updated: October 14, 2026
Your Strike plan is measured in credits. Each execution consumes credits from your plan. How many it consumes depends on the type of testing 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 executions per year |
Focused Test | Runs a one-time test on a specific target | Each execution consumes credits |
Change-Based Testing | Runs automatically when there are changes in your repository | A fixed value for each execution triggered by a PR or a release |
Full Security
Consumption is calculated with three variables:
Paths in scope × depth × executions 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.
Executions per year: they depend on the recurrence. Monthly equals 12 executions per year, quarterly equals 4, and semiannual equals 2.
Example: a Threat Emulation with 40 paths in scope, Deep depth, and quarterly recurrence consumes 40 × 2 = 80 credits per execution, which is 320 credits per year.
Human Hacking. If you turn on the Human Hacking switch, each execution adds a human review, which has a fixed value in credits. That value is multiplied by the number of executions per year. For example, with monthly recurrence, in How it is calculated you will see × 12 human reviews.
Focused Test
A Focused Test is a one-time execution, not a recurring one. It consumes credits every time you run it, from the same plan as the rest of your Threat Emulations.
Change-Based Testing
With Change-Based Testing, each change in your repository triggers an execution according to the trigger you configured: for each PR or for each release.
Each execution consumes a fixed amount of credits, which is the same for PRs and for 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 this value per execution.
For this reason, total consumption in a given period depends on how many PRs or releases are generated 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, an amount of credits is deducted once per year.
Projects: they consume credits based on the number of manual pentesting hours agreed for each project.
Where to see your credits
When you configure a Threat Emulation. While you define the scope, testing type, depth, and recurrence, the platform shows a consumption estimate 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.
The available, projected (what is already scheduled), and consumed credits.
Consumption broken down by test type or by Threat Emulation.
When credits are consumed
In Threat Emulations, credits are consumed when Strike's AI agent starts the execution. Creating or configuring a Threat Emulation does not consume credits.
Action | Does it consume credits? |
|---|---|
Scheduled Full Security execution | Yes |
Human Hacking turned on | Yes, one human review per execution |
Additional execution outside the recurrence | Yes |
Focused Test | Yes |
Change-Based Testing execution | Yes |
Canceled execution | Yes |
Strike Cloud activation | Yes, once per year |
Projects | Yes, based on the agreed hours |
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 automatically paused 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 Change-Based Testing, it depends on how many PRs or releases trigger executions.
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 execution.
Does Change-Based Testing 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 execution starts.
If I cancel an execution, do I get the credits back?
No. Credits for a canceled execution are still consumed. For more details, see How to pause a Threat Emulation or cancel an execution.