For years, security programs in regulated industries were built almost entirely around prevention: firewalls, endpoint controls, email filtering, and awareness training meant to stop an attacker from ever getting a foothold. That model still matters — but treating it as the whole strategy leaves a dangerous blind spot. Anonymized findings from a 12-month engagement with a mid-market financial services firm illustrate why.

The Engagement

The client — a mid-market financial services firm subject to state and federal regulatory oversight — had invested heavily in perimeter and endpoint prevention controls and had passed every compliance-driven vulnerability scan for two consecutive audit cycles. Leadership reasonably believed their prevention posture was strong. NightShade was engaged to run a 12-month program combining periodic red team operations with an assumed-breach methodology: rather than starting from "outside the perimeter," selected engagements started from a simulated foothold already inside the network, mirroring what happens after a successful phishing click or a compromised third-party credential.

What Assumed Breach Found

Starting from an assumed foothold reframed the entire assessment. Instead of asking "can an attacker get in," the operative question became "what can an attacker do once they're already in — and how long until someone notices?" That reframing surfaced issues the prevention-focused program had never been positioned to catch:

  • Flat internal segmentation: A single compromised workstation had a viable, unmonitored network path to systems handling sensitive customer financial data — a path that no external scan would ever exercise.
  • Stale privileged credentials: Service accounts with domain-admin-equivalent rights had not been rotated in over three years and were reachable via common lateral-movement techniques from a standard user context.
  • Detection gaps in "normal" internal traffic: Lateral movement using legitimate administrative tools (living-off-the-land techniques) generated no alerts, because monitoring was tuned almost entirely around perimeter and malware-signature events.
  • 21-day mean-time-to-detect: Before the engagement, the client's own incident-response metrics showed a 21-day average time to detect an active internal compromise. Combined with the program's findings and remediation, that figure fell to under 4 hours by the end of the 12-month engagement.

None of these findings would have been visible to a prevention-only, outside-in testing program — because none of them require getting past the perimeter. They only become visible once you assume the perimeter has already been crossed.

Why Prevention-Only Fell Short

Prevention-only programs answer a narrow but important question: how hard is it to get in? For a mature organization, the honest answer is usually "harder than it used to be, but not impossible" — phishing, credential stuffing, third-party compromise, and zero-days all remain viable initial-access paths regardless of how strong perimeter controls are.

Regulated industries carry an additional pressure: compliance frameworks are frequently written around demonstrable controls (patch levels, scan results, policy attestations) rather than demonstrated resilience against a realistic adversary. It is possible — common, even — to pass every required control check and still have the kind of internal exposure this engagement uncovered. Assumed breach directly tests the part of the threat model that prevention controls, by design, cannot see.

Wrap-Up

Prevention and assumed-breach testing are not competing philosophies — they are complementary halves of a resilient security program. For organizations in regulated industries especially, the question isn't whether prevention controls are working; it's what happens the day they don't. This engagement's mean-time-to-detect improvement — from 21 days to under 4 hours — is a direct result of finally testing that scenario on purpose, instead of waiting to learn the answer during a real incident.