The hybrid two-platform pattern: separating the public attack surface from enterprise client data, and the seam between them

Executive summary

The companion paper, Fortified by Design, closed with an observation that the right hosting answer for an estate serving consumers, business customers and enterprise monitoring clients is often two platforms rather than one: a hyperscaler for the public-facing zones, and a second platform, another hyperscaler or a captive facility, for the one-way ingestion of client data. This paper takes that observation seriously and works through what it costs to do it well.

The case for the split is simple to state. The public zones and the ingestion zone have opposite risk profiles: one is exposed by design to anonymous traffic at internet scale, the other holds the most sensitive data the organisation will ever be trusted with. Putting them on the same control plane means one set of administrative credentials, one policy engine and one audit trail stand between a web-tier compromise and every client's data. Two control planes turn that into two independent compromises, which is a claim an enterprise client's security team can understand and value.

The cost is a second operating model, and the pattern fails when that cost is underestimated. Section 2 states the case and its limits. Section 3 draws the split line and names what goes where. Section 4 defines the seam, the narrow set of flows permitted between the two platforms, as a contract with five entries and nothing else. Sections 5 to 8 handle the four things that must span both platforms: identity, management, security operations and data governance. Section 9 treats resilience, Section 10 the operating model, Section 11 the pairing choices, and Section 12 the anti-patterns that turn two control planes back into one with extra steps.

The one sentence version

Two platforms are safer than one only if the seam between them is narrower than either platform's own internal boundaries, and only if identity, management, detection and governance are genuinely unified across both rather than duplicated.

2. The case for two, and its limits

2.1 Independence of compromise

A single hosting platform, however well segmented, has a root of administrative authority: the organisation, tenant or root account, and the small number of identities that can act at that level. Every guard-rail in Fortified by Design, the service control policy, the management-group policy, the organisation policy constraint, is ultimately editable by that authority. The threat this creates is not the web-tier attacker walking through a firewall; the segmentation stops that. It is the attacker who obtains, through phishing, a supply-chain compromise of the pipeline, or a provider-side incident, an identity that operates above the segmentation. On one platform that identity reaches everything. On two, it reaches half.

The value is therefore in correlation, not in any single control. Two platforms with separate root authorities, separate administrative identity sets, separate policy engines and separate audit trails fail independently, provided the seam between them does not reintroduce a shared dependency. That proviso is the subject of most of this paper.

2.2 What the client sees

Enterprise clients who send operational data for monitoring evaluate the estate as a supplier inside their own perimeter. The question their security team asks is what happens to their data if the estate's public face is breached, and the two-platform answer, that the public face and their data do not share a control plane, is stronger than any answer a single platform can give. It also changes the audit conversation: the ingestion platform can be scoped, evidenced and, where a client requires it, inspected as a smaller and quieter estate than the whole.

2.3 Where the case does not hold

The pattern does not pay for itself in three situations. First, when the ingestion population is small and lightly regulated; a bridged isolation model on one platform is adequate and the second operating model is pure cost. Second, when the organisation cannot staff two platform specialisms; a poorly operated second platform is a liability, and the honest comparison is between one platform run well and two run thinly. Third, when the seam cannot be kept narrow, because product requirements demand that raw client data flow into the public application, at which point the two platforms are one estate with a slow network in the middle. The decision in Section 10 of the companion paper still governs; this paper describes how to execute the two-platform outcome, not why every estate should reach it.

3. The split line

3.1 What goes where

The line is drawn by trust, not by function. Everything that faces the public or holds consumer and partner identity lives on Platform A. Everything that holds client-ingested data, raw or curated, and every key that protects it, lives on Platform B. Two placements need explicit decisions.

•     The analytics platform goes with the data. Analytics runs on Platform B against the curated store. Moving curated data to Platform A for analysis would put client data on the public control plane, which defeats the purpose. The cost is that Platform B needs an analytics capability of its own, which is one of the inputs to the pairing choice in Section 11.

•     The B2B portal stays on Platform A, and reads only derived artefacts. Partner users log in on the public platform and see reports, dashboards and alerts. Those are built on Platform B, pass through a classification downgrade gate, and are published as signed artefacts that Platform A pulls. The portal never queries Platform B directly and never sees a raw row.

3.2 The downgrade gate

The report builder on Platform B is the one component that turns client data into something that may leave the ingestion control plane. It is therefore a security control, not a reporting feature. Every artefact it produces carries a classification label; only artefacts labelled as aggregated, de-identified or client-approved for their own portal view may be published to the drop that Platform A reads. The gate is enforced in code, its rules are versioned, its outputs are signed, and a sample is reviewed. Where a client requires that even derived views never leave the ingestion platform, the portal for that client is served from Platform B behind its own private entry, which the architecture accommodates at the cost of a second portal deployment.

4. The seam

The seam is the set of flows permitted between Platform A and Platform B. Its design principle is that it must be narrower than either platform's internal zone boundaries; if it is not, the split has added cost without adding independence. It is written down as a contract with a small number of entries, each with an owner, a review cadence and an alarm on change.

4.1 The five entries

1.   Derived reports, B to A. Platform B publishes signed artefacts to a drop location on Platform B. Platform A pulls them using a federated, read-only identity that can list and read that drop and nothing else. The pull direction is deliberate: Platform B holds no credential for Platform A, so a compromise of B cannot push into A, and A's read-only credential cannot alter what B published.

2.   Report requests, A to B. When a partner user asks for a report the portal enqueues a request carrying the tenant identifier, the period and the template name. Platform B consumes the queue, validates the tenant against the requesting identity's claim, builds the artefact, and publishes it through entry 1. No data crosses in this direction, and the queue is the only Platform A resource Platform B can read.

3.   Telemetry, both to Zone 6. Both platforms ship audit, flow and application logs to the security-operations archive. Neither ships to the other. This entry is discussed in Section 7 because where the archive lives is itself a design decision.

4.   Change, Zone 5 to both. One infrastructure-as-code pipeline applies to both platforms, with a distinct, short-lived deployment identity per platform issued through workload identity federation. The pipeline can change either platform; neither platform can change the other. Section 6 covers the pipeline's own protection.

5.   Nothing else. No site-to-site tunnel, no peering, no shared object storage mounted on both sides, no database link, no service mesh spanning both, no shared static credential, no shared secrets vault with both platforms' secrets in it. Each of these is a convenience that turns two control planes into one.

4.2 Enforcing the contract

Each entry is implemented with a construct that can be inspected: a specific bucket or container and its access policy, a specific queue and its policy, a specific pair of federated identities and their permitted audiences. A policy-as-code rule on each platform asserts that no other cross-platform connectivity exists, that no identity from the other platform holds any role beyond the two named, and that no static credential for the other platform is present in the vault. Drift on any of these is an incident, not a finding.

The test of a narrow seam

Ask what an attacker holding full administrative authority on Platform A can reach on Platform B. The answer should be: read a drop of already-downgraded reports and place requests on a queue that B validates. If the answer includes anything else, the seam is too wide.

5. Identity across two control planes

Identity is the first of four things that must be unified, and the one where duplication is most tempting and most damaging.

5.1 One workforce directory, two federations

Operators authenticate to one workforce identity provider with hardware-backed multi-factor authentication and conditional access. Both platforms federate to it; neither holds local human accounts beyond per-platform break-glass. Role assignment happens in the platform's own authorisation system, scoped per platform, and just-in-time elevation is administered per platform so that an operator elevated on A is not elevated on B. The identity provider is therefore a shared dependency, and it is protected as such: it is not hosted on either platform's production estate, its administrative roles are the most restricted in the organisation, and its own audit trail feeds Zone 6.

5.2 Workload identity without shared secrets

The two federated identities on the seam, Platform A's reader and Platform B's queue consumer, are established through workload identity federation: each platform trusts the other's token issuer for one specific audience and maps it to one specific role. No access key for either platform is ever stored on the other. The same mechanism gives the deployment pipeline its per-platform identity. The audit question, which token from which issuer assumed which role when, is answerable on both sides.

5.3 Consumer and partner identity stay on A

The customer identity platform and partner federation live on Platform A and are never extended to Platform B. Platform B has no interactive user population at all beyond operators; the only identities it knows are enterprise clients' ingestion principals, its own workloads, the pipeline and the two seam identities. That smallness is a feature and is worth defending against every proposal to add a login.

6. One management plane for two providers

6.1 Infrastructure as code with two backends

A single repository and a single pipeline describe both platforms, using a tool that supports both providers natively. Environment promotion, review and approval apply identically. The pipeline runs on infrastructure that belongs to neither platform's production estate, or on Platform B with the strongest available isolation, because a pipeline that can change both platforms is the most valuable target in the organisation. Its runners are ephemeral, its identities are per-platform and short-lived, and an apply to Platform B's ingestion boundaries requires a second approver by policy.

6.2 Policy as code above both

Each platform keeps its native guard-rails: service control policies, management-group policy, organisation policy and perimeters. Above them, a provider-neutral policy-as-code layer expresses the estate-wide rules once, the seam contract among them, and evaluates every planned change against them before apply. This is what stops a well-intentioned engineer adding a peering connection because it was easier than the queue. Drift detection runs against both platforms and against the seam rules on a schedule, and reverts or alarms.

6.3 Secrets and break-glass

Each platform uses its own secrets service for its own secrets. There is no shared vault holding both platforms' secrets, because that vault would be a single point of compromise across the seam. Break-glass accounts exist per platform, are stored in separate physical custody, alarm on use, and are exercised on a schedule. The scenario each is designed for is the loss of the shared identity provider, which is the one dependency both platforms share.

7. Unified security operations

This is the hardest part of the pattern and the place where most two-platform estates are weakest. Two platforms produce two audit trails in two schemas with two sets of native detection services, and a security operation that watches one platform's console while the other's alerts go to a different inbox is not watching the seam at all.

7.1 Where Zone 6 lives

Whichever option is chosen, three properties are mandatory. Logs leave each platform through an organisation-level sink that no project, account or subscription administrator can disable. The archive is immutable for the retention period and readable only by security-operations identities that are not production identities on either platform. And detection runs on normalised events from both platforms, so that a rule can say that a seam identity was used from an unexpected place regardless of which platform observed it.

7.2 Detection content for the seam

Beyond the per-platform rules in the companion paper, the seam needs its own. Any change to a seam construct: the drop policy, the queue policy, the federation trust, the policy-as-code seam rules. Any assumption of a seam identity by a principal other than the expected workload. Any cross-platform network path appearing where none should exist, detected from flow logs on both sides. Any artefact published to the drop without a valid signature or with a classification label the gate should not have passed. And any correlated activity across both platforms within a short window by the same human operator, which is the signature of an operator credential being used by someone else.

7.3 One response team, two runbooks

Response is a single function with a single incident process and two sets of platform-specific runbooks. Containment actions are pre-authorised per platform, including the action that severs the seam: revoking both federation trusts, which stops report flow and request flow while ingestion continues. That action is tested, because the day it is needed is not the day to discover that the portal fails badly without reports. Client notification obligations are per client and are triggered by an incident on Platform B, or by an incident on Platform A that touched the seam, with the second case being the one contracts often omit.

8. Data governance across the seam

8.1 Classification and the gate

The estate's classification scheme has a level that means client-ingested and a rule that data at that level exists only on Platform B. The downgrade gate in Section 3.2 is the only sanctioned transition out of that level, and each transition is logged with the rule that permitted it. Data-loss-prevention scanning on the drop, on Platform A's inbound side, provides an independent check that nothing at the client-ingested level arrived.

8.2 Keys stay where the data is

Per-client encryption keys live in Platform B's key service, backed by its hardware security modules, and are never referenced from Platform A. Report artefacts are encrypted with a separate key that Platform A can use, which is the only key the two platforms share, and it is scoped so that it can decrypt artefacts and nothing else. Client-held keys, where a client requires them, are integrated on Platform B only. Crypto-shredding a client on offboarding is a Platform B operation, and the client's derived artefacts on Platform A are deleted by retention policy.

8.3 Residency, retention and audit

Residency commitments to ingestion clients bind Platform B's region choices; residency for consumers binds Platform A's. The two need not coincide, which is one of the quieter advantages of the split. Retention is set per platform and per population, and the archive in Zone 6 holds the longest. For audit, the ingestion platform is scoped as a system of its own with its own controls matrix, which is what makes a client's right-to-audit clause tractable: the auditor sees Platform B and the seam, not the consumer estate.

9. Resilience

Two platforms fail independently, and the design should exploit that rather than fight it. When Platform A is unavailable, ingestion continues; clients' data keeps arriving, validation keeps running, and reports accumulate in the drop for the portal to collect when it returns. When Platform B is unavailable, the public estate continues; clients buffer and retry as their contract requires, and the portal shows the last published artefacts with their timestamps. Neither outage should cascade, and the seam design guarantees that only if the portal degrades gracefully without fresh reports and the queue tolerates an absent consumer, both of which are tested.

Disaster recovery is per platform. Platform A recovers into a second region on A; Platform B recovers into a second region on B or, for a captive facility, a second site. The estate does not replicate client data to Platform A as a recovery measure, however convenient, because that replica is client data on the public control plane. Recovery of the shared dependencies, the identity provider, the pipeline and the Zone 6 archive, is planned separately and tested first, since without them neither platform can be operated.

10. The operating model

The second control plane is paid for in people before it is paid for in compute. The honest accounting is below.

The benefit side is concentrated in three places: independence of compromise, a smaller and quieter platform to evidence to clients, and the freedom to choose each platform for what it does best. Whether the benefit exceeds the cost is a judgement about the ingestion population, and the paper's position is that it does once the population includes clients whose contracts would be lost or whose data would be existential to lose.

11. Pairing choices

Three observations follow from the matrix. The exfiltration boundary matters most on the ingestion side, which is why pairings placing the platform with the strongest perimeter construct on Platform B score well and pairings placing it on Platform A do not. Identity strength matters most on the public side, where partner federation and consumer identity live, which favours the identity-led platform for Platform A when the B2B population is large. And the captive facility is a strong Platform B candidate for a specific reason: its physical unidirectional boundary is exactly what operational-technology and sovereign clients ask for, and putting only the ingestion zone on premises keeps the captive footprint, and its staffing, small.

The analytics capability is the tie-breaker. Platform B must run the analytics platform, so the pairing should place a platform with a strong analytical store on the ingestion side or accept that the captive facility hosts one. Pairings that leave the best analytical engine on the public side create pressure to move data across the seam, which is the pressure the pattern exists to resist.

12. Anti-patterns

Each of the following has been observed in estates that described themselves as two-platform. Each collapses the pattern.

•     The mirror. Deploying the full stack on both platforms for resilience. Client data on the public control plane, twice the surface, and no independence.

•     The tunnel. A site-to-site connection between the platforms because a team needed one thing once. The seam becomes a network, and the network becomes a path.

•     The shared key. An access key for Platform B stored in Platform A's vault, or vice versa, to make a job easier. One compromise becomes two.

•     The convenient replica. Curated client data copied to Platform A so the portal can query it directly. The downgrade gate is bypassed and the classification rule is broken.

•     The abstraction layer. A multi-cloud management product that hides each platform's native isolation primitives behind a common model. Convenient for operators, and it typically holds administrative credentials for both platforms in one place.

•     The half-watched estate. Security operations built on one platform's native services, with the other platform's findings arriving as email. The seam is unobserved.

•     The unofficial single team. Two platforms nominally, one engineer who understands the second one. The second control plane exists on paper.

13. Conclusion

Two control planes buy independence of compromise, a smaller estate to evidence to the clients who care most, and the freedom to place each workload on the platform best suited to it. They cost a second operating model and demand that four things, identity, management, detection and governance, be unified rather than duplicated. The discipline that makes the pattern work is the seam: a contract of five entries, written down, enforced by constructs that can be inspected, alarmed on change, and defended against every convenience that would widen it. Where the ingestion population justifies the cost, the result is an estate whose public face and whose most sensitive data cannot be reached with the same set of keys, which is the strongest architectural claim a monitoring provider can make to the enterprises that trust it.

Appendix A. Seam contract checklist