Credential Governance: Managing Your Keys

Credentials Are the Real Target

In 86% of breaches involving ransomware, the attacker had valid credentials before deploying encryption. They did not break through a firewall or exploit a zero-day. They logged in. With legitimate usernames and passwords, obtained through phishing, credential stuffing, or purchasing them on the dark web.

This means the most valuable asset in your organisation is not your data. It is the credentials that control access to your data, your backups, your cloud consoles, and your recovery systems. Govern the credentials, and you govern everything.

The Credential Dependency Map

Most organisations have no single view of which credentials their critical operations depend on. To build one, trace backwards from your most important business processes:

• Email recovery: What credentials are needed to restore Exchange or Microsoft 365?
• Backup restoration: What login is required for the backup console? Where is the encryption passphrase?
• Domain recovery: What is the domain admin password? The DSRM password?
• Cloud console access: What are the root account credentials for AWS, Azure, or GCP?
• DNS management: Who controls your domain registrar account?
• Certificate authority: Where is the root CA private key? Who can issue certificates?

Each of these represents a single point of failure. If the credential is compromised, the attacker controls the system. If the credential is inaccessible, recovery is impossible.

The Three Tiers of Credential Governance

Tier 1: Operational Credentials

Day-to-day login credentials managed through your identity provider, password manager, and multi-factor authentication. These are well-understood and widely governed.

Tier 2: Administrative Credentials

Privileged access credentials for system administration, cloud console management, and security tool configuration. These should be managed through privileged access management (PAM) solutions with session recording and just-in-time access.

Tier 3: Recovery Credentials

Break-glass access codes, backup encryption passphrases, root CA private keys, and emergency access tokens. These are the credentials of last resort, used only when Tier 1 and Tier 2 systems have failed. They require physical governance because they must survive the failure of every connected system.

Why Tier 3 Demands Physical Disconnection

Tier 3 credentials have a unique requirement: they must be available when every connected system has failed. Storing them in a password manager, a cloud vault, or an encrypted file defeats their purpose, because these systems may be exactly what you are trying to recover.

Physical disconnection through OSS resolves this paradox. Recovery credentials stored in hardware with no network interface remain accessible regardless of what happens to your connected infrastructure. They cannot be encrypted, exfiltrated, or deleted by any network-based attack.

Credential Governance Lifecycle

1. Identify: Map every Tier 3 credential your recovery depends on
2. Capture: Record current values through controlled, verified procedures
3. Store: Place in physically disconnected storage with identity-verified access
4. Rotate: When credentials change, update offline copies through governed transfer procedures
5. Verify: Quarterly verification that offline credentials remain current and valid
6. Test: Annual recovery exercises that include accessing offline credentials under simulated incident conditions

Conclusion

Credentials are the most valuable and most vulnerable assets in any organisation. Governing Tier 3 recovery credentials through offline secure storage ensures that when everything else has failed, the keys to recovery remain in your hands.