Zero Trust Reaches the CMS Last

If you hold a security accreditation and an estate of client websites, you have probably watched a zero-trust programme move through your infrastructure in a predictable order. Identity first, because there is a product for it. Then devices, then the network, then workloads. Somewhere near the end, someone opens the content management system that runs forty client sites and discovers that the model does not obviously apply to it at all.

That is not a failure of the programme. It is a property of where a CMS puts its trust boundary, and it is worth understanding precisely, because it is the tier a procurement reviewer will eventually ask you about and the one your architecture diagram is quietest on.

What does zero trust actually require?

The useful definition is not "trust nothing." It is the seven tenets NIST sets out in SP 800-207, which CISA's Zero Trust Maturity Model reproduces as its own foundation: all data sources and computing services are considered resources; all communication is secured regardless of network location; access to individual enterprise resources is granted on a per-session basis; access is determined by dynamic policy; the enterprise monitors and measures the integrity and security posture of all owned and associated assets; all resource authentication and authorization are dynamic and strictly enforced before access is allowed; and the enterprise collects as much information as it can about the current state of assets, infrastructure and communications, and uses it to improve its posture.

Read those as engineering requirements rather than as principles and two of them are much harder than the rest. Per-session access and dynamic policy mean that a decision made once, at login, is not sufficient. Almost every content management system in production was designed on the opposite assumption.

Why does the CMS end up last?

CISA's model, published in April 2023 in version 2.0, divides the work into five pillars — Identity, Devices, Networks, Applications and Workloads, and Data — with three cross-cutting capabilities running through all of them: visibility and analytics, automation and orchestration, and governance. Progress is described as a journey from a Traditional starting point through Initial and Advanced to Optimal, and the model is explicit that each pillar can advance at its own pace.

In practice they advance at very different paces, for an unglamorous reason. Identity, devices and networks are pillars where you can buy the maturity: an identity provider, a device management platform, a network policy layer. Applications and Workloads is the pillar where somebody has to change how the application itself makes decisions — and if the application is a third-party CMS, that somebody is not you.

So the CMS is not skipped because it is unimportant. It is skipped because it is the one pillar where the purchasing lever does not work, and the estate keeps running while the question waits.

Where does a CMS put its trust boundary?

Inside itself. That single sentence is the whole problem, and it shows up in four specific places.

An extension runs with the application's privileges. A module, plugin or add-on is not a guest in the process — it is the process. Whatever the application can read, the extension can read. There is no per-request decision between them because there is no boundary between them.

An editor session is a standing principal. The system authenticates a person once, resolves a role, and then treats every subsequent action as pre-authorised for the life of that session. That is the definition of the Traditional stage, not a misconfiguration of it.

The template layer executes. Anything that renders dynamic content is running code at request time, and in most systems that code has the same reach as the application around it.

The content store is trusted by whatever sits above it. The database does not ask which plugin is asking.

None of those four is reachable by a network control, a device posture check or an identity provider. You can hold a mature posture in four pillars and have all four of these conditions live in production, because they are all inside the fifth.

Does moving to static sites solve it?

For part of the estate, genuinely yes. A site compiled to static files and served from a CDN has no request-time application to compromise, and for brochure sites that is a real reduction, not a rhetorical one. It is also the reason so many teams have quietly moved that half of their work.

Then look at what stays. Commerce, customer portals, anything with a login, anything personalised, anything with a form that writes somewhere, and every site whose editors need to publish without a developer. Those are precisely the sites that cannot be compiled away, and they are also the ones carrying customer data.

So the honest description of the static migration is concentration, not reduction. The easy half of the estate leaves. The risk that remains is now a larger share of a smaller surface, sitting in the systems your team has just stopped thinking about daily. If you are reporting maturity by counting sites, this looks like progress; if you are reporting it by counting exposure, it is close to flat.

What does "Application Access" maturity actually ask of a CMS?

The model is specific enough to test yourself against, which is what makes it useful rather than aspirational. In the Applications and Workloads pillar, the Application Access function describes the Traditional stage as authorising access "primarily based on local authorization and static attributes." The Initial stage begins to incorporate contextual information — identity, device compliance, other attributes — per request, with expiration. The Advanced stage automates those decisions with enforced expiration under least-privilege principles. The Optimal stage authorises continuously, incorporating real-time risk analytics and behavioural factors.

Now hold a normal CMS admin login against that ladder. One authentication event, a role resolved from a local table, a session cookie with a long lifetime, and no re-evaluation until it expires. That is the Traditional column, described accurately. It is not a finding against any particular product; it is the design that nearly all of them share, and it means the CMS tier of an otherwise Advanced programme is sitting at the left-hand edge of the table.

What about the code you did not write?

The same pillar contains a function CISA added in version 2.0 — Secure Application Development and Deployment Workflow — and its ladder is the one most CMS estates read worst. The Traditional stage is ad hoc development, testing and production environments with non-robust deployment. Advanced removes developer access to the production environment for code deployment. Optimal leverages immutable workloads where feasible, "only allowing changes to take effect through redeployment," with administrator access to deployment environments removed in favour of automated processes.

An estate where a developer edits a template in production is not slightly behind that ladder. It is outside it. And the extension question sits underneath: every add-on you install is code you did not write, running with the privileges described above, on a patch chain you do not control. We have written that argument out separately in the patch-chain question to ask about any platform, and it is the same question a zero-trust reviewer is really asking here.

Where does security testing land when the application is a platform?

The Application Security Testing ladder moves from manual pre-deployment testing, through static and dynamic methods, to testing integrated across the software development lifecycle with routine automated testing of deployed applications. That is written for an organisation that owns its application code.

When the application is a vendor's platform, the ladder splits in two. Your testing covers your configuration, your templates, your integrations. The engine underneath is the vendor's, and your evidence about it is whatever the vendor publishes. Two practical consequences follow, and both belong in your bid paperwork rather than in a conversation: find out what the vendor tests and what it will show you, and read your contract before you scan anything, because platform agreements commonly require prior written approval before a customer runs a penetration test.

What should a zero-trust reviewer ask a CMS or DXP?

These are the questions, not our answers. Every one of them has a factual answer that a platform can provide or fail to provide, which is the property that makes a question worth asking in an evaluation.

What is the blast radius of one compromised editor account — can that account reach other clients' sites, the file system, or outbound network calls? Do extensions execute with the platform's own privileges, and is there any isolation between an extension and the content of other tenants? Can a session be invalidated centrally, and what is its maximum lifetime? Are development, staging and production genuinely separate environments, and can a change reach production without passing through them? Who executes the patch chain for the engine, on what cadence, and how are customers told? What does the platform emit that your own monitoring can consume? What is the documented process, with named roles, when something goes wrong? What data leaves the region you selected, and under what circumstances? Which sub-processors touch customer content, and how are changes to that list communicated? And finally: which of the above is contractual, and which is a marketing page?

That last one is the sharpest instrument in the list. A commitment that appears only in marketing copy is generally not a commitment at all, and platform agreements frequently say so in as many words.

What can we answer, and what can't we?

Two things belong here for the same reason: a reviewer's time is worth more than our positioning. WebinOne passed the AWS Foundational Technical Review on 30 August 2026, valid to 30 August 2028, and has completed the AWS Well-Architected Review. Those are dated facts about a review that AWS conducts, and they are worth exactly what a technical review is worth to you — which for some bids is a box ticked and for others is nothing at all.

The absences matter more, and they are already published rather than disclosed reluctantly here: WebinOne holds no FedRAMP authorisation, is not CMMC-certified, and runs in AWS commercial regions rather than AWS GovCloud, with no installable artefact carrying a published patching cycle. If your bid requires any of those, that is a fast no rather than a slow one. We set that out in full, with the reasoning, in where WebinOne is the wrong choice.

What you will not find in this article is a paragraph explaining that our own controls are sound. That would be the exact move the rest of this piece argues against — an unverifiable control claim, published by the party it flatters. The questions above apply to us as written, and the place to put them is the security review page we maintain for exactly that purpose.

Why does this land harder on an integrator than on a platform vendor?

Because the accreditation is yours. The framework obligations you have taken on — whatever the specific regime — attach to your firm, and they attach across the whole delivery estate, including the parts running on somebody else's software. A platform vendor's certificate does not transfer to your bid, and your customer's reviewer will ask you, not them.

That asymmetry is also why the CMS tier is worth closing rather than deferring. It is the tier where your programme's evidence runs out, and it is the one your competitor's proposal will not have thought about either. Arriving at a security review with a specific, boring answer about the content layer — who can change what, what is logged, who patches the engine, what happens when an editor account is stolen — is a differentiator precisely because it is unusual.

Where does this leave the estate you already run?

With a smaller job than it looks. You are not rebuilding a CMS to satisfy a maturity model. You are answering ten questions about the tier you have been treating as furniture, discovering which answers you do not have, and deciding which of those you can get from your platform, get from your own process, or must disclose as a gap. The gaps you disclose cost you far less than the ones a reviewer finds.

If you are weighing the platform layer itself, the questions above are the same ones we set out in our checklist for evaluating a white-label DXP, and the delivery mechanics — portal, roles, environments, handover — are described in how integrators run delivery on WebinOne. For a migration off a legacy platform, the platform-side requirements are in what an integrator needs from the platform during a migration. The platform overview covers the environment itself, partner terms are on the partner programme page, and if the shortest path is a conversation, talk to us.