Continuous penetration testing can replace much of red team work

At a glance

What this is: This article argues that continuous penetration testing can cover most repeatable red team functions by automating discovery, exploitation, credential abuse testing, and multi-stage attack chaining.

Why it matters: It matters because security and identity teams need testing that tracks fast-moving cloud, app, and credential exposure without relying on annual engagements that miss new risk between cycles.

By the numbers:

• Most organizations test only around 20 percent of their attack surface in a given year, leaving large gaps between engagements.
• A manual penetration testing engagement typically costs $2,400 to $10,000 per app, with a two-plus-week lead time.

👉 Read FireCompass's analysis of continuous penetration testing without a standing red team

Context

Point-in-time penetration testing creates a governance gap because modern attack surfaces change continuously while many assurance programmes still operate on annual or quarterly cycles. In practice, that leaves shadow apps, newly exposed APIs, and leaked credentials outside the testing window. For identity security teams, the same gap appears when exposed credentials, reused tokens, or over-broad access paths are not revisited until the next scheduled engagement.

Continuous penetration testing tries to close that gap by turning testing into a recurring control rather than a one-off project. The article’s core claim is that discovery, exploit validation, and attack chaining can be automated for much of the work, while human judgment remains necessary for novel attack paths and social engineering. That balance is typical of where mature assurance programmes are heading, not an edge case.

Key questions

Q: What breaks when penetration testing is only done annually?

A: Annual testing breaks down when environments change faster than the assessment cycle. New code, cloud resources, identities, APIs, and integrations can appear after the test and remain untested for months. The result is stale evidence that supports decisions about an environment that no longer exists, which is especially dangerous in cloud and identity-heavy programmes.

Q: Why do leaked credentials matter so much in attack path testing?

A: Leaked credentials matter because they let an attacker move from discovery to authenticated abuse instead of stopping at a public-facing flaw. Once a credential is valid, the next risk is reuse across apps, privilege escalation, and lateral movement. That is why identity and attack-surface teams need to treat credential exposure as a path, not an isolated event.

Q: What signs show that automated pentesting is producing noise instead of value?

A: A platform is likely producing noise when it only emits alerts, lacks reproduction evidence, or cannot show how separate findings connect into a realistic attack path. High false positives, missing proof-of-concept detail, and no visibility into chainable compromise are strong indicators that the tool is scanning rather than validating risk.

Q: Should security teams replace human red teams with automation?

A: No. Automation should absorb the repeatable work, including discovery, exploit validation, and routine chaining, while humans focus on novel attack paths that require judgement, creativity, and context. The best programme uses automation to increase frequency and humans to increase depth where the highest-value adversary thinking is still needed.

Technical breakdown

Zero-knowledge attack surface discovery

Zero-knowledge discovery means starting from the attacker’s perspective rather than from a curated asset list. The platform enumerates external assets, shadow apps, forgotten subdomains, API endpoints embedded in code, and leaked credentials without requiring prior inventory quality. That matters because most organisations’ declared inventories lag reality, especially in environments where development, acquisitions, and third-party integrations constantly add new exposure. In identity terms, this is the same discovery problem that appears when service endpoints, tokens, and externally reachable admin surfaces exist outside governance workflows.

Practical implication: continuously discover externally exposed assets from an attacker view, not from the CMDB alone.

Working proof-of-concept validation versus alert-only scanning

A scanner can tell you something might be wrong, but a red team function proves whether the weakness is actually exploitable. The article distinguishes alert generation from validated proof-of-concept exploits, which include reproduction steps and demonstrated impact. That difference is operationally important because triage volume collapses when every finding is accompanied by evidence. In practice, this shifts teams from debating theoretical risk to prioritising exploitable paths, including identity-adjacent issues such as leaked credentials, session abuse, and authentication bypass opportunities.

Practical implication: require exploit evidence for remediation priority, not just severity scoring or detection output.

Attack chaining across apps, APIs, and identity

Attack chaining is the step where individual findings become an end-to-end compromise path. One exposed credential may not be catastrophic on its own, but if it unlocks an admin panel, which then pivots into internal infrastructure or directory services, the risk changes materially. The article maps this to MITRE ATT&CK because attackers do not stop at a single defect. For practitioners, the important question is whether testing can reason across findings and connected trust relationships, not merely enumerate isolated vulnerabilities.

Practical implication: test for chained compromise paths that combine application exposure with identity and lateral movement risks.

Threat narrative

Attacker objective: The attacker objective is to turn a small external weakness into a chained compromise path that reaches internal systems, credentials, or sensitive data before defenders notice.

1. Entry begins with externally exposed assets, leaked credentials, or newly deployed APIs that attackers can find before the next scheduled pentest.
2. Escalation happens when a valid credential, session token, or exploitable flaw grants access to higher-value systems or internal administrative surfaces.
3. Impact follows when chained findings enable lateral movement, data access, or control of connected infrastructure before defenders retest the changed environment.

NHI Mgmt Group analysis

Continuous testing is becoming a control problem, not a tooling preference. Annual or quarterly pentests cannot keep pace with cloud-native application churn, shadow apps, and credential exposure that appear between engagements. For security programmes, the real question is whether assurance can be made continuous without collapsing into noise. That shift aligns naturally with NIST CSF and MITRE ATT&CK thinking, where visibility and validation must track adversary tempo. Practitioners should treat continuous testing as part of exposure management, not as a replacement for all human-led red teaming.

Attack chaining is the named concept that separates scanning from adversary simulation. A point finding is useful only if it can be connected to a realistic path that crosses apps, APIs, identity, and internal trust boundaries. That is why multi-stage reasoning matters more than raw alert counts. The article reinforces a broader security truth: exploitability is contextual, and identity paths often turn isolated defects into material compromise. Practitioners should evaluate whether a platform can model chainable risk, not just detect it.

Identity exposure remains the hidden hinge in continuous testing programmes. The article’s credential abuse and session token examples show that many practical attack paths are really identity failures in disguise. That means NHI and IAM governance cannot sit outside penetration testing design. Service accounts, API keys, tokens, and reused credentials need to be part of the testing scope because they are often the fastest route from exposure to impact. Practitioners should integrate identity surfaces into every continuous testing cycle.

Human judgment still matters where automation stops. Automation can cover discovery, exploitation, and repeatable chaining, but novel attack paths, social engineering, and physical-world judgement remain human strengths. That boundary matters because programmes that overclaim autonomy tend to overtrust their coverage. Mature teams should use automation to compress the repeatable work and reserve experts for high-value adversarial creativity. Practitioners should design for complementarity, not replacement.

What this signals

Shadow exposure and credential drift are now programme risks, not occasional exceptions. Continuous testing only works when it is tied to release cadence, identity changes, and external exposure monitoring. The practical lesson for teams is to link testing triggers to asset creation, credential events, and new integrations so that assurance follows change rather than calendar time.

Attack chaining should become a review criterion for exposure-management platforms. If a tool cannot explain how an external finding becomes an identity or network compromise, it is only partial assurance. For practitioners, that means platform selection should ask not just whether the tool finds defects, but whether it can prove business-relevant compromise paths with enough fidelity to drive remediation.

The next maturity step is to treat continuous pentesting as one layer inside a broader exposure programme that includes identity governance, secrets management, and validation after every material change. That is where continuous validation becomes defensible for boards and operational teams alike.

For practitioners

• Map the continuously changing attack surface Start from external discovery, not inventory trust. Reconcile what the platform finds with shadow apps, forgotten subdomains, and newly exposed APIs after every significant release.
• Require proof-of-exploit for every high-priority finding Prioritise validated findings that include reproduction steps and demonstrated impact, especially where credentials, tokens, or authentication paths are involved.
• Include identity surfaces in testing scope Add service accounts, API keys, session tokens, and admin panels to every continuous testing cycle so identity abuse is not left outside the programme boundary.
• Test chained compromise paths, not isolated defects Ask whether a single external weakness can pivot into internal access, directory services, or data exposure before the next test run.
• Reserve human red team time for novel attack paths Use automation for repeatable discovery and exploitation, then schedule expert-led exercises for social engineering, zero-day hypotheses, and unconventional lateral movement.

Key takeaways

• Point-in-time pentests create stale assurance when applications, APIs, and credentials change faster than the next scheduled review.
• Continuous testing adds value only when it validates exploitability and chained attack paths, not when it merely increases alert volume.
• Identity surfaces matter inside pentesting because leaked credentials, tokens, and admin access often turn small defects into real compromise.

Key terms

• Continuous Penetration Testing as a Service: A delivery model that runs penetration testing as an ongoing process rather than a one-time engagement. It uses change detection, human validation, and remediation loops to keep security findings aligned with the current environment instead of a stale snapshot.
• Zero-Knowledge Discovery: An attack-surface discovery method that starts without a trusted asset list and instead maps what an external attacker can actually find. It is especially useful when shadow apps, forgotten subdomains, and hidden API endpoints are likely to exist outside normal inventory processes.
• Attack Chain: An attack chain is a sequence of prompts, observations, and tool calls that moves an AI agent from a benign starting point to a harmful result. In agent security, the chain matters more than any single prompt because real risk often emerges only when actions accumulate across steps.
• Proof-of-concept validation: The process of confirming that a security finding can be exploited in a real environment rather than assuming a scan result is actionable. It reduces false positives, improves prioritisation, and makes remediation decisions faster because teams focus on reachable, repeatable attack paths.

What's in the full article

FireCompass's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step workflow for zero-knowledge discovery, exploit validation, and attack chaining across live assets.
• Platform evaluation criteria for false positives, compliance audit trails, and configurable scope guardrails.
• Cost comparison details for manual pentests, in-house red teams, and continuous automated testing.
• Examples of how the platform frames weekly, on-demand, and trigger-based testing cadence.

👉 The full FireCompass article covers the workflow, platform criteria, and cost math in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the operational security gaps that continuous testing often exposes.