Secrets and Configuration

Separate secret-classified values from ordinary environment configuration and assign an owner to both. Documentation should describe purpose and ownership without containing real secret values.

Classification

Type	Examples	Handling
Secret	API key, OAuth client secret, signing key, password	Approved secret store, restricted access, rotation
Connection string	Database or provider connection containing credentials	Treat as a secret even when generated by infrastructure
Sensitive identifier	Tenant, subscription, internal endpoint, account identifier	Controlled documentation and environment-specific validation
Configuration	Feature flag, model deployment name, sender address, timeout	Versioned configuration with review and validation

Mandatory Controls

• Never place real secrets in documentation, tickets, chat, email, screenshots, source control, or deployment reports.
• Store production secrets in Azure Key Vault or the customer-approved secret manager.
• Prefer managed identity over credentials where supported.
• Separate environments and prevent test credentials from reaching production.
• Give every credential an owner, purpose, allowed consumers, creation date, and rotation or expiry rule.
• Rotate credentials after suspected exposure, owner departure, provider policy change, or agreed maximum age.
• Validate customer-specific endpoints, tenants, senders, and model deployments before go-live.
• Log secret access events without logging secret values.

Handover Inventory

The customer-safe inventory should list the configuration category, purpose, owning service, source of value, sensitivity class, owner, rotation method, and validation status. It should not expose repository paths, local build paths, raw deployment output, or the secret-store value itself.

Include credential rotation and emergency revocation in Incident Response.