Security teams should use on demand testing for newly shipped assets, especially when change is constant and exposure can appear within hours. The goal is to validate what is actually reachable right now, not what was true during the last assessment. Pair that with cloud context so findings can be prioritized by real business risk, not just technical reachability.
Why This Matters for Security Teams
New cloud exposure changes the attacker’s window immediately, which is why waiting for the next scheduled pentest leaves a blind spot between release and review. Teams that rely only on periodic assessments often miss short-lived public endpoints, open storage, permissive security groups, and misconfigured APIs that appear after deployment. Current guidance from CISA and cloud security best practice points toward validating exposure continuously or on demand, then triaging findings by blast radius and asset criticality.
The practical issue is not whether a scan can find something, but whether the organisation can prove what is reachable now, who owns it, and how it fits into the service path. That matters even more when release velocity is high, infrastructure is ephemeral, and security review lags engineering change. In practice, many security teams encounter the weakness only after an internet-facing service is already indexed, probed, or abused, rather than through intentional release-time verification.
How It Works in Practice
On demand testing works best as a release-adjacent control: a new asset is detected, its context is pulled from cloud inventories and tags, and a focused test is launched before or immediately after exposure. The test should not be a generic full-scope pentest. It should verify the asset’s actual attack surface, authentication posture, network reachability, and any direct trust relationships to sensitive data or workloads.
A practical workflow usually includes:
- Detecting new public assets from CSPM, cloud logs, IaC pipelines, or asset inventory.
- Confirming ownership, environment, and business criticality from tags or CMDB data.
- Running targeted checks for exposure, weak authentication, insecure defaults, and data leakage paths.
- Correlating results with exploitability and business impact before assigning severity.
- Feeding validated issues into ticketing, SOAR, or remediation workflows with a clear fix owner.
This approach lines up well with MITRE ATT&CK for understanding likely attacker techniques, because the asset test can be mapped to the same paths an intruder would use after discovery. It also helps to treat cloud context as a first-class input. A weakly protected dev asset is not equivalent to a production endpoint that can reach customer data or privileged control planes. That distinction is where prioritisation becomes operational rather than theoretical.
The most effective teams also set triggers for re-testing after configuration drift, not just after initial exposure. These controls tend to break down when cloud inventories are stale and ephemeral assets disappear before validation completes, because the test never captures the live attack surface.
Common Variations and Edge Cases
Tighter testing often increases operational overhead, requiring organisations to balance faster validation against developer friction and tool noise. For highly dynamic environments, current guidance suggests a tiered model: lightweight automated checks for every newly exposed asset, followed by deeper manual testing only for high-risk services. That is more sustainable than trying to force every cloud change into a traditional pentest queue.
There is no universal standard for this yet, especially where agentic tooling, container churn, or serverless functions create exposure that exists for minutes rather than days. In those cases, security teams may need to test from the deployment pipeline itself, or accept that some validation will be evidence-based rather than interactive. The key is to avoid treating a failed scheduled pentest as equivalent to a clean bill of health.
AI-assisted attack activity adds another layer of urgency. Anthropic’s report on an Anthropic — first AI-orchestrated cyber espionage campaign report underscores how quickly reconnaissance and abuse can scale once exposed assets are found, which strengthens the case for rapid exposure testing rather than periodic review alone. The right model is to validate reachability as part of change, then reserve heavier testing for the assets that justify it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-1 | Newly exposed assets must be identified quickly to reduce blind spots. |
| MITRE ATT&CK | T1611 | Cloud assets should be tested against attacker paths used for container and cloud discovery. |
Keep asset inventory current and trigger testing whenever a new cloud asset becomes reachable.
Related resources from NHI Mgmt Group
- How should security teams reduce AWS data security risk without slowing cloud operations?
- How should security teams limit cloud access without slowing delivery?
- How should security teams reduce unused cloud permissions without breaking workloads?
- How should security teams handle exposed secrets without breaking production?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
