Why regulated approval workflows change the headless CMS build
When content must pass legal, compliance or medical review before it goes live, the approval logic, the audit trail and the publishing controls decide which headless CMS fits, more than the front end does. The named approver for each piece of content is the accountable party if something goes out unapproved, so the platform has to prove who reviewed what, in what order, and that the published version matches the approved one. The workflow feature set differs by edition in Strapi: according to Strapi's self-hosted pricing page, audit logs and review workflows are Enterprise features, while content history and releases start at the Growth plan. Payload and Directus do not ship the same approval model out of the box, so the review stages, roles and publish gates have to be designed around them. The sections below cover the details.
Before choosing a platform, confirm three things in writing: which approval stages your policy requires, who may approve at each stage, and whether the approver can also be the author. Ask each vendor or implementation partner to demonstrate a draft that moves through two review stages, a rejection that returns to the author, and a scheduled publish that cannot run until the final approval is recorded. Confirm also whether the audit log records the approver's identity, the time and the content version, and whether it can be exported for an assessor. These checks turn a feature list into evidence you can defend.
Scheduled publishing needs the same care as review. A scheduled release is only compliant if the version that goes live is the version that was approved, so ask how each platform handles edits made after approval and whether a scheduled item can be changed without triggering re-review. If your policy treats medical or legal copy as requiring fresh sign-off after any change, plan for that rule in the content model and the roles, not as a manual step. Your organization's policy, not the platform default, sets these rules, and your compliance lead should own them.
Which approval requirements shape the build
This table lists the approval requirements a regulated publisher typically must meet and what each one means for the content model, roles and admin access. Read each row as a requirement, the source that usually drives it, and the build decision it forces. Confirm the exact obligations with your legal, compliance and accessibility owners before choosing a platform.
| Requirement | Typical source | What it means for the build |
|---|---|---|
| Named review stages | Internal content policy and sign-off rules from legal, compliance or medical reviewers | Model a status field per entry with defined stages such as draft, legal review and approved, and tie each stage to a named reviewer group. |
| Role separation | Internal segregation policy and sector-specific sign-off expectations | Authors cannot approve their own entries. Set roles so publish rights sit with a separate reviewer role, and test that restriction in staging. |
| Record of who approved what and when | Internal audit requirements and the evidence an assessor will ask to see | Confirm which edition provides audit logs and review workflows for your chosen platform, and export approval history to a system you control. |
| Scheduled publishing | Operational policy for embargoes, product disclosures and campaign timing | Store publish and unpublish dates on the entry, and confirm whether approval is re-checked when a scheduled release runs. |
| Admin access control with SSO | Identity policy from your security team, including joiner and leaver rules | Route administrator login through your identity provider and define a default role. Confirm whether SSO is included in the paid tier you need. |
| Accessibility of public-sector front ends | ADA Title II rule requiring WCAG 2.1 Level AA for state and local government web content | Compliance dates are April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts. The CMS feeds the front end, so review the rendered output as well as the content model. |
| Versioned content history | Internal change control and records retention rules | Keep prior versions of approved entries available for comparison and rollback, and confirm how long history is retained in your chosen configuration. |
| Field-level access on sensitive content | Internal data classification policy | Restrict which roles can edit regulated fields such as disclosures or dosage language, separate from general copy. |
Which headless CMS fits an approval-heavy content model
Each of the three headless CMS options handles review stages, role separation and audit history differently, and the gaps sit in edition terms as much as in features. The cards below cover what each product provides out of the box, what must be built, and what to confirm before you commit to a plan.
Strapi: approval features sit in paid plans
Strapi's Community Edition is MIT licensed, but audit logs and review workflows are Enterprise features, so an approval-heavy model needs that plan from the start. Content history and releases begin at the Growth plan, and SSO is a Growth add-on and included in Enterprise. Code under the ee directories carries the separate Enterprise license, so check which parts of the codebase your contract covers before you build on them. Confirm current plan terms with Strapi, since pricing pages change.
Payload: approval stages are code
Payload's built-in versions and drafts, field-level access control, document and field hooks, and built-in authentication give you the building blocks for approval. Admin and customer users can be managed in the CMS itself, which keeps reviewer identities in one place. However, approval stages, sign-off states and the rules for who may move content between them must be written in code and tested as application logic. Your team owns that code for the life of the system, so budget for it in the build plan.
Directus: permissions cover every access path
Directus applies role-based permissions to its REST and GraphQL APIs, Studio and native MCP server alike, so a reviewer's role limits what they can read or change through any channel. That consistency helps when you need proof that only named roles can publish. The embedded AI Assistant also works under those permissions. Confirm whether the approval workflow features you need, such as multi-stage sign-off and history of each decision, are available in the edition you plan to run, because they are not a given in every tier.
License terms that affect your operations
Strapi's Community code is MIT, Payload's core is MIT, and Directus is under the Monospace Sustainable Core License, which allows internal use and professional services to deploy or host it for a licensee but bars a competing use against Monospace's paid offerings. Legal and procurement teams should read the actual license text for each product, not a summary. For an approval platform, the license determines whether your implementation partner can host and maintain the system for you without a separate agreement.
Audit trail coverage per product
An approval record is only useful if it shows who approved which version, when, and from which role. Ask each vendor whether its audit log captures the content version, the reviewer identity, the stage and any rejection reason, and whether that log is append-only and exportable. Strapi keeps this under its Enterprise plan, Payload depends on what your code records, and Directus depends on the edition. Test the log with a real approval cycle before sign-off so you know what an auditor will actually see.
Upgrade paths under approval workflows
A workflow built on one major version can break when the platform changes. Strapi v4 reached end of life on April 30, 2026, so teams still on v4 must plan migration, and Strapi's docs advise backing up the database first because downgrading is not supported. Pending approvals, version history and role mappings must survive any upgrade intact. Ask each candidate how it handles schema and history migration and how long it supports each major line before you lock in an approval design.
How review stages and role separation map to content states
Start by writing the sign-off chain as a state table before you touch the schema. A typical chain runs draft, legal review, medical review, approved and scheduled, and each state needs three answers: who may enter it, who may move content out of it, and which API consumers can read it. The rule that matters most is that public endpoints return only the published version. The public token or public role should be unable to read draft content, so an unapproved draft cannot reach a public endpoint even if a front end requests it by ID. Confirm this with a test: request each draft entry through the public API as an anonymous user and record the response.
Reviewers need to see exactly what will go live, so preview has to be a permissioned action, not a shared link that stays valid indefinitely. Give legal and medical reviewers a role that can open draft content in preview but cannot edit or publish it. Keep the distinction explicit in your design: a draft is the working version that authors and reviewers change, while the published version is the one the public API serves. Scheduled publishing should promote a specific approved version at a set time, so the content that goes live is the content that was signed off. Ask each vendor how draft and publish states, preview access and scheduled jobs are configured, and how those actions are logged.
Role separation is what makes the approval record credible. The person who writes a claim should not also approve it, and reviewers should not be able to change approved text without returning it to draft. Strapi lists review workflows and audit logs as Enterprise features in its self-hosted pricing, with content history and releases starting at the Growth plan, so match the edition to your evidence needs before you design around it. Payload offers versions, drafts and field-level access control that can enforce these rules in code. Directus states that its MCP server and AI Assistant operate under the same role-based permissions as human users, which matters if automated tools can touch content. Confirm that each product's stages and approval history meet your evidence requirements before you commit.
Deployment patterns for regulated content
In a self-hosted cloud deployment, the client's own cloud account holds the whole stack: the CMS application, the database, the media bucket, the admin panel and the public API. Strapi 5 runs on PostgreSQL, MySQL, MariaDB or SQLite, and it does not support MongoDB. Payload supports MongoDB, PostgreSQL and SQLite. Directus connects to an existing SQL database through its DB_CLIENT setting and supports PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB. Most teams place the editorial admin behind a private network path or a restricted allow list, and expose only the read-only public API to the delivery layer.
- Database placement: Use a managed relational service in the same region as the application, with backups and point-in-time recovery enabled and confirmed in writing.
- Media storage: Keep uploads in a private object bucket with versioning and object lock where the legal hold process requires it, and serve public assets through the CDN.
- SSO for editors: Strapi SSO covers administrator login only and is a paid add-on on Growth or included in Enterprise. Confirm the same identity provider policy applies to Payload and Directus admin access.
- Audit log export: Strapi audit logs are an Enterprise feature, so budget for that edition or design an export from the database and application logs into your SIEM.
- CDN separation: Point the CDN at the public API or a static build, never at the admin panel, and invalidate cache on publish through an event from the CMS.
Before you commit, confirm which edition your approval workflow needs, where backups and logs are retained, and whether your cloud provider's regional controls match your legal and data residency obligations.
In a private data center, the same CMS components run on hardware and virtual machines the organization operates, usually behind its own firewalls and load balancers. This model suits teams whose records policy requires physical control of the database and the media archive. The database usually sits on a clustered relational server with storage replication to a second site. The admin panel is reachable only from the corporate network or through a VPN with multi-factor authentication. The public API and the CDN origin sit in a separate network zone, so a compromised delivery node cannot reach the editorial database.
- Database and storage: Plan replicated storage and tested restores, because downgrading Strapi after a migration is not supported and backups must be taken before any upgrade.
- Identity: Connect editor sign-in to the on-premises directory through the identity provider your organization already operates, and document the fallback if that directory is unavailable.
- Audit logs: Forward application and database audit records to a central log store that the compliance team can query, and keep them on write-once storage for the retention period.
- Network zoning: Publish to a delivery tier in a demilitarized zone that reads only from a copy of published content, never from the editorial database.
- Patching: Track Node.js support status for your CMS version, since Strapi 5 runs only on Active or Maintenance LTS Node.js versions.
Confirm who operates the hardware, how change tickets link to CMS releases, and whether your audit process accepts the log format your SIEM produces.
In an air-gapped or restricted network, the CMS has no route to public package registries, vendor cloud services or external identity providers. Everything it needs, including container images, npm dependencies, plugin packages and security updates, must be mirrored into the enclosed environment through a controlled transfer process. Strapi's Community Edition, Payload and Directus can all be self-hosted, but the build and update pipeline must be reproducible offline. Editors typically sign in through an identity provider inside the enclave, and the public site is generated and copied out through a one-way transfer rather than served directly from the editorial system.
- Dependency mirror: Maintain an internal package and image registry, and record every version you transfer so you can reproduce the build later.
- Database and media: Keep the database and media storage fully inside the enclave, with encryption at rest and backups kept on separate media.
- Identity: Confirm that the enclave identity provider supports the SSO protocol your edition uses, because external identity services are unreachable.
- Audit evidence: Export audit logs through an approved one-way channel, and check that the approval history remains intact after transfer.
- Licensing: Review each product's license terms for offline use and for any restrictions on contractors who operate the system.
Confirm the transfer process with your security authority, the approval procedure for each mirrored package, and which paid edition features, such as audit logs and review workflows, you need inside the enclave.
Evidence auditors and reviewers ask for
This table maps each piece of evidence an assessor or internal reviewer typically asks for to the component that produces it and who prepares it. Use it to check whether your chosen edition and configuration can generate the records before you commit to a platform. DeployOpen prepares evidence, but independent auditors and certification bodies issue any assessment.
| Evidence | Component that produces it | What to confirm before committing |
|---|---|---|
| Approval record by content version | Review workflow and audit logs on Strapi Enterprise; version history and drafts in Payload; custom logging configured by DeployOpen for Directus | Whether approvals are stored against a specific version, and whether the record survives later edits and republishing |
| Role assignment list | Admin roles and permissions exported from the CMS database or admin panel, with SSO group mapping where enabled | Who can approve, who can publish, and whether a single person can hold both roles |
| Access review for admin accounts | Identity provider reports for SSO users, combined with CMS user lists; Strapi SSO applies to admin panel login only | Whether removed approvers are disabled at the identity provider and in the CMS, and how often reviews run |
| Change history of content models and permissions | Schema and configuration held in version control for code-defined models (Payload, Strapi); Directus schema changes captured through its own tooling or custom logging | Whether schema and permission changes are reviewed and traceable to a named person and ticket |
| Publish log | Audit logs on Strapi Enterprise; scheduled publish events recorded by the CMS or the hosting platform's deployment logs | Whether scheduled publishes and API-triggered publishes are logged with user or service identity |
| Backup and restore test results | Database and media backups run by the hosting team, with restore tests documented by DeployOpen or your operations team | Restore time achieved in a test, date of the last test, and who signs off the result |
| Version and upgrade records | Release notes, change tickets and test results for each CMS upgrade, such as the Strapi v4 to v5 migration path | That the running version is supported by its vendor and that patches are applied on a documented schedule |
How a regulated approval rollout proceeds
The sequence turns a legal, compliance or medical sign-off policy into a headless CMS workflow that editors use, reviewers can evidence, and operators can roll back. Each phase closes with a written output so the approval design is settled before the build starts.
Map approval policy with legal and compliance owners
The client's legal, compliance or medical reviewers name the content types that need sign-off, the reviewers for each, the order of review and the situations that send content back for changes. DeployOpen records these as a written approval matrix. The step is done when the named owners have signed off the matrix, and any content that can bypass review has been identified and either closed or accepted in writing.
Design content model and reviewer roles
Using the matrix, the team maps each content type to fields, locales and workflow states, then defines roles that separate authors, reviewers, approvers and publishers so no one approves their own work. The output is a content model diagram and a role-permission table. The step closes when the client's owners confirm that every state in the matrix has a role allowed to move content into it and no single role can publish alone.
Confirm edition and license fit
Audit logs, review workflows and some SSO options sit in paid editions of certain headless CMS products, so the team checks the vendor's current plan terms against the matrix and the license terms against the client's intended use. The output is a short decision record naming the product, the edition, and the features that are included or missing. Confirm current edition terms with the vendor before purchase, because plan contents change.
Configure SSO and harden admin access
The team connects administrator login to the client's identity provider, sets default roles for new accounts, decides whether local login stays available as a break-glass path, and restricts the admin panel to approved networks. Separately, end-user accounts for any logged-in audience are configured through the platform's own user model. The step is complete when test accounts for each role can log in and reach only their permitted states.
Build and test the approval workflow with reviewers
Engineers build the review states, notifications, comment threads and publish gates from the matrix, then reviewers run scripted cases including rejected drafts, returned edits, reassignments and urgent withdrawals. Each defect found is logged and retested. The step closes with a signed test record showing every matrix rule was exercised by the people who own it.
Test scheduled publishing and rollback
The team schedules approved entries to publish at set times, confirms that only entries in the approved state are eligible, and rehearses rollback to a prior published version on a staging copy. They also check how cached front ends refresh after publish or unpublish. The output is a runbook with the rollback steps and an observed result for each. The step is done when the rehearsal restores the prior version and the front end reflects it.
Assemble the evidence pack and hand over
DeployOpen compiles the approval matrix, role table, configuration exports, test records, audit log samples and runbooks into one evidence pack, mapped to the client's own control list. The pack is handed to the client's compliance owner, who decides how it is used. DeployOpen does not issue audit reports or attestations, so the step closes when the client confirms receipt and an operations owner accepts the runbooks.
What buyers ask before hiring help with approval workflows
Can a free edition of a headless CMS meet a regulated approval requirement?
Usually not on its own, because review stages and audit history are gated features in the paid tier of at least one major option. Strapi's Community Edition is free under the MIT Expat license, but on Strapi's self-hosted pricing page, audit logs and review workflows are listed as Enterprise features. Payload is MIT licensed and its versions and drafts are built in, but a sign-off matrix, role separation and an audit trail still need to be designed and built around it. Directus is licensed under the Monospace Sustainable Core License 1.0, and its role-based permissions are the place to start. Before you decide, confirm in writing which approval, history and logging features each edition actually provides for your version.
How much does a paid Strapi edition add to the approval workflow cost?
The listed price on Strapi's self-hosted pricing page is 45 US dollars per month for Growth, which includes 3 users, with 15 dollars per extra user. Growth lists SSO as an add-on, while Enterprise includes SSO, audit logs and review workflows at a custom price. Enterprise pricing is quoted by Strapi, so the recurring cost depends on your seat count and the terms you negotiate. Add the implementation effort, which is one-time, and any ongoing support you choose to buy. Ask for the subscription and seat cost as a separate line from the build cost in any written quote.
How long does a regulated approval workflow take to build?
The duration depends on the number of review stages, the reviewer roles, the content types that need sign-off, and how many systems must integrate. A build with one review stage and a single content type is much smaller than a build with legal, medical and brand review across several locales. Other drivers include whether admin SSO must connect to your identity provider, how scheduled publishing is tested, and how much evidence your compliance team needs. DeployOpen works to a fixed scope agreed in writing before work starts, so the timeline should appear in that scope document. Ask for the milestones and the assumptions behind each one.
What must our team provide before an implementation partner starts?
The partner needs decisions from your business owners more than technical access at the start. Prepare a named list of reviewers for each stage, with a backup for each, and a sign-off matrix that shows which content types each role may approve. Gather the written policies that define what requires legal or medical review, how long reviews may take, and what happens when a reviewer rejects content. Also provide the publishing calendar, the list of locales and brands, and the identity provider details if admin SSO is in scope. Missing reviewer decisions are one of the most common reasons a fixed-scope timeline slips, so confirm ownership before signing.
Can an in-house team run a self-hosted approval workflow without outside help?
An in-house team can run it if it has people who can operate the CMS, manage the database, apply updates and maintain the workflow configuration. The recurring work includes patching, backups, role changes when staff move, reviewing audit logs and testing scheduled publishing after each release. Strapi's Enterprise audit logs and review workflows need an administrator who understands the permission model, and Payload's approval logic is code you will maintain. Decide whether your team will own those tasks for the life of the system or buy ongoing support and upgrades. DeployOpen offers ongoing support, upgrades and retainers, which you can compare against the cost of keeping those skills in house.
How does a Strapi 4 to 5 upgrade change an existing approval setup?
A Strapi 4 to 5 upgrade changes the API layer, so any workflow that reads content through the API must be retested. Strapi 5 replaces the Entity Service API with the Document Service API and changes the response format, and a Strapi-Response-Format: v4 header is available during migration. Strapi v4 reached end of life on April 30, 2026, so existing installations should plan the move. The migration docs say to back up the database first because downgrading is not supported. Review any review-stage and permission configuration after the migration, and confirm with Strapi which features the upgraded edition includes.
Which parts of the approval cost recur after launch?
Recurring costs fall into three groups: licenses or subscriptions, hosting, and support for changes. A self-hosted Community Edition has no license fee, but you still pay for servers or cloud accounts, backups, monitoring and the people who maintain them. Paid editions add a per-seat or per-plan subscription, and Strapi Cloud, if you choose it, adds monthly hosting plans such as the 35 US dollar per month Starter listing for each project. One-time costs include the build, the content model and the testing of each review path. Ask any quote to separate these categories so you can see what continues after go-live.
What should a written quote for this workflow include?
A useful quote lists the scope in plain terms: the content types covered, the review stages and roles, the audit history required, the publishing rules and the integrations. It should name the CMS edition and the license terms that apply, and state which features depend on that edition. It should show one-time build work separately from ongoing support, upgrades and any retainer. It should also state assumptions, such as the reviewer decisions and policies your team provides, and what happens if those arrive late. DeployOpen does not publish a price list, so the written scope is the basis for every figure you will receive.
Questions to put to an implementation partner
Start by asking how the partner maps each approval stage to a role and a content state, and where that mapping lives. For a regulated sign-off, the useful answer names the states a draft moves through (for example draft, in review, approved, scheduled, published), which roles can move content between them, and whether those transitions are enforced by the CMS or by convention. Ask for the role matrix in writing and for the review workflow configuration as it would be exported from the CMS. Also ask which of these controls sit in the Community Edition and which need a paid self-hosted plan. For Strapi, the researched plan details place audit logs and review workflows in the Enterprise tier, so confirm that before the design is locked, and ask how the partner would handle the same stages on Payload or Directus, where the approval model is built differently.
Next, ask how the partner proves that a reviewer cannot approve their own work. A credible answer describes a test: a named author account attempts to approve, publish or schedule their own entry, and the attempt is recorded as a failed action. Ask for the test script, the accounts used, and the result as evidence, and ask how they verify that role changes do not quietly restore the permission. Also ask how administrator accounts are handled, since an administrator who can edit roles can often approve indirectly. Ask whether admin login is routed through SSO and whether local login is locked out, and how that lockout is tested. Finally, ask how audit records are exported and retained, and how scheduled publishing is tested. The partner should state where audit events are stored, how long they are kept, who can read them, and whether they can be exported in a format your records team can search. Ask how a scheduled entry is tested across a time zone change, a failed publish, and an edit made after approval but before the scheduled time, and which record shows what version went live. Ask how they handle a paid-edition gap if a required control is missing, and which evidence they deliver at handover: configuration exports, test results, and runbooks, with a clear statement that independent auditors, not the partner, decide whether those records meet your obligations.
Failure modes that cause sign-off gaps
Most sign-off gaps do not come from a missing workflow feature. They come from a control that works in the admin panel but is bypassed through the API, a scheduled job, an shared login or a restore that was never tested. Each card below names one of these failure modes and the control that closes it.
Approvals enforced only in the UI
A review stage that blocks publishing in the admin panel does nothing if the REST or GraphQL endpoint will write and publish the same entry. Editors, integrations and scripts can all reach the API with a token. Check that the publish action is permission-checked on the API route itself, that each token is scoped to a role, and that a test call with a draft-only role cannot change a published entry. Enforce the state change in the API, not the screen.
Shared admin accounts without SSO
When several reviewers share one administrator login, the audit trail records the account, not the person who approved the content. Strapi's SSO applies only to administrator login to the admin panel through an identity provider, and in its self-hosted plans SSO is an add-on for Growth and included in Enterprise. Confirm that every editor and reviewer has a named identity, that local login can be locked out, and that leavers lose access when their directory account is disabled.
Scheduled publishes that bypass review
Scheduled publishing is often configured by a different role than the one that approves content, and some setups let the scheduler run the publish action without rechecking the approval state. A disclosure approved on Monday can go live on Friday after a later edit that nobody reviewed. Ask the vendor or partner to show that the scheduler evaluates the same approval status as a manual publish, and test a case where content is edited after approval and scheduled.
Missing version history after upgrades
Major upgrades change the data model and the API response format, so content history can be lost or misaligned if the migration is run without a plan. Strapi 5 replaced the Entity Service API with the Document Service API and changed the response format, with a compatibility header during migration. Confirm that every approved version, its reviewer and its timestamp survive the move, and compare sample records before and after each upgrade.
Unclear ownership of the audit log
An audit log that no one owns is rarely reviewed, exported or retained to the period the compliance team needs. Decide who reads the log, who answers an auditor's question about a specific approval, where logs are stored outside the CMS database, and how long they are kept. In Strapi's self-hosted plans, audit logs are an Enterprise feature, so confirm the edition before design starts. Write the ownership into the operating procedure.
Backups that were never restored
A nightly database backup proves little until someone restores it into a clean environment and checks that approval states, roles and scheduled jobs come back intact. Strapi's migration guidance says to back up the database first because downgrading is not supported, which makes a tested restore the only rollback path for a failed upgrade. Schedule a restore drill before each major change, record its result, and keep media storage in the same recovery plan as the database.
How DeployOpen scopes and supports regulated content approval
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For regulated content approval, we start from your sign-off chain, then build and document the review stages, role separation and approval history that your compliance, legal or medical reviewers depend on.
How we scope
- We map every content type that needs legal, compliance or medical sign-off before it can publish.
- We define review stages, approver roles and the editors who may only draft, in writing.
- We confirm which approval and audit features your chosen edition includes before any build begins.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We configure the workflow, role permissions and scheduled publishing in your self-hosted CMS instance.
- We set up admin SSO and test that editors cannot approve their own content.
- We wire preview, publishing and the front-end delivery path so only approved versions go live.
- We run security testing on the CMS, its APIs and the hosting environment before handover.
How we hand over
- You receive documentation of the workflow, roles, permissions and the approval audit trail.
- We provide evidence that supports your compliance team's review, which assessors and auditors then judge.
- Editors and approvers are trained on their stage of the workflow using your own content models.
- Backups, upgrade steps and a runbook for restoring the approval history are documented for your operators.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer.
- Retainers can cover version upgrades of the CMS, such as moving between major releases, when your team schedules them.
- We re-test approval workflows after changes to roles, plugins or the front end.
- Questions about audit evidence scope are confirmed with your auditors, since DeployOpen does not issue attestations.
