App Key Rotation

Overview

To improve security posture and support incident response scenarios (such as credential leakage), we have an AppKey Rotation mechanism. This enables controlled rotation, disabling, and deletion of sensitive credentials while ensuring zero or minimal impact to client traffic.

The system supports up to two AppKeys per App ID, with strict guardrails for safety, continuity, and reversibility.

Who is this for: GTM Teams, SA Team, Support Team When to use: Client requesting app-key rotation

Why AppKey Rotation?

AppKeys can be exposed due to code leaks, misconfigured systems, or insider/third-party risks. Credential rotation is a security best practice, often mandated by compliance standards.

Core Rules & Guardrails

• Minimum 1 enabled AppKey must always exist
• Maximum 2 AppKeys per App ID
• AppKey cannot be deleted unless disabled first
• Third AppKey cannot be created if two already exist

AppKey Lifecycle

1. Create AppKey

• One AppKey is auto-generated when credentials are created
• A second can be created manually (only if exactly one exists)

2. Disable AppKey

• AppKey must have no usage in the last 7 days
• At least one other enabled AppKey must exist
• Reversible — can be re-enabled if needed

3. Delete AppKey

• Must already be disabled
• At least one other enabled AppKey must exist
• Irreversible — cannot be recovered

Recommended Rotation Flow

1. Initial State: Client has one default AppKey (Key A)
2. Request: Client contacts HV team to create a second AppKey (Key B)
3. Deploy: Client updates applications to use Key B
4. Transition: Both keys active; client migrates all services
5. Verify: Key A shows no usage for 7+ days
6. Disable: Request disable of Key A
7. Grace Period: Disabled key remains in system (re-enable if needed)
8. Delete: Permanently remove Key A

stateDiagram-v2
    [*] --> Created: Credential Created
    Created --> Single_AppKey: Default AppKey Auto-Generated
    Single_AppKey --> Two_AppKeys: Create 2nd AppKey
    Two_AppKeys --> One_Enabled_One_Disabled: Disable AppKey (7 days inactive)
    One_Enabled_One_Disabled --> Two_AppKeys: Re-enable if needed
    One_Enabled_One_Disabled --> Single_AppKey: Delete Disabled AppKey (Irreversible)
    Single_AppKey --> Single_AppKey: Continue using single AppKey

Current Implementation

All AppKey lifecycle operations are performed by the HyperVerge team on behalf of clients through backend administrative functions. Self-service rotation via the HVOne platform is planned for future quarters.

FAQs

Q: Do we support automated rotation? A: No. Rotation is a manual, user-driven process to ensure no disruptions occur.