WordPress 7.2, scheduled for December 8, 2026, adds a Secrets API: an official way to store API keys, OAuth client secrets and similar credentials encrypted in the database. The dev note published by the core team on November 11, written by Eric Mann, includes a change from the betas: the API now depends on a new constant, WP_SECRETS_KEY, in wp-config.php. New installs get this key automatically. Existing sites do not.
What ships in 7.2
Today most plugins save keys for external services (payments, transactional email, CRM, AI models) as a regular option, in plain text in the wp_options table. Anyone with a copy of the database dump has the keys.
With 7.2, plugins can call wp_set_secret() and wp_get_secret(). The value is encrypted with libsodium (XChaCha20-Poly1305) and stored in the same options table, and the previous version is kept so a key can be rotated without breaking the integration. The returned object does not show up in logs, var_dump or JSON; the value only comes out when code calls reveal(). There is also wp_import_option_as_secret(), which copies an existing option into the store and flags the secret as pending rotation.
The note spells out two limits. The prefix in a secret's name (plugin/name) keeps one plugin from overwriting another's, but it is not access control: any code running on the site can read any secret. And the functions do not check user capabilities, because they have to run from cron and REST; that check remains the plugin's job.
The new key and what happens without it
Encryption depends on WP_SECRETS_KEY. In the betas, when the constant was missing, core derived a key from LOGGED_IN_KEY and LOGGED_IN_SALT. That fallback is gone. Without the constant, the API stores nothing: every write and every read of a stored secret returns a secret_key_unavailable error. An empty value, the wp-config-sample.php placeholder or a copy of one of the salts does not count either.
On existing sites, Site Health shows a notice and generates the define() line to paste into wp-config.php, below the salts. Hosts and tools that write that file should add the constant; according to the note, WP-CLI's wp config create "is being updated" to do so.
The note also warns not to treat this key like the salts. Changing the salts logs users out. Changing or losing WP_SECRETS_KEY makes every stored secret unreadable until the old value is restored. In practice, wp-config.php stops being a file you can rebuild from scratch during a migration and becomes part of the backup, together with the database. A dump restored without the original key brings the secrets back but cannot open any of them.
Who needs to act
Anyone maintaining WordPress sites outside managed hosting needs to decide where this key will live and who holds a copy. If wp-config.php is generated by a pipeline, a server template or a container image, the constant has to go into that process instead of being pasted by hand in production. If the site was handed over by an agency and nobody is quite sure who touches the server today, this is one of the first pieces of information to get lost; I wrote about that gap in Who looks after the system once the project ends?.
Hosts that want to keep the key in a KMS or HSM, or send secrets to an external manager, do it through a wp-content/secrets.php drop-in. There is a breaking change here for anyone who tested the betas: the extension points became abstract classes, so a drop-in that still uses implements instead of extends causes a fatal error on every request, according to the note. That fix has to reach production together with 7.2.
Beta testers who already stored secrets without the constant need to migrate them before touching the salts, because the old key is derived from them. The note describes three steps: define the new key and WP_SECRETS_KEY_PREVIOUS, run the root key rotation via wp eval, and remove the temporary line.
For everyone else, there is no hard deadline on December 8. A site without the constant keeps working; only the Secrets API is unavailable. The real deadline arrives when a plugin on the site starts relying on it, and the note does not say how each plugin will behave in that case. My reading: add the key and keep a copy off the server before updating, because doing it after a plugin has already stored secrets carries more risk than doing it now.
What is still unclear
The note does not say when the wp config create update ships in WP-CLI, or whether large managed hosts will add the constant themselves or leave it to customers. There is also no sign of which popular plugins will adopt the API at launch, or how they will handle a site without the key: fall back to the plain-text option or refuse the configuration. 7.2 RC1 is planned for November 17, and details may still change before then.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
