Ghost’s staff device verification adds a one-time email code when a staff member signs in from a new or unrecognized device. Ghost also offers an optional setting to require email-based two-factor authentication (2FA) on every login. They are related security protections, but they are separate features.

After these protections were introduced, some self-hosted sites found that ghost backup could no longer authenticate. The original Ghost-CLI issue was fixed by adding token-based authentication for newer Ghost versions. However, a 403 or 500 response can have other causes too, so treat the error as a symptom—not proof that device verification is responsible.

What the error can look like

A failed backup may show an error such as:

✖ Backing up site
An error occurred.
Message: 'Response code 403 (Forbidden)'

Some users reported a 500 response or an authentication error in Ghost’s logs. Record the complete error and version details before changing configuration.

Recommended fix: update Ghost-CLI and use token authentication

First, check the installed Ghost and Ghost-CLI versions from your Ghost installation directory:

$ ghost version

The fix was released in Ghost-CLI 1.28.0. The project reported that token-based backups apply to Ghost 5.129.0 and later. Update Ghost-CLI using the installation method for your server. For a standard system-wide npm installation:

$ sudo npm install -g ghost-cli@latest

Then verify the CLI version:

$ ghost version

From the Ghost installation directory, retry the backup:

$ ghost backup --verbose

On supported versions, Ghost-CLI may ask for a staff access token. For non-interactive backups, Ghost-CLI 1.28.0 and later supports the GHOST_CLI_STAFF_AUTH_TOKEN environment variable. Avoid pasting a token directly into a command that will be saved in shell history. For an interactive shell, you can enter it without echoing it:

$ read -rsp 'Staff access token: ' GHOST_CLI_STAFF_AUTH_TOKEN
$ export GHOST_CLI_STAFF_AUTH_TOKEN
$ printf '\n'
$ ghost backup
$ unset GHOST_CLI_STAFF_AUTH_TOKEN

Use a valid staff access token accepted by your Ghost version and backup workflow. Treat it like a password: do not commit it to scripts or repositories, expose it in logs, or share it in support requests. For scheduled backups, use a secret manager or a protected environment file with permissions limited to the account that runs the job.

The Ghost-CLI fix was merged on July 21, 2025; Ghost-CLI 1.28.0 was announced as containing the fix on July 25, 2025. Later reports show that backup failures can still occur—for example, because of permission problems, a proxy, or version-specific issues. Updating is the first step, not a guarantee that every 403 or 500 will be resolved.

If the backup still fails

1. Confirm that the command is running from the correct Ghost installation directory.
2. Check the versions printed by ghost version. Confirm that the Ghost version supports the token-based backup flow.
3. Read the full Ghost-CLI output and relevant Ghost logs. A 403 may indicate a token or permission problem; a proxy or security layer may also block the request. A 500 can indicate a server-side error.
4. Check whether a reverse proxy, firewall, or access-control rule blocks requests from the Ghost server to its own site URL.
5. Compare the exact error and version combination with the Ghost-CLI issue and the merged fix.

Before posting logs publicly, redact tokens, passwords, email addresses, private URLs, and other secrets.

Should you disable device verification?

Usually, no. Updating Ghost-CLI and using its supported authentication flow is preferable to weakening staff account security.

Only consider temporarily disabling device verification on a self-hosted site if you have confirmed that it is the cause, cannot update the CLI, and understand the security trade-off. Keep a separate, verified administrator login available, make a copy of the configuration first, and restore the setting as soon as the CLI is fixed. Do not disable the optional email 2FA setting for all staff as a general troubleshooting step.

Ghost supports configuration through its CLI. If you choose this temporary workaround, use the Ghost configuration command rather than adding a duplicate security object by hand:

$ ghost config set security.staffDeviceVerification false
$ ghost restart

After updating Ghost-CLI and confirming backups work, re-enable device verification:

$ ghost config set security.staffDeviceVerification true
$ ghost restart

If this setting is managed outside the Ghost config file in your deployment, follow that deployment’s configuration process instead. Check the resulting configuration and sign-in behavior after restarting.

Keep backups reliable

Ghost’s ghost backup command creates a backup archive containing publication content and media. A working, recent backup is essential before upgrades and for disaster recovery. After resolving the error, confirm that the archive was created and store a copy somewhere separate from the server.

Staff device verification exposed an authentication limitation in older Ghost-CLI backup flows. Update Ghost-CLI, use token-based authentication on supported Ghost versions, and investigate the complete error if the backup still fails. Keep device verification enabled whenever possible, and verify that each backup archive is usable and stored safely.

We hope this was helpful.
Keep learning. Keep exploring. Stay secure.