Case Study: Continuous Pentesting Transformation

How a European Mid-Cap Insurance Group Replaced Annual Engagements With Always-On Attack Path Validation

---

1. Customer Background

The customer is a European mid-cap insurance group operating across seven countries, with approximately 9,400 employees and €4.2 billion in annual gross written premium. The group provides life, property, and specialty commercial insurance products through a combination of direct distribution, broker channels, and a network of regional bancassurance partners.

The technology environment reflects the operational complexity typical of regulated insurance carriers. It includes:

• An on-premises Active Directory forest with two child domains, supporting approximately 11,000 user accounts and 24,000 machine accounts
• A primary Microsoft Entra ID tenant, with hybrid synchronization to the on-prem forest
• A secondary Entra ID tenant inherited from a 2023 acquisition, not yet consolidated
• Microsoft 365 across all subsidiaries
• Azure workloads supporting actuarial computing, document processing, and an internal data platform
• A smaller AWS footprint hosting two customer-facing portals
• Okta as the SaaS federation broker for approximately 70 sanctioned SaaS platforms, including Salesforce Financial Services Cloud, ServiceNow, Workday, and a proprietary policy administration system delivered via SaaS
• A claims processing platform delivered by a third-party vendor with deep integration into both the policy administration system and the data platform

The security organization is led by a Group CISO with regional CISO counterparts in three of the operating countries. The function operates a 24x7 SOC delivered through a hybrid model — internal Tier 2/3 capability combined with an MSSP providing Tier 1 monitoring. Compliance obligations include ISO/IEC 27001:2022 (group certification), local data protection regulations across operating countries, GDPR, and the European Union's Digital Operational Resilience Act (DORA), which had taken full effect prior to the engagement.

The Group CISO had been in post for approximately two years. The CISO's predecessor had established a traditional offensive security program centered on annual external and internal penetration tests delivered by a reputable European consulting firm. The most recent engagement had concluded approximately five months prior to the start of this case study.

---

2. Security Challenges

The Group CISO had inherited a security program operating with credible governance, mature defensive controls, and the periodic offensive validation that had served the organization for the preceding decade. The CISO had also inherited a set of structural concerns that the inherited program did not adequately address.

Concern one — the relevance gap between engagements. The most recent internal pentest had identified 23 findings ranked across critical, high, and medium severity. By the time the CISO's team had completed remediation, more than four months had passed since the testing window. The environment had absorbed three significant changes during that period: a major Entra ID conditional access policy refactor, a new Salesforce-to-policy-administration integration involving substantial OAuth consent grants, and the onboarding of a new third-party claims handling partner with federated access to the data platform. None of these changes had been validated by offensive testing. The CISO did not know, with evidence, whether the post-change environment was as defensible as the pre-engagement environment had been.

Concern two — DORA expectations. DORA had taken effect with explicit expectations of continuous testing of ICT systems, with particular emphasis on threat-led penetration testing for significant institutions and ongoing testing for all in-scope entities. The Group CISO had concluded that annual engagement evidence, however well-executed, was unlikely to satisfy a substantive regulatory examination under DORA's "ongoing testing" expectations.

Concern three — the acquired entity. The 2023 acquisition's Entra ID tenant had not been consolidated. Integration had proceeded through federation rather than full merger, primarily because the acquired entity's identity hygiene had been assessed as below the parent organization's standards. The federation arrangement had been intended as temporary. Two years on, the temporary arrangement had become permanent in practice, and the CISO had limited visibility into the chains the federation enabled.

Concern four — cyber insurance renewal. The group's cyber insurance policy was due for renewal within the case study period. The carrier had communicated, in pre-renewal discussions, an explicit interest in evidence of continuous validation rather than periodic attestation. The CISO understood that the renewal terms would reflect, at least in part, the evidence base the group could produce.

Concern five — board expectations. The board's risk committee had begun, over the preceding two committee cycles, asking sharper questions about offensive validation. The committee had recently engaged external counsel for a briefing on directors' duties under DORA and emerging European cyber governance frameworks. The questions the committee was now asking — "what chains currently reach customer data," "how quickly are new exposures validated," "what evidence supports the assertion that our controls are effective" — were questions the inherited program could not answer with current evidence.

These concerns formed the strategic case for transitioning from periodic to continuous offensive validation. The CISO engaged KeenSafe for a structured transformation program covering the group's primary tenants, on-premises forest, Azure and AWS workloads, Okta-federated SaaS platforms, and the federated relationship with the acquired entity.

---

3. Initial Exposure State

The KeenSafe platform was deployed in week one of the engagement. Continuous ingestion from the identity providers, cloud control planes, Okta, the on-premises forest, vulnerability scanners, and selected SaaS platforms was operational by end of week two.

The first comprehensive baseline of validated chains was produced at the end of week three. The findings provided a substantively different picture of the environment's exposure than the inherited annual pentest report had produced.

Baseline state — validated chains reaching crown jewels. At the end of the baseline period, the platform had surfaced and empirically validated 31 distinct chains terminating at assets the group had designated as crown jewels. Crown jewels had been defined explicitly during week one and included the policy administration database, the customer master record store, the claims processing data store, the actuarial pricing model repository, the Workday HR records, the Salesforce customer relationship data, and the production deploy pipelines for the customer-facing portals.

Composition of validated chains. The 31 chains decomposed by entry vector as follows:

• 14 chains originated through identity exposures — over-privileged service principals, embedded credentials in collaboration platforms, weak password policies on legacy on-prem accounts, federation policy gaps enabling cross-tenant traversal
• 8 chains originated through OAuth consent over-grants in the Salesforce and Microsoft 365 environments
• 5 chains originated through misconfigurations in the inherited tenant from the acquired entity
• 3 chains originated through external attack surface exposures — including one chain rooted in an exposed administrative interface inherited with the acquisition and one rooted in a misconfigured certificate validation in a partner-facing API
• 1 chain originated through a CI/CD pipeline misconfiguration that allowed a developer identity to deploy to production through a path not subject to the standard release approval workflow

Most consequential chains. Of the 31, the platform's prioritization surfaced six chains as immediate priorities based on adversary realism, business impact, and feasibility. These six included three chains reaching the policy administration database, two chains reaching the customer master record store, and one chain reaching the production deploy pipeline for the larger of the two customer-facing portals.

Comparison with the inherited report. The most recent annual pentest report had identified 23 findings. Mapping those findings against the 31 validated chains showed that only 4 of the 23 findings participated in any of the validated chains. The remaining 19 findings — many of which had absorbed substantial remediation effort — addressed conditions that, in the post-change environment, did not participate in any chain reaching the group's crown jewels.

---

4. Attack Path Discovery

The platform's value became most concretely visible in the chains that the inherited annual model had not surfaced. Three representative chains are summarized below.

Chain A — Acquired Tenant to Customer Master Records

The chain originated in the inherited tenant from the acquired entity and terminated at the customer master record store in the parent tenant.

Stage 1 — Initial Access (T1078.004). A service principal in the acquired tenant, created during the 2023 migration, retained read access to a developer-accessible storage container. The container contained a configuration export that included a long-lived secret for a second service principal — also in the acquired tenant — with broader permissions.

Stage 2 — Privilege Acquisition (T1552.001, T1078.004). Validation confirmed that any of the 31 developer identities in the acquired tenant could retrieve the configuration export. The credential was validated as authentic (token acquired and discarded). The second service principal held Application.ReadWrite.All in the acquired tenant.

Stage 3 — Cross-Tenant Federation (T1556.006, T1199). The federation policy between the acquired tenant and the parent tenant permitted the second service principal to be added as a guest principal in the parent tenant for a specific class of integration. The historical policy, intended to facilitate the migration, had not been reviewed since deployment.

Stage 4 — Account Manipulation in Parent Tenant (T1098.001). Once present as a guest principal, the service principal could add credentials to a specific class of integration accounts in the parent tenant. One of those integration accounts held read access to the customer master record store.

Stage 5 — Crown-Jewel Reach (T1213). Validation confirmed reachability of the customer master record store from the integration account's context. No records were retrieved; reachability and authorization were confirmed through controlled API interactions only.

The chain composed five techniques across two tenants, exploited identity governance gaps in both tenants, and reached the customer master record store — one of the group's most consequential assets — through entirely identity-mediated steps.

Chain B — Salesforce OAuth to Claims Data

The chain originated through OAuth consent grants in the Salesforce environment and terminated at the claims processing data store.

Stage 1 — Compromised Vendor Scenario (T1199). A third-party marketing automation vendor held OAuth consent grants in the group's Salesforce environment that exceeded its functional requirements, including read access to customer records and integration with a Salesforce-to-Azure data synchronization service.

Stage 2 — Sales Data Access (T1213). Validation simulated a vendor-credential compromise scenario and confirmed that records accessible through the consent grants would be retrievable through Salesforce APIs.

Stage 3 — Synchronization Service Pivot (T1078.004). The synchronization service ran as a service principal with read access to a staging area in the Azure data platform. Validation confirmed that the principal's context could be leveraged from the Salesforce-mediated path under specific conditions reproducible in the customer environment.

Stage 4 — Staging-to-Production Movement (T1078.004, T1213). The staging area was reachable from the production claims processing data store through a configuration that, while intended to enable data lineage workflows, had not been hardened against the chain conditions that produced this reachability.

Stage 5 — Crown-Jewel Reach (T1213). The chain terminated at claims processing data accessibility. Validation confirmed authorization through read-only API interactions, without record retrieval.

The chain composed five techniques across three operational domains (SaaS, identity, and cloud) and reached claims data through trust relationships none of the individual domain teams had complete visibility into.

Chain C — Developer Identity to Production Deploy

The chain originated through a CI/CD pipeline misconfiguration and terminated at the production deploy pipeline for the larger customer-facing portal.

Stage 1 — Repository Access (T1213). A specific build pipeline had been configured to allow direct deployment without requiring the standard release approval workflow. The configuration was inherited from a prior emergency deployment process that had not been reverted.

Stage 2 — Credential Acquisition (T1552.001). A pipeline configuration file accessible to all developers in the relevant repository contained a deploy credential for the production environment.

Stage 3 — Deploy Path Validation (T1078.004, T1505.001). Validation confirmed the credential's validity and the deploy path's functional reachability. The empirical step confirmed authorization to deploy without actually deploying.

Stage 4 — Crown-Jewel Reach. Production deploy capability against a customer-facing portal — one of the explicitly designated crown jewels.

---

5. Validation Findings

Across the first 90 days of continuous operation, the platform produced findings substantively different from the inherited periodic model in three dimensions.

Dimension one — coverage. The platform validated 31 chains in the baseline. By the end of day 90, after multiple environmental changes including a major Okta policy update and the addition of two new SaaS platforms, the platform had surfaced a cumulative 47 distinct chains. The inherited annual model would have sampled the environment once during this period and would have produced a report of approximately 25–30 findings, of which historically only a minority would have represented validated chains to crown jewels.

Dimension two — currency. Mean time between exposure introduction and validation across the 90-day baseline period was approximately 19 hours. This included exposures introduced by the customer's own change activity (new SaaS integrations, identity changes, application deployments) as well as exposures arising from upstream events (a CVE disclosure against a software component in the inventory, a third-party vendor security advisory).

Dimension three — empirical evidence. Each validated chain produced an evidence package mapped to MITRE ATT&CK at procedure-level detail. The packages included execution timestamps, authorization confirmation artifacts, control telemetry, and explicit identification of which detective controls fired and which did not.

A particularly consequential finding emerged from the control telemetry correlation. Across the 47 chains surfaced during the baseline period, 64 percent of the chain stages should, by detection design, have produced SIEM alerts in the customer's SOC. Empirical correlation showed that only 38 percent of those stages had actually produced alerts. The 26-percentage-point gap reflected a combination of detection rule misconfigurations, log source ingestion gaps, and tuning that had drifted from its original design. This was the first systematic, evidence-backed measurement of detection efficacy the customer had ever obtained.

---

6. Business Impact

The Group CISO's quarterly board materials had historically reported on engagement counts, finding closures, and SLA compliance percentages. The first board report following the platform's deployment shifted the framing.

The committee was presented with a state-level summary: 31 validated chains at baseline, decomposed by entry vector and terminal asset; six chains prioritized for immediate severance; the detection efficacy gap measured at 26 percentage points; mean time to validate at 19 hours; chain severance progression tracked week-over-week.

The committee's response was substantively different from prior interactions. Questions focused on chain severance progression, on the detection efficacy gap, and on the federation arrangement with the acquired entity. The discussion produced an explicit committee request: a target state in which no validated chains terminate at customer master records or claims data within 180 days, with monthly progress reporting.

The business impact materialized across multiple dimensions over the engagement period.

Insurance renewal outcome. The cyber insurance renewal completed approximately five months into the engagement. The carrier accepted the platform's chain state evidence as material to underwriting. The renewed policy provided a 14 percent reduction in premium and an additional €5 million in coverage relative to the prior year, with several exclusions removed.

DORA examination readiness. A pre-examination conversation with the customer's primary regulator referenced the group's continuous validation evidence positively. The regulator's representative communicated that the evidence base presented was the strongest the regulator had seen across the customer's peer set.

ISO 27001 surveillance audit outcome. The annual surveillance audit, conducted approximately six months into the engagement, closed with two minor non-conformities, compared to seven minor and one major in the prior year's audit. The auditor's narrative commentary explicitly referenced the strength of the validation evidence presented.

Acquired entity integration acceleration. The federation arrangement with the acquired entity, which had been treated as permanent in practice, was reopened as a strategic priority following the platform's surfacing of multiple chains traversing the federation. A consolidation program was initiated with executive sponsorship that had previously been absent.

---

7. Remediation Actions

The customer's remediation activity over the engagement period was organized around the validated chains rather than around finding severity. The chain-aware prioritization produced an explicit reorientation of engineering capacity.

Identity governance actions. The most consequential remediation work occurred in identity governance. Over the engagement period, the customer:

• Refactored 47 service principals in the parent and acquired tenants, reducing accumulated permissions to operational minimums
• Revoked 312 OAuth consent grants in Microsoft 365 and Salesforce that participated in validated chains or held permissions exceeding functional requirements
• Eliminated 19 dormant or recently-offboarded identities that retained credentials and group memberships
• Rotated credentials for 84 service accounts identified as Kerberoastable with weak password policy
• Tightened conditional access policies in Entra ID, including the elimination of two MFA bypass exceptions that had participated in validated chains

Federation and cross-tenant actions. The federation between the parent and acquired tenants was substantively reduced in scope. Specifically:

• The cross-tenant trust enabling guest principal addition for migration-era integrations was revoked
• The remaining federation pathways were restricted to a defined set of approved integration types
• A consolidation roadmap for the acquired tenant was initiated with a 12-month target

Configuration remediation. Beyond identity, the customer performed:

• Refactoring of the Salesforce-to-Azure synchronization service to use a scoped service principal with minimal permissions
• Hardening of the staging-to-production reachability path in the Azure data platform
• Restoration of the standard release approval workflow on the customer-facing portal CI/CD pipeline, with deprecation of the bypass configuration
• Removal of embedded credentials from collaboration platform content, with implementation of automated content monitoring to prevent recurrence

Detection engineering. The detection efficacy gap drove a substantial detection engineering work stream. The SOC's detection rules were re-tuned against the techniques participating in validated chains. Log source ingestion gaps were closed. New detection rules were authored against several techniques where empirical validation had confirmed no detection coverage existed.

Re-validation confirmation. Every remediation action triggered automatic re-validation of the affected chains. The customer's confirmation of severance was empirical, not assumed from closed tickets.

---

8. Outcome Metrics

The engagement's outcome was measured against state-level metrics established during the baseline period.

Path density at crown jewels. The number of validated chains terminating at crown jewels decreased from 31 at baseline to 4 by month nine. Of the remaining 4, two were in active remediation and two had accepted-risk dispositions formally signed by the business with explicit residual-risk acceptance.

Chains terminating at customer master records and claims data. The committee's target of zero chains terminating at these specific assets was achieved at month seven, five months ahead of the 180-day target.

Mean Time to Validate (MTTV). MTTV remained stable at approximately 14–22 hours across the engagement period, with no measurable degradation as the environment continued to absorb change.

Mean Time to Sever (MTTS). MTTS for highest-priority chains averaged 8 days across the engagement period. For lower-priority chains, MTTS averaged 23 days. Both compared favorably to industry benchmarks the customer's risk function had researched.

Detection efficacy ratio. The detection efficacy ratio improved from 38 percent at baseline to 71 percent at month nine, with the remaining gap attributable to specific technique categories the SOC was actively investing in.

Re-validation coverage. 100 percent of remediated chains were empirically re-validated. The customer detected three instances during the engagement period where a previously remediated condition was reintroduced through unrelated change activity; in each case, re-validation surfaced the reintroduction within hours and a targeted intervention restored severance.

Engineering capacity reallocation. The proportion of engineering remediation effort directed at conditions participating in validated chains rose from approximately 18 percent in the pre-engagement quarter to approximately 81 percent in the most recent quarter of the engagement.

---

9. Strategic Improvements

The transformation produced strategic improvements that extend beyond the measurable outcome metrics.

Operating model maturation. The security program transitioned from a periodic-engagement operating model to a continuous validation operating model. The transition was organizational as much as technical — ownership of validated chains was established explicitly, integration with SOC and identity governance workflows was operationalized, and executive reporting was refactored to emphasize state metrics.

Identity governance reorientation. Identity governance, historically operated as a compliance discipline, was reoriented around chain severance evidence. The function's investment priorities, staffing, and tooling were realigned with the conditions producing the most chains.

Federation discipline establishment. The federation between the parent and acquired tenants — historically managed informally — became a governed surface with explicit ownership, regular review, and chain-aware impact assessment for any proposed changes.

OAuth consent governance institutionalization. OAuth consent, historically managed through reactive review when issues arose, became a continuous discipline integrated with the validation evidence base.

SOC integration maturation. The SOC's relationship with offensive validation evolved from periodic engagement debriefs to continuous detection efficacy correlation. The MSSP partnership was renegotiated to incorporate the new evidence base.

Regulatory engagement strengthening. The customer's regulatory engagement became proactive, with the validation evidence base serving as the foundation for substantive discussions on DORA implementation and ongoing testing expectations.

Board confidence development. The board's risk committee had transitioned, over the engagement period, from asking questions the program could not answer to receiving state-level evidence at every committee meeting. The qualitative effect on board-CISO dynamics was substantial.

Strategic positioning of security as business enabler. The CISO's positioning within the executive team strengthened. Security validation evidence became an input to M&A diligence, vendor selection, and several customer-facing commercial conversations where the group's security posture had become a competitive factor.

---

The transformation took place against the backdrop of an active threat environment and ongoing business pressure. The group did not pause operations to enable the transition. Continuous validation absorbed change as it occurred, surfacing exposures introduced by the business's own activity and severing them before they were exploited. The platform did not displace the offensive security capability the group had relied on for a decade; it relocated where that capability operated. The annual external pentest continued, refocused on novel adversarial creativity. The internal pentest function was reorganized around emerging chain classes and business logic exploitation that the platform did not cover.

The Group CISO's summary, at the end of the engagement's first year: "We have replaced an annual photograph with a continuous video, and we have stopped reporting activity to our board and started reporting state. The conversations we have are different. The decisions we make are different. The defensibility we operate from is different. And we have evidence — current, empirical, continuously refreshed — that supports all of it."

---

KeenSafe is an AI-powered attack path validation platform for continuous offensive security validation across hybrid enterprise infrastructure. The case study reflects a representative engagement composite. Customer specifics have been anonymized.