CMS Exit Strategy: the FedRAMP Landscape

Every federal Drupal shop eventually holds the meeting. Someone has seen a demo of a modern headless CMS. The editing experience is gorgeous, the API is clean, the deploy takes ninety seconds, and the room starts asking why we’re still patching a decade of contrib modules. It’s a fair question. Then someone from the security office asks whether the shiny thing has an ATO, and the meeting gets shorter.

I wanted to know exactly how much shorter. So I did the homework: the real capabilities of the modern CMS field, and the real FedRAMP statuses behind them, checked against the FedRAMP Marketplace on July 7, 2026, with links. Consider this the receipts-bearing sequel to What the Job Postings Know.

The exit question has changed

In that post I argued that generating and rendering pages have commoditized, and durable value moved to two things: governance (accessible, on-brand, non-redundant, compliant content) and multi-channel distribution (publish everywhere, including to AI agents). The same thesis runs through the book I’ve been writing on Drupal site architecture in the age of AI, where the guardrails chapter does the heavy lifting.

That reframes the exit conversation before it starts. The question is not “what can render our pages,” because everything can now. Astro can. Next.js can. A static site generator from 2014 can. The question for a government shop is narrower and harder: what enforces the editorial guardrails, publishes to every channel that matters, and can actually clear the federal compliance bar? In government, that last clause does most of the work, and it’s the one the vendor demo never mentions.

FedRAMP is a filter, not a feature

Two facts about FedRAMP that reshape any CMS comparison.

First, FedRAMP authorizes cloud service offerings, not software. There is no such thing as “FedRAMP-authorized Drupal,” and there never will be, because Drupal is code you run, not a service someone operates. Search the marketplace for “Drupal” and you get zero product hits. The compliance story always lives one layer down, in whoever operates the boundary: a platform-as-a-service (Acquia Cloud, cloud.gov), a SaaS (WordPress VIP, Adobe’s government cloud), or an IaaS you build on yourself (AWS GovCloud, Azure Government). An agency’s ATO covers the whole system boundary, hosting, configuration, integrations, and operations, and an authorized platform lets you inherit a large share of the controls. cloud.gov publishes the arithmetic: of the 323 NIST 800-53 Rev 5 Moderate controls, roughly 155 are platform-owned and another 98 shared, about 60% you don’t have to carry alone.

Second, the marketplace is small. As of the July 7, 2026 snapshot, the FedRAMP Marketplace lists 664 products across the entire federal cloud universe, of which 68 sit in the “Content Management System” category. For comparison, a CMS-tracking site will happily list you a hundred headless CMS vendors. The overlap between those two lists is where this post lives.

(A labeling note for anyone who last looked a couple of years ago: the marketplace moved from marketplace.fedramp.gov to fedramp.gov/marketplace, and under the 2026 Consolidated Ruleset the old “FedRAMP Authorized” label now displays as “FedRAMP Certified,” with impact levels expressed as Cert Classes: Class B is Low, Class C is Moderate, Class D is High. Same regime, new paint.)

Now run the shiny list through the filter.

Contentful. Sanity. Storyblok. Strapi Cloud. Sitecore XM Cloud. Pantheon. As of the snapshot, none of them appears in the FedRAMP Marketplace under their product names. Not Certified, not In Process, not even FedRAMP Ready. That’s not a gap in my search; it’s the finding. Sitecore’s own partner ecosystem says the quiet part plainly: XM Cloud runs on ISO 27001 and SOC 2 Type II, and federal agencies must decide whether that suffices, which for a public-facing federal system it generally doesn’t. Pantheon’s government page markets Section 508 capability and a customer list that is state and local (Iowa, Charlotte, NYC DOT, Washington’s WaTech, the New York State Senate), with carefully hedged compliance-adjacency language and no federal authorization claim. Respectable state/local story. Not a federal one.

One honest asterisk before the table: the marketplace was never the gate for open-source software. Strapi, and a whole class of modern self-hostable CMSes alongside it (Payload, Directus, Wagtail, Umbraco), can run on FedRAMP-authorized infrastructure exactly the way self-hosted Drupal does: folded into an agency’s own ATO, inheriting the infrastructure controls from AWS GovCloud or Azure Government, no marketplace listing required or even possible. Nothing about the filter forbids that path. What the filter tells you is its price. Self-hosting on raw IaaS is the maximum-burden version of compliant; your team owns every control above the hypervisor, and the question stops being “is it authorized” and becomes “which CMS has the governance depth, and the security operations story, to help you carry an ATO.” Drupal fares well in that comparison for reasons that have nothing to do with the marketplace. I’ve sketched the field in the addendum below; a deeper dig is its own post.

The FedRAMP filter eliminates most of the modern field before a single feature gets compared. What survives is a short list, and it looks nothing like the conference-talk landscape.

The receipts

FedRAMP Marketplace snapshot, checked 2026-07-07. Package IDs link in the sources section below.

And the feature comparison for the survivors, scored against what a governed federal content operation actually needs. “Drupal” here means decoupled Drupal: Drupal as the governed content API on FedRAMP-authorized hosting, behind a modern front end.

What you lose when you leave

Migration talks love the demo and skip the inventory. Here’s the inventory. A mature federal Drupal build is quietly doing all of this, today, inside an ATO someone already signed:

• Revisions with moderation states, so a subject-matter expert can draft, a reviewer can approve, and legal can see exactly what changed between the two.
• Structured content modeling, the entity/field system that makes content queryable data instead of blobs in a rich-text field.
• Translation of content, configuration, and interface, field by field.
• Role and permission governance granular enough to encode an org chart, which in government is the whole game.
• Config management, the deployment discipline that makes the site reproducible.

WordPress VIP replaces perhaps 70% of that with a friendlier editor and a real FedRAMP Moderate authorization; the remaining 30% (deep structure, native multilingual, granular workflow) is plugin archaeology. AEM replaces all of it, sometimes better, for a price that assumes you have an implementation partner on retainer, and with the wrinkle that its authorization is the old JAB kind whose continuous monitoring now falls to its own agency customers. Salesforce replaces it only if you squint at “content” until it looks like CRM data, and my honest read is that you inherit an admin and configuration burden every bit as heavy as the Drupal one you were escaping, now with per-login pricing. cloud.gov Pages doesn’t replace it at all, and that’s its virtue: for the large class of federal sites that are mostly documents and don’t need editorial workflow beyond “someone reviews the pull request,” deleting the CMS is the correct architecture, and GSA will sell it to you through an interagency agreement with 508 and the design system baked in.

One more contender worth naming because it’s aimed squarely at this audience: Adobe announced in March 2026 that Edge Delivery Services “supports FedRAMP requirements,” alongside an AI “Experience Modernization Agent” that promises to convert Drupal sites into Edge Delivery Services in a fraction of the usual time. Note the verb. “Supports FedRAMP requirements” is not “FedRAMP Certified,” and there is no Edge Delivery Services listing on the marketplace as of the snapshot. When the pitch is an AI agent that eats your Drupal site, the compliance wording deserves the same scrutiny as the demo.

The verdict

For a federal Drupal shop, the lowest-risk modernization is the one that doesn’t look like an exit: keep Drupal as the governed content API, keep the ATO and the hosting authorization you already have (Acquia Cloud and cloud.gov have carried FedRAMP Moderate since 2016 and 2017 respectively), and swap the front end for something modern on infrastructure that’s already in scope. If your agency runs Azure, App Service on Azure Government is FedRAMP High and sitting right there. My personal instincts run toward Cloudflare and Vercel for front-end hosting, and the government reality check is that neither instinct survives contact with the marketplace; the boring answer is Azure Government, AWS GovCloud, or cloud.gov, and boring is the point. This path is also reversible. A decoupled front end you regret is a front end you replace; a CMS migration you regret is a fiscal year you don’t get back.

A full platform swap is justified in three honest cases. Your content is simple enough that cloud.gov Pages deletes the problem outright. Your organization already lives in Salesforce or Adobe, with the licenses, the admins, and the appetite, so the platform tax is sunk cost. Or your Drupal talent has genuinely evaporated and WordPress VIP’s simpler model plus a real FedRAMP Moderate ATO beats a governance stack no one on staff can operate. What’s never justified is migrating because the demo was pretty. The demo is the commoditized part. The guardrails and the authorization are the part you’d be rebuilding, and this table is what rebuilding them costs.

Generating and rendering pages got cheap. Governance, distribution, and an ATO didn’t. Read the marketplace the way I read the job boards: it tells you where the value actually sits.

Addendum: the self-hosted open-source field

A survey pass, not the full comparison; that’s a follow-up post. The mechanics first: when you self-host, the software joins your agency’s ATO under FISMA/RMF, assessed against NIST 800-53 like everything else in the boundary. You inherit the bottom of the stack from the authorized IaaS (physical, hardware, hypervisor, some network) and you own the rest: OS hardening, patching, access control, audit logging, scanning, the SSP chapters, and continuous monitoring, forever. Where cloud.gov lets you inherit or share roughly 60% of the Moderate baseline, raw IaaS hands you the long end of that stick. Every open-source CMS pays the same toll, so the comparison is purely about governance features and who eases the burden you signed up for.

The candidates, honestly:

• Strapi (Node): the most-cited modern option. REST and GraphQL, draft-and-publish, and unlimited custom roles now sit in the free tier. The operational-governance features an assessor asks about (content history, audit logs, SSO) live in paid tiers, and the editorial stack is young.
• Payload (TypeScript, MIT): the strongest technical answer. Code-first config, versions and drafts, field-level access control written as functions, localization. Governance-as-code that a reviewer can actually read. Figma acquired Payload in June 2025; the project remains open source, and the roadmap is worth watching for exactly that reason.
• Directus: data-first over your SQL database, granular permissions, revisions. The procurement wrinkle: it’s source-available under a custom license (formerly BSL), not OSI open source, which a contracting officer will notice even when the demo doesn’t mention it.
• Wagtail (Python/Django, BSD): the credible peer. Real moderation workflows, revisions, localization, Django’s permission system underneath, headless API, and a genuine public-sector track record. The closest thing to Drupal’s governance depth outside PHP.
• Umbraco (.NET, open source): the Azure answer. Mature editorial features, and it runs naturally on App Service, which is in FedRAMP High scope on Azure Government.
• Self-hosted WordPress: fits the mold trivially, and plenty of agencies do it. You inherit WordPress’s governance gaps plus the full patch burden, which is the worst quadrant of this matrix.

The discriminator that never makes the slide deck: security operations as a compliance feature. When the application layer is your responsibility, Drupal’s dedicated security team, coordinated advisories, and long support windows are things an ISSO can write an SSP section around. The Node-ecosystem options carry large, fast-churning npm dependency trees, which makes the supply-chain story materially harder to defend in an assessment; Wagtail sits somewhere in between. That, and not the marketplace, is the honest reason “self-host something newer” usually loses to “keep Drupal and modernize the front end.” The decoupled front end is the same self-hosted pattern, held to the same standard, with the smallest possible surface.

Sources & FedRAMP snapshot (checked 2026-07-07)

FedRAMP statuses change; this is a snapshot, not a promise. Marketplace terminology follows the 2026 Consolidated Ruleset (“FedRAMP Certified,” Cert Classes B/C/D).

• FedRAMP Marketplace (664 products; CMS category 68): https://www.fedramp.gov/marketplace/products/
• Acquia Cloud, F1302201919 (Moderate, since 4/13/2016): https://www.fedramp.gov/marketplace/products/F1302201919/ · scope history per Acquia: https://www.acquia.com/blog/acquia-receives-third-fedramp-ato-us-dot
• WordPress VIP, FR1923743650A (Moderate, 3/12/2025): https://www.fedramp.gov/marketplace/products/FR1923743650A/ · vendor gov page: https://wpvip.com/wordpress-vip-for-government/
• Adobe Experience Manager Managed Services (AEMMS-GC), F1509037239 (Moderate, since 6/27/2019; agency-customer conmon since 3/7/2025): https://www.fedramp.gov/marketplace/products/F1509037239/ · Adobe FedRAMP page: https://business.adobe.com/industries/government/fedramp-certification.html · Edge Delivery Services announcement (2026-03-03): https://business.adobe.com/blog/modernizing-federal-digital-experiences-fedramp
• Salesforce Government Cloud Plus, FR2003061248 (High, since 5/27/2020): https://www.fedramp.gov/marketplace/products/FR2003061248/ · Salesforce compliance doc: https://compliance.salesforce.com/en/documents/a005A00000t4NpRQAU
• cloud.gov (CG-TTS), F1607067912 (Moderate, since 2/2/2017): https://www.fedramp.gov/marketplace/products/F1607067912/ · control-inheritance math: https://docs.cloud.gov/platform/compliance/ato-process/ · cloud.gov Pages: https://cloud.gov/pages/
• Azure / Azure Government FedRAMP High scope (incl. App Service; Static Web Apps public-only), page updated 2026-02-25: https://learn.microsoft.com/en-us/azure/azure-government/compliance/azure-services-in-fedramp-auditscope
• Sitecore XM Cloud not FedRAMP authorized (partner analysis): https://www.agencyq.com/insights/article/sitecore-xm-cloud-government
• Pantheon government page (state/local customers, no federal authorization claim): https://pantheon.io/industry-solutions/government