Is Your Digital Front Door Wide Open? Spotting Excessive Online Exposure

What CPG 2.0 actually changed — and what it means for your next assessment

Passing the assessment correlated with slower breach detection

What clients told us before the assessment — and what we found underneath

• We have MFA everywhere. That's the first thing we implemented.

  Root cause:

  MFA was enabled on primary identity provider authentication. It was not enforced on service accounts, on legacy application logins that used direct database authentication, on administrative consoles that bypassed the identity provider, or on API endpoints accessed with long-lived tokens. The primary login path was protected. The lateral movement paths inside the environment were not. In three engagements, post-breach forensic analysis traced attacker lateral movement entirely through service account credentials that had never been rotated and were not subject to MFA.

• Our MSP handles our security. They're responsible for keeping us compliant.

  Root cause:

  MSP contracts typically define service levels around uptime and response time. They rarely include enforceable obligations around CPG-specific control implementation, evidence collection, or continuous monitoring standards. The client believed the MSP's monitoring covered their CPG scope. The MSP's monitoring covered what the MSP had been contracted to monitor — which was a subset of the CPG scope, defined during the original procurement and not updated as the client's infrastructure grew. Under CPG 2.0, the responsibility to actively manage and verify your MSP's cybersecurity practices is now a named client obligation. Delegation does not transfer accountability.

• We did a penetration test last year. We know what our gaps are.

  Root cause:

  Penetration tests are scoped. They test what you include in the scope document. The assets that aren't in your inventory aren't in the scope document. The CPG gaps most likely to produce a breach — unknown assets, unmonitored environments, IT/OT connectivity that wasn't supposed to exist — are structurally excluded from standard scoped penetration tests because they require discovery-led assessment methodology, not confirmation of known targets.

The CPG gaps that don't show up on standard checklists

How a realistic CPG gap assessment should actually run

1. Step 1

   Start with the asset inventory — before any control review

   Output:

   A reconciled asset inventory that includes assets not in internal systems, sorted by exposure risk and ownership status.

   Purpose:

   An assessment against an incomplete inventory produces a false compliance picture. Before reviewing any control, independently enumerate what is externally reachable: subdomains, cloud resources, service accounts, OT network segments, third-party integration endpoints. What you find in this step that is not on the internal asset list defines the outer boundary of your real assessment scope.

2. Step 2

   Assess GOVERN before touching technical controls

   Output:

   A GOVERN maturity assessment with documented evidence gaps and a named accountability chain — or a documented finding that one does not exist.

   Purpose:

   Under CPG 2.0, GOVERN gaps cannot be compensated by technical control strength. Assess it first: does executive leadership have documented cybersecurity risk ownership? Is there a formal policy development and review cycle? Is the CISO's reporting structure and authority commensurate with the risk profile? A GOVERN gap identified early shapes the entire remediation plan.

3. Step 3

   Test controls adversarially, not by existence verification

   Output:

   A control effectiveness finding for each critical category — not a checkbox, but a statement of what the control catches and what it doesn't.

   Purpose:

   A CPG control review that asks 'do you have MFA?' is not the same as testing whether MFA is enforced on all access paths under real conditions. For each critical control category, the test should ask: can I bypass this? Test MFA through service account paths, legacy application bypasses, and API token flows. Test the IPS by running it against the KEV catalog for software versions in the environment. Test the IR plan by calling the team at an unexpected time and telling them they have an active incident.

4. Step 4

   Map third-party access against CPG 2.0 C-SCRM requirements

   Output:

   A third-party access inventory with a CPG 2.0 gap analysis against each named requirement in the C-SCRM goal category.

   Purpose:

   Enumerate every vendor, contractor, and MSP with active network or system access. For each: when was access last reviewed? What is the contractual basis for CPG-aligned security practices? What monitoring exists for their activity in your environment? The goal is not to audit the vendors — it is to establish whether you can answer these questions at all. Most organizations cannot.

5. Step 5

   Establish continuous monitoring against the gaps, not the checkboxes

   Output:

   A monitoring program with documented drift thresholds, named owners for each monitored control category, and a defined escalation path when drift is detected.

   Purpose:

   Annual assessments verify a snapshot. Between assessments, the controls that are most likely to drift are the ones that require active maintenance: patch levels, firewall rule hygiene, access reviews, certificate management, and vendor account lifecycle. Build monitoring against the specific drift patterns that produce your highest-risk gaps — not against generic compliance dashboards that confirm the tool exists and is turned on.

Closing the gaps that clean assessments leave open

1. 1Security and legal jointly

   Establish a pre-authorized forensic retainer before your next assessment cycle. Not during an incident — before. The retainer should include pre-negotiated scope, pre-approved budget authority, and a pre-established communication channel. The 31-hour procurement delay we observed in active incidents is not a budget problem. It is a pre-authorization problem, and it is entirely solvable before an incident occurs.

   Expected outcome

   When an incident starts, forensic engagement begins within hours, not days. The window for evidence preservation is not lost to procurement.

2. 2IT and security jointly

   Run an external asset enumeration from outside your network before submitting your asset inventory to any assessor. Use Certificate Transparency logs, passive DNS, and cloud resource tagging audits to find what your internal systems do not show. The assets that are not on your inventory are the assets most likely to carry your highest-risk gaps.

   Expected outcome

   The inventory handed to the assessor reflects the actual external attack surface, not the official record of what you believe exists.

3. 3Security team

   Run your incident response plan as an unannounced drill, not a scheduled tabletop. Call the team at an unexpected time. Do not tell them the scenario in advance. Measure actual response times, actual decision latency, and actual escalation paths. The gap between tabletop performance and real-incident performance is where breach costs accumulate.

   Expected outcome

   A realistic baseline of actual IR capability — including the specific decision points and coordination failures that only surface under real time pressure.

4. 4IT operations and security

   Extend log retention to a minimum of 180 days across all critical systems. Given that average dwell time in our dataset exceeds the standard 30-90 day retention window, investigations consistently start after the evidence of initial access has been overwritten. The cost of storage is lower than the cost of being unable to reconstruct the breach.

   Expected outcome

   Post-incident investigations have sufficient log depth to identify initial access vectors, not just the point of detonation.

5. 5CISO and executive team

   Document the GOVERN requirements before CPG 2.0 assessments begin. This means written evidence of executive cybersecurity risk ownership, a formal policy review cycle, and a documented accountability chain from the board to the technical teams. This is not theater — it is the foundation that makes the technical controls meaningful. Without it, you will have a GOVERN gap that cannot be closed by any technical remediation.

   Expected outcome

   CPG 2.0 GOVERN requirements met with substantive documentation, not nominal compliance.

What the next wave of CPG compliance failures will look like

1. The first major breach attributed directly to a CPG 2.0 GOVERN gap — not a technical control failure — will occur within 18 months of the framework's adoption, and it will involve an organization that had strong technical CPG scores.

   The GOVERN function is new, under-understood, and frequently treated as documentation work rather than substantive governance change. Organizations with mature technical controls and weak governance structures are building exactly the profile that produces this failure: strong perimeter, no coherent risk ownership, no executive accountability, and no mechanism to escalate security findings to decision-makers who can act on them. When a breach occurs in this profile, the technical controls will have fired correctly. The organizational response will fail because the governance infrastructure to act on those signals doesn't exist.

   Confidence: highIf, by end of 2026, no post-incident analysis of a CPG-assessed organization attributes failure to GOVERN-category gaps specifically, this prediction should be reassessed.

2. Managed service provider compromise will become the dominant initial access vector for CPG-assessed organizations within two years, specifically because CPG 2.0's C-SCRM requirements will drive organizations to better direct security — pushing attackers toward the softer MSP target.

   As organizations improve their direct security posture under CPG pressure, the path of least resistance shifts to their service providers. MSPs have access to many client environments from a single credential set. They are often smaller organizations with less mature security programs than their clients. And critically: under the current CPG framework, the client's obligation is to manage and verify the MSP — but the MSP's own security posture is not directly assessed. The requirement creates a governance layer without creating a security requirement for the entity being governed.

   Confidence: mediumIf MSP-originated initial access does not appear as a named pattern in CISA's threat reporting by 2027, this prediction is wrong.