Signing Key Rotation for License Keys: Planned Changes and Compromise Recovery

Signing-key rotation changes who can issue offline proofs your application trusts. It is different from generating a new customer's license key, changing a payment credential or resetting a password. A safe rollout accounts for both the new signer and applications that still trust an older public key.

Separate routine replacement from a suspected compromise. Keeping an old verification key can preserve legitimate offline use during a planned transition. Keeping trust in a stolen signing key can also preserve an attacker's ability to create accepted proofs.

Inventory the different keys

• Customer license key: a credential identifying an issued entitlement. Rotating your offline signer does not automatically replace this customer's key.
• Private signing key: vendor secret used to sign offline tokens. Anyone with it can create signatures accepted by clients that trust its public counterpart.
• Public verification key: safe to distribute, but its authenticity matters. Put approved keys in trusted application configuration.
• Encryption and passphrase material: protects stored license values or recovery packages. It is not interchangeable with the offline signer.
• Admin JWT, API and payment credentials: separate authorities with separate replacement procedures.

Record which products, application versions and deployment environments trust each signer. Keep private material in a controlled secret store, restrict access and record authorised changes without logging the secret. OWASP's key-management guidance covers distinct key purposes, lifecycle inventory, protected distribution and documented compromise recovery. A rotation schedule should follow the risks and recovery needs of your own system.

A key ID helps routing; it does not establish trust

PermitCore signing-key versions have a kid. The server uses that identifier to find the relevant verification key and status. The label is not itself proof that the token or its advertised key is trustworthy.

SDK 2.1.1 verifies cached authorization against public keys configured by your application. A public key found beside a token in an editable cache file cannot create its own trust. Fetch approved public material from your verified service origin and deliver configuration through your trusted application release or update process.

All eight SDKs support an explicit trusted-key list. Their configuration names differ; use the language-specific reference. No configured trust keys means cached authorization is disabled, while online license calls remain available. Verify product and device context as well as the signature and deadline.

What Rotate does in PermitCore

In Settings → Security → Business Continuity, routine Rotate creates a new active signer immediately. The previous key becomes Deprecated and remains available for server verification of older tokens. Routine rotation does not revoke the tracked tokens.

Newly signed proofs use the new active key. An installed application that trusts only the old key will not automatically trust that new signer. Existing valid old proofs can still be checked against an approved old key, subject to their original signed constraints. Do not assume every client fetches and approves a new trust root silently.

The current rotation operation does not provide a pending-key activation stage or dual-sign each proof. Because the new key is created when Rotate runs, a rollout cannot simply assume its public key was distributed beforehand. Plan a controlled transition that covers the interval between signer creation and delivery of the updated trust configuration.

A routine rollout checklist

1. Inventory current trusted public keys and application versions. Know how a disconnected customer receives updates and when its current proofs expire.
2. Rehearse with an owned test tenant. Prepare an authenticated configuration or app-update path and a support window before changing the production signer.
3. Rotate in that controlled window. Capture the new public key and kid; protect any returned private material as a vendor secret.
4. Deliver the approved new public key through the prepared trusted path. During a planned overlap, include the legitimate old verification key where its continued acceptance is intended.
5. Test a new proof and an existing old proof on the actual supported app versions. Check wrong signer, changed payload, wrong product/device and expired proof, not just one successful request.
6. Track rollout coverage before removing old trust from customer applications. Keep a recovery plan for offline customers who missed the update.

Online entitlement validation and offline proof acceptance are different checks. During the transition, define whether the app can continue online, needs an update or must wait for support. Do not turn a cache-verification failure into an unconditional grant of paid access. Removing an old public key from your release does not update every already-installed copy.

Use Regenerate for the current-key compromise response

PermitCore's Regenerate is a separate, destructive operation with explicit confirmation. It marks the current active signer Compromised, creates a replacement and revokes all currently tracked offline tokens for the tenant. Online token verification rejects a compromised signer and tracked revocations.

This is not a global remote wipe of customer trust. A disconnected application retaining the old public key cannot learn that the server changed its status. An attacker holding the leaked private key may mint new forged proofs for applications that still trust it; waiting for one legitimate token to expire does not remove that trust.

Inventory the affected key version. Regenerate marks the current signer compromised; do not assume it marks every historical deprecated key compromised too. If the incident concerns an older exported key, coordinate an operator-reviewed response for that specific version and update application trust. Avoid treating a history row or a green online check as evidence that every offline customer has recovered.

Contain the original exposure as well: revoke inappropriate access, secure the signing and distribution environment, preserve incident evidence without copying secrets into tickets, and communicate the required app/config update. Reissue legitimate proofs through the recovered process. Do not roll back to a compromised key to make an old build work.

Short-lived proofs and online status have different limits

A signed proof has an expiry. Shorter lifetimes bound the authority of that particular proof when the verifier enforces its deadline, but they increase the need for reconnects and customer recovery. Choose a period that fits the sold offline workflow. A signature alone does not prevent application patching or host-controlled clock rollback.

The optional online token-status check can consult the token tenant's signing-key status and tracked revocation without an Admin session. Tokens issued independently with an exported signing key can be valid, but an untracked token has no individual server revocation record. The app must handle the check's result and network-failure policy deliberately.

Store payment grace and signed token expiry remain separate constraints. A renewal or refund does not rewrite a proof already held on a disconnected machine. The offline reference explains setup and the boundaries of cached authorization.

Export supports continuity; it transfers responsibility too

Signing-key export, rotation, regeneration and history are available on every plan, including Free, to the owning CompanyAdmin through the authorised Admin-session workflow. An API key cannot export the private signer. Read and accept the Business Continuity warning before exporting. Hosted offline-token generation and self-hosting retain their own plan entitlements.

Exporting gives you a copy of the active signing material; it does not revoke PermitCore's copy or move your installed applications to a new service. Never ship the private PKCS8 key in a desktop, mobile, Unity or browser application. Keep the recovery package encrypted in controlled storage and test access by the people responsible for recovery.

Preserve public verification history, product identifiers and the exact token schema your clients support. A data ZIP, order reference or signing-key package is not a complete restore of every hosted dependency. The exit plan separates data recovery, license values, signing authority and the application release needed for an end-of-life strategy.

Verify the transition before customers depend on it

• New and approved old proofs behave as intended during planned overlap.
• Missing trust, wrong signer and altered token cannot enable protected work.
• Product, device and signed expiry checks survive restart and cache reload.
• A client with old-only trust gets a clear update or recovery path for a new signer.
• Online compromised-key and tracked-revocation outcomes are handled explicitly.
• A disconnected old build's remaining trust is documented rather than described as remotely revoked.
• Private signing material never enters application bundles, screenshots, logs or support messages.

Use the Business Continuity reference for the current controls, and the shutdown-planning guide for long-term customer access. Rotation is complete when your intended clients trust the right keys and the recovery process works, not merely when a new row appears in key history.