What changed
WordPress released 7.2 Beta 1 on October 20, 2026. Among the developer additions is a new first-party Secrets API for plugins and integrations to store credentials such as SMTP, payment and AI provider keys without putting their values in plaintext options. The API provides wp_set_secret(), wp_get_secret(), wp_delete_secret() and a deliberate import helper, with WP_Secret objects that require explicit reveal() access. Its design uses encryption at rest, configurable keyring/storage providers and current/previous value slots to support credential rotation. The feature is in beta and the final 7.2 release is scheduled for December 8.
Why it matters
WordPress plugins commonly persist tokens and API keys in wp_options, which is routinely copied into backups, staging sites and support exports. A standard encrypted credential interface offers a consistent hardening path, with a central API that plugin authors and hosts can audit. However, encrypted-at-rest storage reduces database-leak exposure; it is not a sandbox between plugins and cannot prevent code execution inside WordPress from retrieving usable secrets.
What developers can use
The proposed API includes wp_set_secret(name,value), wp_get_secret(name,version), wp_delete_secret(name) and wp_import_option_as_secret(option,name). Retrieval distinguishes a missing secret (null) from a key or decryption failure (WP_Error) and returns an object rather than plaintext by default. A plugin should explicitly handle all three states and call reveal() only when passing the credential to its intended service.
Encryption and rotation boundaries
The core design encrypts secrets using a key hierarchy with a dedicated key configuration preferred and a salts-derived fallback. Current and previous secret versions support rotation without an unlimited history. If the wrapping key is lost or salts change without a migration plan, stored credentials can become unreadable; recovery may require re-entering and rotating credentials. Encryption does not stop malicious PHP code executing inside WordPress from calling the same retrieval API.
Hosting providers raised a real integration issue
During design review, engineers from managed WordPress hosts questioned whether a write-capable local encryption model fits read-only external secret stores backed by services such as AWS Secrets Manager. The proposal's author subsequently discussed pluggable provider implementations. Builders using a host-managed secrets system should verify the beta's actual provider behaviour rather than assuming every existing keyring or read-only store is interchangeable.
Migration is not automatic
WordPress cannot safely infer which arbitrary options contain credentials. Plugin authors must deliberately import known values and rotate them, because encrypting a previously exposed key does not remove plaintext copies from old database dumps or backups. The beta is for testing on staging or local environments, not production deployment; API signatures and behaviour should be checked again before the December stable release.