The Hidden Trade No One Expected: Trust Concentration and Systemic Risk in the Platform Era
Executive Summary
Enterprise computing has spent the past fifteen years consolidating independent software products into integrated trust platforms. The pattern is visible everywhere an organization buys software. Exchange, Active Directory, Office, and antivirus were once separate purchases that became Microsoft 365, where email, identity, documents, device management, and security tooling ship as one subscription under one admin centre. Gmail, Drive, and Cloud Identity became Google Workspace. Okta grew from single sign-on into a full identity and access platform. Palo Alto Networks and CrowdStrike have each spent years folding firewalls, endpoint protection, SIEM, and cloud security into single platform offerings, and both openly describe consolidation as their core strategy. The commercial case for this shift is well understood and largely valid: fewer vendors, lower administration costs, native integration, and better routine security outcomes. Its validity rests on a real transfer, because most organizations cannot hire or retain the depth of security skill the platforms employ, and consolidation moves the work to the perceived skilled. That is a rational move as far as it goes, but it is a trust transfer as much as a skills transfer, and it is made without properly evaluating the risk that travels with it. What has gone almost entirely undiscussed is that structural cost. Twenty years ago, a compromised email server was a compromised email server. The identity system, the file store, the finance application, and the endpoint tooling ran as separate products with separate credentials, so each failed on its own and the damage stopped at its own edges. Today those same functions sign in through one identity service and answer to one management console, which means a single compromise of that shared layer can reach all of them at once. Modern enterprise security has quietly exchanged many small, independent failure domains for a few very large shared ones, and it has made that exchange without ever considering the consequences.
The danger is not that one vendor sells many products. It is that the products become mutually trusting extensions of one security boundary. Integration is trust extension by another name, and the clearest illustration is the administrative layer itself. In a typical platform deployment, one identity service authenticates every user into email, file storage, endpoint management, the security console, and the AI assistant, and one global administrator role governs them all. That shared layer is what makes the platform convenient, and it is also the hidden concentration of risk: a single phished administrator credential, a single hijacked admin session, or a single stolen signing key at the provider is no longer an email problem or a device problem. It is immediately a company-wide problem, because the compromise propagates along the same integration paths the platform was sold on. The attacker who holds the common element holds everything the common element touches. The market has already conceded this point, even if the marketing has not. An entire category of add-on businesses now exists to re-engineer the platforms' own administrative model. CoreView built its business on carving Microsoft 365 tenants into segmented virtual tenants with delegated, least-privilege administration. AvePoint sells governance and permissions control over the same environments. CyberArk, BeyondTrust, and Delinea sell privileged access management whose core promise is containing what a compromised administrator account can reach, and Semperis sells detection and recovery for the identity tier itself, marketing explicitly to the scenario where Active Directory or Entra ID is the thing that fails. These products are a tacit admission that the platform's shared administrative layer is a liability serious enough to build companies around, and they address it only at the layer the customer controls, quietly ignoring the larger vulnerability that sits above every tenant: the single platform owner itself.
That owner is a second, largely invisible administrative layer sitting above every customer. The platform vendor holds the signing keys, the update channels, and the operational access that outrank any control the customer can configure, which makes the provider a hidden super-administrator shared by every organization on the platform. The compound risk is who has access to and influence over that hidden super-administrator. The customer's threat model must now include everyone who can reach the provider's control plane: the provider's own employees and contractors, the attackers who target the provider precisely because of what it holds, and the external parties able to compel or influence the provider through law, ownership, or pressure. That last class is universal rather than a property of any one flag. Chinese providers are subject to their government, British providers to theirs, American providers to theirs, and every provider everywhere answers to some jurisdiction whose interests are not the customer's. Nor is state power the only route in, because history already records vendors secretly owned outright by intelligence agencies, most famously Crypto AG, the Swiss encryption company covertly owned for decades by the CIA and Germany's BND while it sold deliberately weakened equipment to more than one hundred governments,1 and organized crime has repeatedly bought, built, or penetrated its way into positions of vendor access. None of these actors appear in the customer's directory, none are governed by the customer's controls, and every one of them stands upstream of the customer's entire environment. The key change sits here, and it is easy to miss because it is an absence rather than an event. An organization could always vet the people who held administrative power over its systems: it hired them, screened them, contracted them, supervised them, and could remove them. The platform era transfers the highest level of that power to people the organization cannot name, cannot screen, cannot supervise, and cannot remove. The ability to vet who has access, the oldest control in security, quietly stopped applying at exactly the layer where access is greatest.
Figure 1. The vetting boundary, before and after platform consolidation. On the left, every holder of administrative power sits inside the boundary the organization controls: hired, screened, supervised, removable. On the right, the boundary still exists but covers only the tenant, while signing keys, update channels, and operational access sit with a provider layer the customer cannot name, screen, supervise, or remove, shared with every other tenant on the platform.
That compounding has elevated the risk to unprecedented levels, because no previous era of computing concentrated this much organizational authority in a place so few customers can observe and so many third parties can reach. A compromise at that layer is the customer-side admin breach repeated at industry scale, striking thousands of tenants through a single point they cannot see, cannot audit, and cannot revoke. This is not a theoretical exposure, because the pattern has already been evidenced repeatedly: a poisoned build system at SolarWinds pushed trojanized updates to roughly eighteen thousand organizations,2 a compromised management platform at Kaseya delivered ransomware to some fifteen hundred downstream businesses in a single weekend,3 a breached support system at Okta exposed session material affecting its customer base,4 a hijacked accounting-software update channel in Ukraine became the launch vector for NotPetya,5 and, on the availability side of the same coin, one faulty content update from CrowdStrike disabled roughly 8.5 million Windows machines in a morning.6 In every case, the same integration that made the platform efficient is what carried the failure to everyone connected to it.
Security and resilience are different objectives, and platform consolidation trades one for the other. The distinction is simple and worth fixing in mind, because the two words are routinely used as if they were interchangeable. Security is about keeping bad things out: the lock on the door, the password policy, the patched server. Resilience is about what still works after something gets in or breaks: whether the business can take orders when the email system is down, whether staff can still sign in when the identity provider fails, whether one infected machine stays one infected machine. A house with an excellent lock and no smoke detector is secure but not resilient, and a hospital that can run on paper charts through a network outage is resilient even on a day its security fails. Consolidation raises the security average by reducing routine hygiene failures, and at the same time it increases the risk of rare but organization-wide failures by concentrating systemic dependency, common-mode failure, and provider-side blast radius. An organization can be harder to compromise on a typical day and more exposed to catastrophic correlated failure than it has ever been, and both statements can be true at once. Microsoft serves as the principal case study, not because it is uniquely at fault but because its combination of Windows, Entra ID, Microsoft 365, Defender, Sentinel, Azure, Intune, and Copilot forms the largest shared identity and management plane in enterprise computing, and because the Storm-0558 intrusion demonstrated how a provider-side compromise propagates beyond the provider's own environment.7 The same structural analysis applies to Google, AWS, Okta, Palo Alto Networks, and CrowdStrike, because the issue is architectural and economic rather than vendor-specific.
It all comes down to a single question that should sit inside every procurement decision, and currently sits inside almost none: if this trusted component suddenly becomes unavailable, compromised, or no longer trustworthy, how much of the organization continues to function? That question applies equally to AI models, identity providers, cloud platforms, security suites, and national digital infrastructure. Organizations that cannot answer it have solved one problem and replaced it with an even bigger one. They have made an uninformed trade into a different level of jeopardy, exchanging fixable small-scale security incidents for systemic large-scale failures.
SECTION 1
Introduction
This is not about Microsoft. Microsoft will appear throughout, and one Microsoft incident will serve as the principal case study, but the subject is larger than any vendor. The subject is a structural shift in how enterprises organize trust, and the fact that this shift happened without anyone formally deciding to make it.
Over the past fifteen years, enterprise computing moved from a portfolio of independent software products toward integrated trust platforms. The email system, the identity provider, the endpoint agent, the SIEM, the device manager, and increasingly the AI assistant no longer arrive as separate products from separate vendors with separate failure modes. They arrive as one platform, sharing one identity plane, one management plane, and one commercial relationship. The industry describes this as consolidation. That word is accurate but incomplete, because what consolidated was not merely the invoice. What consolidated was trust.
Modern enterprise security has quietly exchanged many independent failure domains for fewer, much larger trust domains. This is the hidden vulnerability of the platform era, and it needs to be stated plainly and examined in the open, because it currently lives nowhere: not in the vendor's marketing, not in the procurement checklist, not in the risk register. The exchange is not inherently good, and it is not inherently bad. It is a trade, and every trade has a cost. The security industry has spent a decade marketing the benefits of this trade while giving almost no sustained attention to its costs, which is precisely how the cost became an unexpected one. What follows is an attempt to state the costs plainly, so that organizations can decide whether the trade is one they meant to make, and whether alternatives exist that can alleviate the risk.
SECTION 2
The Platform Economy
Platform vendors did not set out to concentrate systemic risk. They set out to win customers, and they responded rationally to what customers asked for.
Consider the incentives from the buyer's side. A mid-sized organization running best-of-breed security in 2015 might have held contracts with a dozen vendors: one for email, one for identity, one for endpoint protection, one for log management, one for mobile device management, one for data loss prevention. Each contract meant a procurement cycle, a renewal negotiation, an integration project, a training burden, and a distinct console for a security team that was already understaffed. Integration between these products was fragile, expensive, and perpetually behind. Consolidation solved real problems. It reduced operational complexity, cut administration costs, replaced brittle third-party integrations with native ones, and gave security teams a single pane of glass that mostly worked instead of six panes that mostly did not. For many organizations, measured security outcomes genuinely improved.
Now consider the incentives from the vendor's side. Every additional product a customer adopts increases integration depth. Integration depth increases switching costs, and switching costs increase retention and pricing power. A vendor that sells one product competes on that product's merits every renewal cycle, while a vendor that sells a platform competes on the cost of leaving. Neither side is behaving badly here. Buyers are reducing friction, vendors are maximizing lifetime value, and these are the ordinary mechanics of enterprise software economics.
But follow the mechanics one step further. Deep integration between products requires those products to trust each other. The identity service must be trusted by the email service, the management agent must be trusted by the endpoint, and the security tooling must be trusted by everything, because it must see everything. Each act of integration is also an act of trust extension. The commercial logic of the platform economy, executed faithfully by rational actors on both sides, produces ever larger shared trust boundaries as a byproduct. Nobody designed that outcome. It emerged, and emergent architecture is precisely the kind that never gets a risk review.
SECTION 3
The Promise of Consolidation
It is important to state the case for platforms honestly, because the case is strong and the benefits are real and clearly visible. The argument that follows does not require pretending otherwise.
Platform consolidation improves the security average, and the evidence for this is reasonable. A single identity provider with consistent conditional access policies beats a patchwork of federation agreements maintained by hand. A natively integrated endpoint and SIEM stack surfaces signals that a bolted-together equivalent drops on the floor. Unified patching and configuration management reduce the routine hygiene failures that account for a large share of real-world breaches. Small organizations in particular gain access to security capabilities they could never have assembled or staffed independently. These are not marketing claims. They are true, and the typical organization on a well-run platform is probably harder to compromise on a typical day than the same organization running a loose federation of point products.
The mistake is stopping the analysis there. Security and resilience are not the same objective, and they do not always move together. Security asks how likely a compromise is, while resilience asks what happens when one occurs. Consolidation systematically improves the first measure while systematically degrading the second. It reduces the frequency of small, survivable failures and increases the severity of rare, correlated ones, so the everyday incidents become fewer while the catastrophic ones become larger.
An organization can therefore be more secure on average and simultaneously exposed to a category of failure it never faced before. Both statements are true at once. This is the “true, and” structure of the problem, and it is why the platform debate generates so much confusion. The vendor cites the improved day-to-day record, the critic cites the catastrophic exposure, and neither is wrong. The question is whether the organization ever consciously weighed that exposure, and in most cases the answer is no.
Figure 2. The trade, itemized. Each problem consolidation genuinely solved maps to a problem it introduced, and the two columns are not separable: the mechanism that delivers the benefit is the mechanism that creates the exposure. Procurement evaluated the left column. The right column arrived with it, unexamined.
SECTION 4
The Missing Conversation
Read any major security vendor's platform messaging and a pattern appears. The benefits of consolidation are quantified: fewer consoles, faster response times, lower total cost of ownership, reduced alert fatigue. The costs of consolidation are absent, and not minimized but absent. There is no slide in the deck titled “What happens to you if we are compromised.” There is no line in the business case for correlated failure. The renewal conversation covers licence tiers and feature roadmaps, and it does not cover blast radius.
This is not a conspiracy. It is an incentive structure. No vendor profits from articulating the systemic cost of its own success, and no procurement template asks for it. The result is an industry-wide conversation that resembles a mortgage broker explaining interest rates while never mentioning that the loan is denominated in a foreign currency. The stated terms are accurate, but the material risk is simply outside the frame.
Regulators have started to notice the shape of the problem in adjacent domains. Financial regulators speak of concentration risk when too many institutions depend on one clearing house or one cloud region. The security industry has no equivalent vocabulary in common use. It has “vendor lock-in,” which frames the issue as a commercial inconvenience, and “single point of failure,” which frames it as a component-level engineering flaw. Neither term captures what has actually been built: organization-wide dependence on the continued integrity of one provider's control plane. That gap in vocabulary is part of why the trade stayed hidden and its cost unexpected, because you cannot negotiate over a risk you cannot talk about. This is the conversation that needs to be in the open.
SECTION 5
Trust Concentration
The danger is not that one vendor sells many products. It is that the products become mutually trusting extensions of one security boundary. That distinction exposes the risk, so it is worth talking about clearly and examining without blinders.
A vendor that sells you ten unrelated products has sold you ten things. If one is compromised, you have a compromised product, and the other nine stand behind their own authentication, their own credentials, their own administrative planes. The failure is contained by architecture, not by luck. A vendor that sells you ten integrated products has sold you one product with many interconnected facets. The products authenticate through a common identity service, they are administered through a common management plane, and they extend trust to each other by design, because that mutual trust is precisely what makes the integration valuable. Single sign-on, unified policy, automatic enrolment, shared telemetry: every convenience on the feature list is a trust relationship on the architecture diagram, and each one needs to be examined in that light, asking who owns it, who can access it, and who controls it.
Compromise the common element and the compromise is not contained. It propagates along the same integration paths that the sales material celebrates. The identity plane that signs a user into email also signs that user into the document store, the device manager, the security console, and the AI assistant that has been granted standing access to all of the above. The feature and the failure mode are the same object viewed from opposite sides.
This is a systems principle, not an accusation. It applies to any sufficiently integrated platform from any vendor, and it applies outside computing entirely. Aviation engineers call it common-mode failure: the condition where nominally redundant systems fail together because they secretly share a dependency. Redundancy that shares a dependency is not redundancy. It is one system with extra steps. Enterprise security has spent a decade building exactly this structure and calling it defence in depth. Multiple products, multiple layers, multiple controls, one identity plane underneath all of them. The layers are real, but the independence is not, and the exposure scales with the plane: the more systems one identity plane underwrites, the greater the risk carried by its failure.
What remains is to examine what that structure looks like when it fails, why the clearest available case study is Microsoft, why the same logic already governs how sophisticated organizations think about AI dependence, and why the industry's most consequential architectural question is one almost nobody asks at procurement time: if this trusted component suddenly becomes unavailable, compromised, or no longer trustworthy, how much of the organization continues to function?
SECTION 6
Microsoft as Case Study
Microsoft is the case study for one reason, and it is not misconduct. It is scale, and a design focused on customer need and business revenue. The combination of Windows, Entra ID, Microsoft 365, Exchange, Defender, Sentinel, Azure, Intune, and Copilot forms the largest shared identity and management plane in enterprise computing, one plane underwriting the daily operation of governments, critical infrastructure, and a large fraction of the world's businesses. The scaling principle applies directly: the more systems one identity plane underwrites, the greater the risk carried by its failure, and no plane underwrites more than this one. In 2023, that risk stopped being theoretical.
The events are established in the public record. Between May and June 2023, a threat actor tracked as Storm-0558 and assessed to be affiliated with the People's Republic of China accessed Exchange Online mailboxes belonging to 22 organizations and more than 500 individuals, among them senior United States officials responsible for managing the relationship with China.7 The actor did not phish an administrator or exploit a customer's misconfiguration. It held a Microsoft consumer signing key, issued in 2016, and used it to forge authentication tokens, and a flaw in token validation meant that a key intended only for consumer accounts was accepted for enterprise ones. The key had been scheduled for retirement in March 2021 and was still in service two years later. The intrusion was detected not by Microsoft but by a customer, when analysts at the U.S. Department of State noticed anomalies through detection rules their own team had built on premium audit logging.
The Cyber Safety Review Board conducted the authoritative review, and its conclusions were unusually blunt for a public inquiry. The Board found the intrusion “preventable,” stated that it should never have occurred, described a long chain of avoidable security failures, and judged Microsoft's security culture inadequate, shaped by operational and strategic decisions that had deprioritized enterprise security investment in a company whose centrality in the technology ecosystem demanded the opposite.7 Two details in the record deserve particular weight. The first is that, as of the report's publication, Microsoft did not know how or when the actor obtained the key. The second is that meaningful detection required premium logging that many customers had not purchased, which meant visibility into a provider-side failure was itself a paid feature. Microsoft made that logging free after the incident, which was the correct response and also an admission of what the previous arrangement had been.
The engineering failures matter, and the architectural reading matters more. Consider what any victim organization could have done differently: nothing. No conditional access policy, no multi-factor rollout, no tenant hardening guide addressed a forged token signed with the provider's own key, because every control the victims owned operated below the plane where the failure occurred. The failure happened in the layer no customer can vet, with a credential no customer knew existed, discovered through telemetry most customers could not afford, in an incident the provider itself could not fully explain. Ownership, access, and control, the three questions every trust relationship should face, were answered by events: the customers owned none of it, could not see who reached it, and controlled nothing that would have stopped it.
Two honest qualifications complete the case study. Microsoft responded seriously, launching its Secure Future Initiative, hardening key management, and expanding free logging, and the record does not support a claim that Microsoft is uniquely negligent among providers. Storm-0558 has been tracked for over twenty years and is linked by industry to the 2011 theft of RSA SecurID seed material, because sophisticated actors have always hunted concentrated key material; it is the highest-value object in computing precisely because of what it unlocks.7 And that is the point that survives every qualification. The incident was not an aberration in an otherwise sound structure. It was the structure behaving exactly as designed under hostile conditions, at the largest plane in the industry, and the plane has only grown since, with AI assistants now holding standing access inside the same trust boundary.
SECTION 7
AI and the Blast Radius Principle
On 26 July 2026, Satya Nadella gave an interview to Fareed Zakaria on CNN that deserves close reading, because in it the chief executive of the largest platform company in the world articulated the resilience principle this analysis has been building toward, applied to artificial intelligence. His advice to businesses using AI was direct. Retain your data, your prompts, and the metadata generated every time you use a model, because that record is what would let you train weights of your own. Keep the harness, the context, and the memory separate from any single model, so that you can use several models and remain in control if one disappears. A firm that lacks this control, he said, “will not remain a firm because you've essentially outsourced your thinking.”8
Strip away the AI vocabulary and this is the working question in different clothes. If this model suddenly becomes unavailable, compromised, or no longer trustworthy, how much of the firm's capability continues to function? Nadella's prescription answers it the way a resilience engineer would: keep the assets that make the dependency valuable, the context, the memory, the orchestration, and the record of use, outside the dependency's trust boundary, so that the dependency stays substitutable. Substitutable dependence is manageable dependence. Dependence without substitution is the outsourcing of a function, and a function outsourced without an exit is a function that can be lost.
The consistency question follows on its own. If dependence on a single AI model threatens a firm's survival because its thinking has moved outside its control, dependence on a single platform deserves the same scrutiny, because what sits inside the platform is not thinking but functioning. The identity plane is the organization's memory of who its people are. The communication and document systems are its memory of what it knows and has decided. The management plane is the orchestration of everything it operates. An organization that cannot authenticate, communicate, or administer itself when one provider fails has outsourced not its thinking but its ability to act, and no consistent application of Nadella's principle can exempt the platform that employs him, or any of its competitors, from the standard he set for AI. This is not an accusation of hypocrisy. The advice is correct, and correct advice earns consistent application: retain your context, preserve your orchestration, avoid dependence on any single provider, and remain in control if one disappears.
AI then raises the stakes on the platform side of the comparison, because the two subjects are converging. Assistants and agents do not arrive as separate systems with separate credentials. They join the existing plane, authenticate through the same identity service, and hold standing access to the mail, documents, and telemetry the plane already unifies, and increasingly they hold delegated authority to act. The blast radius of the shared plane now extends beyond reading an organization's information to doing things in the organization's name. The trade is the familiar one, capability purchased through trust extension, and it means the single-model warning and the single-plane exposure are the same lesson at two layers. The organizations best positioned for the AI era will be the ones that learned it at both.
SECTION 8
Google, AWS and the Industry
None of this is a Microsoft condition, and the structural analysis applies across the industry with the same evenhandedness. Google operates the same architecture at comparable scale. Workspace and Cloud Identity consolidate mail, documents, meetings, and device management under one Google account and one admin console, and a compromise of that account layer or of Google's own signing infrastructure would propagate exactly as the model predicts. Amazon concentrates differently but no less consequentially. AWS Identity and Access Management is the control plane for a vast share of the world's production infrastructure, and AWS Organizations extends it so that a compromised management account governs every account beneath it. The market is different; the architecture is the same.
The identity and security vendors deserve particular attention, because their products are the trust concentration. Okta's offering is the shared identity plane sold as a standalone service, which makes Okta a super-administrator for thousands of organizations that run nothing else of Okta's, and its 2023 support-system breach demonstrated the provider-side path into customer sessions in miniature.4 Palo Alto Networks named its strategy plainly, describing the folding of firewalls, cloud security, and security operations into a single offering as platformization.9 CrowdStrike's consolidation pitch is equivalent, and its July 2024 content update demonstrated what the availability side of a trusted channel looks like at scale.6 The companies selling protection from concentrated risk are pursuing concentration as their growth strategy, and there is no contradiction in their doing so, because the economics reward it. That is precisely the problem.
The universality now has a regulatory echo, because the institutions responsible for systemic risk have started to treat providers as systemic. Financial regulators developed the vocabulary first, in concentration risk, and the European Union's Digital Operational Resilience Act goes further, establishing direct oversight of ICT third-party providers designated as critical to the financial sector, on the explicit reasoning that a provider's failure is a systemic event for everyone built on it.10 Regulation is a lagging indicator, and its arrival is the clearest available confirmation that the exposure described here is real. Authorities do not build oversight regimes for hypothetical risks.
The conclusion of the industry survey is the one that matters for decisions. Changing vendors does not exit the structure, and changing jurisdictions does not either, since every provider answers to some flag and every platform concentrates by design. The exposure is escaped only by architecture, and the question an organization should be asking is never which platform to trust, but how much of the organization still stands when any platform fails.
SECTION 9
Security versus Resilience
Security and resilience are different objectives, and the difference is worth stating with some rigour, because the trade between them, whose price the customer ultimately pays, is the missing conversation and the big-picture view where the analysis converges. Security is concerned with the likelihood of compromise: keeping hostile actors and failures out, reducing the probability that a bad day begins. Resilience is concerned with behaviour under failure: what continues to function once the bad day has started, how far the damage spreads, and how the organization recovers. Mature engineering disciplines hold the two apart as a matter of course. Automotive engineering distinguishes collision avoidance from crashworthiness, and no serious manufacturer argues that good brakes make airbags unnecessary. Enterprise computing routinely collapses the two into the single word security, out of convenience, misunderstanding, or marketing need, and the collapse is where the trade hides.
Consolidation trades the two against each other through one mechanism, the shared plane. The plane raises the security average honestly: consistent policy, unified patching, integrated monitoring, and professional operations reduce the routine failures that produce most incidents. The same plane couples failure domains, so the incidents that do occur are correlated across everything the plane touches. The everyday failures become fewer and the catastrophic ones become larger, which is the trade stated as engineering rather than as marketing. The resilience discipline exists to face this squarely. NIST's cyber resiliency engineering framework begins from the assumption that compromise will occur and asks systems to anticipate, withstand, recover, and adapt,11 which is a formal way of saying that resilience is engineered in advance or not at all. The hospital that runs on paper charts through a network outage did not improvise that ability during the outage. Someone designed it, funded it, and rehearsed it while the network still worked.
Why, then, does the trade keep being made? The most honest answer is a measurement asymmetry. Security improvements are measurable on a quarterly cadence: incident counts fall, patch compliance rises, scores improve, and every stakeholder from the analyst to the board sees the line move. Resilience is tested only by rare events, so its erosion produces no signal at all. The organization that quietly loses its ability to function without its platform sees nothing on any dashboard, and may in fact watch every measured metric improve while it happens. Organizations optimize what they can measure, and consolidation flatters every measured metric while consuming the unmeasured one. The vendor's numbers are real. The erosion is real. Both are true at once, and only one of them appears in the budget and on the executive suite's agenda. And when a problem finally exposes the erosion, it registers as a serious loss and a post-mortem mention, and even then it often fails to cycle into the yearly awareness process, so the organization absorbs the incident without absorbing the lesson, and the asymmetry resets for another cycle.
What resilience actually looks like, as an organizational property, is concrete. Identity that can fail without stopping the business, because break-glass access and offline authentication paths exist and are tested. Communications with an out-of-band channel that does not share the platform's fate. Degraded-mode operations that are planned, documented, and rehearsed rather than invented mid-incident. Exit capability preserved while it is still affordable, in data formats, in contracts, and in institutional knowledge. None of this can be purchased as a feature, because resilience is a property of the organization's architecture and preparation, not of any product inside it, and no platform can sell independence from itself.
SECTION 10
What Should Be Done
The first correction is conceptual, and it dissolves the assumption on which the entire one-bucket model rests. Operating at scale does not require a single integrated platform. That equation, scale therefore consolidation, is an un-engineered simplification, and it entered the industry through marketing rather than through need. No requirements analysis produced it. It is what organizations absorb when they respond to vendor messaging instead of their own environment. Every other discipline that engineers at scale reaches the opposite conclusion: aircraft separate flight controls from cabin systems, power grids partition into islands that can shed and reconnect, and naval architects divide hulls into compartments precisely so that one breach does not become a sinking. Scale in serious engineering produces segmentation and independence of critical functions. Only in enterprise IT has scale been sold as a reason to merge everything behind one identity plane, and the difference is not that IT discovered a better principle. The difference is that IT let its architecture be designed by its procurement.
The discipline that corrects this already exists, and it needs to be embedded into security decisions rather than treated as a specialty for defence programmes. Systems Security Engineering, in the sense of NIST SP 800-160 rather than the Gartner market category that shares the acronym, treats security as an engineering concern that must be present from requirements onward: identifying critical assets, modelling threats at the architectural level, evaluating trade-offs explicitly, and producing verifiable evidence for why a system deserves trust.11 Peter Hillier has made the sharpest recent case for this discipline, arguing that Zero Trust, whatever its merits as a runtime enforcement posture, is incomplete because it treats access as the whole problem and cannot guide the design of the system it protects; in his formulation, Zero Trust is the bouncer while systems security engineering is the architect.12 Applied to the platform question, the discipline changes what a procurement decision is. Before an organization adopts an integrated platform, systems security engineering requires it to model what the shared trust boundary actually contains, to treat the provider itself as a dependency with failure modes, to ask what continues to function when the common element fails, and to demand evidence rather than assurances. Hillier extends the same argument to the supply chain, and it lands directly on trust concentration itself: contract clauses, attestations, and certifications cannot reveal whether an architecture over-trusts a third-party service, whether a critical dependency has quietly become a single point of mission failure, or whether update mechanisms are constrained, monitored, and recoverable.13 Those are engineering questions, and only engineering work answers them.
This points to the final and least welcome correction, which is cultural. In security there is no easy solution, and the marketing of one is itself a signal worth flagging as a problem. A vendor whose pitch is that complexity disappears inside their platform is asking the organization to relocate its complexity, not eliminate it, and to relocate it into a layer the organization can no longer see, audit, or revoke. Any offering marketed as the simple answer to enterprise security should be treated as questionable on that basis alone, because the claim misrepresents the nature of the problem. What actually reduces risk is unglamorous: understanding your own environment, mapping the dependencies you have rather than the ones the reference architecture assumes, analyzing failure modes before they are demonstrated for you, preserving exit capability while it is still affordable, and doing that work continuously as the environment changes. This is hard work, and it is a necessity rather than an option, because the alternative is not a simpler security posture. The alternative is an unexamined one that opens your organization to extreme risk, held together by a vendor's assurances, waiting for the day events answer the working question and expose an internal lack of knowledge and process that was there all along.
SECTION 11
Over fifteen years, enterprise computing traded many small, independent failure domains for a few very large shared ones. The shift happened almost quietly, and the few who voiced concerns were dismissed as resistance against progress and security itself. It emerged from rational behaviour on both sides of every transaction: buyers reducing friction and acquiring skills they could not hire, vendors deepening integration because integration is what retains customers. The benefits were real and remain real, and the cost was structural, cumulative, and absent from every document in which the exchange was agreed. What was purchased was a better average day. What was paid was the independence of everything behind one identity plane, the ability to vet the people holding the greatest access, the capacity to function when the shared layer fails, and a transfer of ownership and control away from the customer and onto the operating business, without any assurance of accountability or transferability in return.
The evidence carries the argument without embellishment. Storm-0558 demonstrated a provider-side compromise crossing tenant boundaries with a credential no customer knew existed, at the largest plane in the industry, in an incident the provider could not fully explain. SolarWinds, Kaseya, NotPetya, Okta, and CrowdStrike demonstrated the same propagation through build systems, management platforms, support systems, and update channels, and Crypto AG demonstrated that even the ownership of a vendor cannot be assumed. Every one of these was a failure in a layer the affected customers could not name, screen, supervise, or remove. The honest accounting holds both truths at once. The organizations on these platforms were, on the typical day, harder to compromise than they would have been alone, and on the atypical day they discovered their fate was coupled to thousands of strangers through a single point of trust, with the price of the coupling paid by them and not by the parties who designed it.
The corrective does not require a new idea, because every principle needed is already evident in other industries that have gone through the same pain points, lessons that IT security has somehow missed. Aviation, power, and naval engineering already build scale through segmentation and independent failure domains. Systems security engineering already exists as a discipline and asks the right questions at the right time. Somehow even the industries that learned these lessons in steel and at sea are having difficulty applying the same principles to their own IT systems, operating compartmentalized hulls and partitioned grids on top of consolidated identity planes, as if the discipline applied to everything except the computing that now runs it. The chief executive of the largest platform company has already articulated the standard, telling enterprises to retain their context, keep their memory and orchestration separate from any single model, and remain in control if a provider disappears, on the grounds that a firm without that control has outsourced something it cannot remain a firm without. Nothing in that standard is specific to AI. The work is not invention. The work is consistency, applying the industry's own best principles to the platforms where they are least welcome, because that is where the concentration is greatest.
The practical instrument is one question, asked before any contracts are signed rather than after the incident, and asked even in emergencies and under stress, because pressure is exactly when skipping it multiplies errors: if this trusted component suddenly becomes unavailable, compromised, or no longer trustworthy, how much of the organization continues to function? The question applies without modification to an AI model, an identity provider, a cloud platform, an enterprise security suite, and a nation's digital infrastructure, because all of them are the same object at different scales, a concentration of trust that something else depends on. The question will not ask itself. The cycle does not self-correct, since incidents produce post-mortems and post-mortems fail to be reflected in operations unless their lessons are specifically highlighted and chosen, so the question survives only where someone puts it in the budget, on the agenda, and in the procurement template, and keeps it there. An organization that can answer it has options, degraded modes, and an exit. An organization that cannot has paper assurances and no backup plan when things go wrong.
None of this argues for abandoning platforms, and none of it can honestly be read as nostalgia for a dozen consoles and brittle integrations. The platform era is not reversible and, on its own terms, not regrettable. The argument is narrower and harder. The trade at its centre must be made with open eyes, priced in the budget, owned by executives who are held accountable for it, and engineered against by the organizations they serve, because examined or not, it is already the reality they operate in. A hidden trade, fixing one problem and inheriting an even bigger one, does not go away because nobody discusses it. The only decision actually available is whether to see it, and the organizations that choose to see it will be the ones still functioning on the day the question stops being hypothetical. That day is approaching faster than the fifteen-year arc suggests, because AI is transforming the speed of scale, folding new capability and new authority into the same shared planes in quarters rather than decades, and it has moved this challenge from the background of enterprise architecture to the forefront. The trade is compounding while the conversation is still missing. Caveat emptor.
Endnotes and Sources
AI collaboration: this essay was researched, drafted, and source-verified in collaboration with Claude (Anthropic). All positions, judgments, and final wording are the author's.
Footnotes
Crypto AG / Operation Rubicon. Crypto AG, a Swiss manufacturer of encryption equipment, was secretly owned from 1970 by the U.S. Central Intelligence Agency and Germany's Federal Intelligence Service (BND), and sold deliberately weakened devices to more than 100 governments; the BND exited in the early 1990s and the CIA retained ownership until the company's sale in 2018. Greg Miller, “The intelligence coup of the century,” The Washington Post, 11 February 2020, joint investigation with ZDF and SRF, https://www.washingtonpost.com/graphics/2020/world/national-security/cia-crypto-encryption-machines-espionage/, accessed 7 August 2026. ↩
SolarWinds Orion supply chain compromise (SUNBURST), disclosed December 2020. SolarWinds stated in its Form 8-K filed with the U.S. Securities and Exchange Commission (14 December 2020) that up to approximately 18,000 customers may have installed the trojanized Orion update. See also CISA Cybersecurity Advisory AA20-352A, “Advanced Persistent Threat Compromise of Government Agencies, Critical Infrastructure, and Private Sector Organizations,” 17 December 2020 (last revised 15 April 2021), https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a, accessed 7 August 2026. ↩
Kaseya VSA supply chain ransomware attack, July 2021. REvil ransomware was distributed through a vulnerability in the Kaseya VSA remote management platform, affecting managed service providers and, per Kaseya's estimates, fewer than 1,500 downstream businesses. CISA, “Kaseya Ransomware Attack: Guidance for Affected MSPs and their Customers,” July 2021, https://www.cisa.gov/news-events/news/kaseya-ransomware-attack-guidance-affected-msps-and-their-customers, and CISA-FBI joint guidance, 4 July 2021, https://www.cisa.gov/news-events/alerts/2021/07/04/cisa-fbi-guidance-msps-and-their-customers-affected-kaseya-vsa-supply-chain-ransomware-attack, both accessed 7 August 2026. ↩
Okta support case management system breach. From 28 September to 17 October 2023, a threat actor using a compromised service account accessed files associated with 134 Okta customers, including HAR files containing session tokens later used to hijack the sessions of five customers; a subsequent review found the actor had also run a report containing names and email addresses of all customer support system users. David Bradbury (Chief Security Officer, Okta), “Tracking Unauthorized Access to Okta's Support System,” 20 October 2023, https://sec.okta.com/articles/2023/10/tracking-unauthorized-access-oktas-support-system/; “Root Cause and Remediation,” 3 November 2023, https://sec.okta.com/articles/2023/11/unauthorized-access-oktas-support-case-management-system-root-cause/; “Update and Recommended Actions,” 29 November 2023, https://sec.okta.com/articles/october-security-incident-recommended-actions/, all accessed 7 August 2026. ↩ ↩2
NotPetya, June 2017. The destructive malware was seeded through the compromised update mechanism of M.E.Doc, Ukrainian accounting software, and propagated globally across firms including Maersk and Merck. The White House, Statement from the Press Secretary, 15 February 2018, attributed the attack to the Russian military and described it as the most destructive and costly cyber-attack in history, causing billions of dollars in damage across Europe, Asia, and the Americas; as reported by CNN, “White House blasts Russia for NotPetya cyberattack,” 15 February 2018, https://www.cnn.com/2018/02/15/politics/white-house-russia-notpetya, accessed 7 August 2026. ↩
CrowdStrike Falcon content update incident, 19 July 2024. A faulty channel file update caused system crashes on approximately 8.5 million Windows devices. David Weston (Vice President, Enterprise and OS Security, Microsoft), “Helping our customers through the CrowdStrike outage,” The Official Microsoft Blog, 20 July 2024, https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/, accessed 7 August 2026. See also CrowdStrike, Preliminary Post Incident Review, July 2024. Not a compromise but a demonstration of update-channel blast radius. ↩ ↩2
Storm-0558 intrusion, May to June 2023, disclosed July 2023. A threat actor assessed to be affiliated with the People's Republic of China acquired a Microsoft account consumer signing key issued in 2016 and used it, together with a token-validation flaw that accepted consumer-signed tokens for enterprise accounts, to access Exchange Online mailboxes of 22 organizations and more than 500 individuals; Microsoft's initial disclosure cited approximately 25 organizations. Cyber Safety Review Board, Review of the Summer 2023 Microsoft Exchange Online Intrusion, dated 20 March 2024 and released 2 April 2024, https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewOfTheSummer2023MEOIntrusion508.pdf, accessed 7 August 2026. ↩ ↩2 ↩3 ↩4
Satya Nadella, interview with Fareed Zakaria, Fareed Zakaria GPS, CNN, aired 26 July 2026, https://www.cnn.com/2026/07/26/business/video/gps-0726-microsoft-interview-satya-nadella, accessed 7 August 2026. See also TechCrunch, “Satya Nadella says companies that trust one AI for everything may not survive,” 27 July 2026, https://techcrunch.com/2026/07/27/satya-nadella-says-companies-that-trust-one-ai-for-everything-may-not-survive/, accessed 7 August 2026. ↩
Palo Alto Networks announced its “platformization” strategy on its fiscal second-quarter 2024 earnings call, February 2024 (chief executive Nikesh Arora), and has since described it as the company's core strategy; see Palo Alto Networks, fiscal Q4 2024 earnings release (Form 8-K exhibit), 19 August 2024, quoting Arora on “strong execution on our platformization strategy,” https://www.sec.gov/Archives/edgar/data/1327567/000132756724000023/ex991q424earningsrelease.htm, and Futuriom, “Palo Alto Shares Plunge on Strategy Shift,” February 2024, https://www.futuriom.com/articles/news/palo-alto-shares-plunge-on-strategy-shift/2024/02, both accessed 7 August 2026. ↩
Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA), applying from 17 January 2025, including a pan-European oversight framework for ICT third-party service providers designated as critical (designation criteria specified in Commission Delegated Regulation (EU) 2024/1502), https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng, accessed 7 August 2026. ↩
NIST Special Publication 800-160, Volume 1 Revision 1, Engineering Trustworthy Secure Systems (Ron Ross, Mark Winstead, Michael McEvilley, November 2022), https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final, accessed 7 August 2026, and Volume 2 Revision 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach (2021), linked from the Volume 1 publication page; direct DOI https://doi.org/10.6028/NIST.SP.800-160v2r1 [UNVERIFIED; alternative: navigate from the Volume 1 page above]. ↩ ↩2
Peter Hillier, “Beyond the Buzzword: Why Systems Security Engineering Delivers More Than Zero Trust Ever Could,” Medium, 17 June 2025, https://medium.com/@pjhillier/beyond-the-buzzword-why-systems-security-engineering-delivers-more-than-zero-trust-ever-could-e60065804d0d, accessed 7 August 2026. ↩
Peter Hillier, “Supply Chain Security Is Not Just a Procurement Clause,” Medium, 7 April 2026, https://medium.com/@pjhillier/supply-chain-security-is-not-just-a-procurement-clause-702645a8614d, accessed 7 August 2026. See also Peter Hillier, “Systems Security Engineering Is Supply-Chain Security (Whether Industry Likes It or Not),” Medium, 11 February 2026, https://medium.com/@pjhillier/systems-security-engineering-is-supply-chain-security-whether-industry-likes-it-or-not-31971977f28f, accessed 7 August 2026. ↩
Microsoft seems to be repeating errors from its past in the pursuit of marketable “tools” and “features,” sacrificing safety and privacy for dominance. This is not a new pattern. In the late 1990s and early 2000s, Microsoft made a deliberate decision to integrate Internet Explorer directly into the operating system, not because it was the safest architecture, but because it was a strategic one. The browser became inseparable from Windows, not merely as a convenience, but as a lever to eliminate competition and entrench market control. The result was not only the well documented U.S. antitrust case, but a security disaster of historic scale, where untrusted web content was processed through deeply privileged OS components, massively expanding attack surface across the entire installed base. The record of that era is clear: integration was a business tactic first, and the security consequences were treated as collateral. 
