When we’re shortlisted for platform builds, procurement teams often assume a proprietary CMS is safer because a single vendor is accountable.
Both models have security trade-offs, and they’re worth understanding before you sign a long contract, because changing platforms later can be expensive.
What a proprietary platform gives you
A platform like Sitecore or Adobe Experience Manager, or a SaaS CMS, gives you a single supplier responsible for the core product, a support contract with defined response times, and a vendor with its own certifications you can point to in a supplier questionnaire.
With a SaaS platform the vendor also runs the infrastructure, which can save work for teams with limited technical capacity.
What it costs you
With a proprietary platform you can’t inspect the code, so you’re relying on the vendor’s word about how it’s built and tested.
When a vulnerability is found, the vendor decides when it’s disclosed, how much detail is shared and when the fix ships. If you need a security control the product doesn’t offer, such as a specific SSO setup, a particular data residency arrangement or a WAF rule in front of an admin route, you’re waiting on their roadmap.
Proprietary platforms also tend to store content in their own structures and couple tightly to their own tooling, which can make leaving expensive and slow, including when the vendor’s security falls short.
Proprietary vendors do ship security patches, and several have released serious ones this year. Part of what you’re paying for is the vendor making those security decisions on your behalf.
What open source gives you
With an open source CMS the code is public, so anyone can read it, test it and report problems, and fixes are developed and published in the open.
WordPress is the obvious example, with a dedicated security team that handles reported vulnerabilities through a coordinated disclosure process, and minor security releases are applied to core automatically by default.
WordPress runs around 40% of all websites (W3Techs, October 2026), so its code is reviewed by security researchers, hosting companies and agencies worldwide.
Payload is a newer open source option, built in TypeScript and MIT licensed, with its code public on GitHub.
It runs inside your own application, so you control where it’s hosted and how it’s patched, and its access rules are written as code at collection, field and operation level, which means they’re reviewed and version-controlled alongside the rest of the build.
Sanity is only partly open source, with its Studio editing interface open source and the content backend a hosted service run by Sanity, which we cover in the next section.
You also choose where it’s hosted and who supports it, and you can add controls such as SSO or restricted admin access yourself.
What open source asks of you
An open source platform needs someone to run it properly, and most of the problems we see on open source sites come from this.
Updates need applying, hosting needs to be configured and monitored, and the extensions you add need vetting.
With WordPress, the core is well maintained, but the plugin ecosystem varies significantly in quality, and plugins account for the large majority of disclosed WordPress vulnerabilities. We covered that in detail in our look at this year’s Wordfence data.
On a self-hosted platform the hosting is your responsibility, and it needs the same care as the application: managed server patching, tested backups, failover and a clear answer on data residency. Our dedicated hosting covers this, with every environment running on a pair of physical servers in active failover, OS and library patching managed under our data centre’s ISO 27001 information security management system, and data kept in the UK, or in the US, Europe or APAC where a client needs it.
When a vulnerability is published on an open source platform, the fix and the information needed to exploit it become available at the same time. Automated tooling now picks up new disclosures within hours, which is why patching speed matters so much on open source platforms, and why our Cyber Shield SLA patches anything high or critical within one day. On sites that aren’t actively maintained, that gap can stay open for months. If you want to see how many vulnerabilities have been disclosed against your own site, try our vulnerability tracker.
Open source can give you more control over your security, provided someone is actively managing the platform.
The three models in practice
With headless platforms in the mix, there are broadly three models to choose from.
| Model | Examples | Who runs the infrastructure | Can you read the code? | How hard is it to leave? |
|---|---|---|---|---|
| Self-hosted open source | WordPress, Payload | You or your agency | Yes | Low. Choose a new host or agency, keep the platform |
| Hosted headless with open components | Sanity | Vendor runs the content store, you run the front end | Partly. The Studio editor is open source, the hosted backend isn’t | Medium. Content exports cleanly, but the hosted backend is the vendor’s |
| Proprietary DXP or SaaS CMS | Sitecore, Adobe Experience Manager | Vendor, or vendor-certified partners | No | High. Licences, proprietary content models and specialist skills |
Payload was bought by Figma in 2025 and has stayed MIT licensed, so the code you run remains yours under that licence regardless of who owns the company.
With Sanity, the vendor runs the content backend, holds its own SOC 2 Type II certification and handles that layer’s security for you, while the front end and the editing interface stay under your control.
All three can be run securely, and in each case the security of the site depends on how well the platform is maintained.
Lock-in is a security question too
Vendor lock-in affects security as well as cost, in three main ways, each of which comes down to how easily you could move if you needed to.
If you can’t move off a platform, you can’t respond when its security falls behind your requirements. If your platform’s capabilities are concentrated in one supplier, you take on that supplier’s risks, from their staffing to their acquisition plans. And if there’s only one company that can support your platform, an incident at that company can quickly become an incident for you.
A reasonable test is to ask what would happen if your current supplier disappeared tomorrow. With a mainstream open source platform you’d probably find another agency within weeks, whereas with a niche proprietary one, you may be facing a full rebuild.
Questions to ask before you choose
Whatever platform you’re looking at, these questions will help you assess its security:
- Who reviews the code, and can you see the results?
- How are vulnerabilities reported and disclosed, and how quickly do fixes typically ship?
- Where is your content and user data stored, and can you choose the region?
- Can you connect your own identity provider for SSO and enforce MFA?
- How granular are user roles and permissions, and can they be customised?
- Can you put your own controls in front of it, such as a WAF or IP restrictions on the admin?
- What does exporting your content look like, and in what format?
- If your current agency or vendor relationship ended, who else could support it?
- What would it cost, in time and money, to move off it in three years?
Our approach
We build most of our client platforms on WordPress, because it gives clients control over hosting, access and suppliers, with no lock-in to us as a supplier.
We also build on Payload and Sanity for headless projects, depending on how much of the stack the client wants to own.
Whichever platform you choose, how it’s hosted, patched and governed matters just as much, which we cover in who owns website security.
If you’re weighing up a replatform or reviewing your current setup, our CMS migration and code audit teams can help you work through it.
