VMware ESXi and vSphere Cluster Management

Credentials: Digital Identity, Authentication, and Secure Credential Management

Learn how credentials establish identity, support authentication and authorization, and should be created, stored, rotated, revoked, and protected.

A credential is information or an artifact used to establish identity, authenticate a subject, or support an authorization decision. Credentials can identify a person, service, device, application, or process.

Examples include passwords, passkeys, smart cards, certificates, private keys, API keys, access tokens, and service-account keys. A credential is not automatically a permission: it is evidence used by an access-control system to decide whether and how access should be granted.

Identity, Credentials, Authentication, and Authorization

An identity is the person, system, service, device, or process represented in an access-control system. An account is a system record associated with an identity. A credential is evidence or a secret associated with that identity.

• Authentication verifies that a subject is who or what it claims to be.
• Authorization determines which actions or resources an authenticated identity may use.
• An authentication factor is a category of evidence used during authentication.
• A permission is an allowed action, such as reading a file or modifying a database.
• A session is a temporary interaction context created after successful authentication. It may be represented by a session cookie or token.

A typical access flow is:

1. The subject makes an identity claim, such as entering a username.
2. The subject presents a credential, such as a password, security key, or token.
3. An authentication service verifies the credential and its relationship to the claimed identity.
4. The system creates a session or issues a token.
5. An authorization system evaluates the identity, requested resource, action, policies, and context.
6. The resource allows or denies the operation.

Valid credentials do not grant unlimited access. A user may authenticate successfully but lack permission to read a particular record. Similarly, a valid API key may be restricted to one endpoint, operation, environment, or time period.

Credential Categories

Knowledge credentials: Passwords, passphrases, and PINs. They are easy to deploy but can be guessed, reused, phished, or disclosed.

Possession credentials: Security keys, smart cards, one-time-password devices, and registered phones. Their security depends partly on protecting the physical device and enrollment.

Inherence credentials: Fingerprints, facial recognition, voice characteristics, and other biometric traits. They are convenient, but biometric data is sensitive and cannot usually be replaced after permanent compromise.

Cryptographic credentials: Private keys, public-key pairs, certificates, signed tokens, and passkeys. These use cryptographic operations to prove possession of a secret key or to represent delegated access.

Machine and service credentials: API keys, service-account keys, client secrets, certificates, and workload identities. They authenticate software rather than an interactive person.

Authentication Factors and MFA

Common factor categories are something you know, something you possess, and something you are. Some systems also use location or behavior, such as a recognized device, network, typing pattern, or normal login location. These additional signals are often risk indicators rather than independent factors.

Multifactor authentication (MFA) uses two or more independent factor categories. A password plus a second password is still one category, so it is weaker than a password plus a physical security key. Common MFA methods include authenticator-app codes, push approvals, hardware security keys, smart cards, and passkeys.

Phishing-resistant MFA binds the authentication operation to the legitimate service or website. FIDO2 and WebAuthn security keys and passkeys are preferred to SMS codes where practical because an attacker who copies a website's appearance cannot normally reuse the cryptographic response at a different domain. SMS remains better than password-only authentication in some situations, but phone-number takeover and message interception make it a weaker choice.

Passwords and Passphrases

A strong password is long, unique, and randomly generated. A memorable passphrase should contain several unrelated words and should not be based on public personal information, predictable substitutions, or common quotations. Never reuse a password across important services: a breach at one service can enable credential stuffing, in which attackers automatically try leaked username-and-password pairs on other services.

A password manager can generate, store, and fill unique credentials. Protect the manager with a strong primary passphrase and MFA. Avoid placing passwords in browser notes, spreadsheets, chat messages, or unencrypted documents.

Services should not store plaintext passwords or reversible encrypted passwords. Instead, they should store a password verifier produced with a unique salt and a slow, password-specific hashing algorithm. During login, the submitted password is processed using the stored salt and the result is compared with the verifier. The service should never need to decrypt a stored password.

Password reset is a sensitive credential-recovery process. Recovery links, backup codes, support procedures, and alternate email addresses can become an easier route into an account than the normal login. Recovery methods therefore require strong identity checks, short-lived reset artifacts, rate limits, notifications, and careful protection from social engineering.

Cryptographic Credentials

In public-key cryptography, a key pair contains a shareable public key and a secret private key. The private key may sign data or prove possession of the key pair; the public key can verify signatures or encrypt data for the private-key holder. A private key must be protected because anyone who obtains it may impersonate its owner or decrypt protected material, depending on its use.

A digital certificate is a signed document that binds a public key to an identity, domain, or service. A certificate authority (CA) issues or signs certificates. During a TLS connection, a client may validate the certificate chain to a trusted CA, the intended hostname, the validity period, key usage, and other policy requirements.

• A trust chain connects an end-entity certificate to a trusted root through one or more intermediate certificates.
• Expiration limits how long a certificate is accepted.
• Revocation invalidates a certificate before its expiration when its key or identity is no longer trustworthy.
• Renewal issues a replacement certificate before expiration or after a change in identity or key.

An access token is a credential-like artifact presented to a service for access within a defined scope and lifetime. A signed token commonly contains claims such as subject, issuer, audience, issued time, expiration, and permissions. The receiving service must validate the signature and check the issuer, audience, expiration, required scopes, and relevant policy. A refresh token is usually longer-lived and is used to obtain new access tokens, so it requires especially careful storage and revocation handling.

Credential Types and Appropriate Uses

Password or passphrase: Knowledge factor; interactive human login; risks include phishing, guessing, and reuse; protect with a password manager, rate limits, MFA, and secure verification.

Security key or passkey: Possession and cryptographic proof; phishing-resistant sign-in; risks include loss and weak recovery; protect with device registration, PINs where applicable, backup authenticators, and account alerts.

Biometric: Inherence factor; convenient local device unlock; risks include privacy exposure and limited replaceability; protect with local matching, encryption, fallback controls, and minimal collection.

Certificate and private key: Cryptographic identity for users, devices, or services; risks include private-key theft, expiration, and trust errors; protect with hardware-backed storage, chain validation, inventory, renewal, and revocation.

API key or client secret: Machine or application credential; simple API authentication; risks include repository leaks, broad scope, and long lifetimes; protect with secret managers, narrow permissions, rotation, monitoring, and short lifetimes where supported.

Access or refresh token: Delegated or session access; risks include theft, replay, excessive lifetime, and incorrect audience validation; protect with secure transport, protected storage, limited scope, expiration, rotation, and revocation.

Credential Lifecycle Management

Credentials need management from creation to destruction. The lifecycle commonly includes:

1. Creation and enrollment: Establish the identity, verify ownership, and register an authenticator or generate a key.
2. Issuance and distribution: Deliver the credential through a controlled channel to the intended owner or workload.
3. Activation: Require confirmation, device binding, PIN setup, or another step before use.
4. Storage and use: Keep the credential in an approved protected location and use it only for its intended purpose.
5. Monitoring and audit: Record issuer, owner, scope, creation time, last use, changes, and suspicious activity without recording the secret value.
6. Rotation and renewal: Replace credentials on a planned schedule or after risk changes. Certificates and keys often need renewal before expiration.
7. Revocation: Invalidate a credential immediately when it is exposed, no longer needed, or associated with a departed person or retired system.
8. Recovery: Provide an accessible, controlled way to regain access without creating a bypass that undermines authentication.
9. Destruction: Delete credentials and backups securely, remove registrations, and document completion.

Frequent forced password changes can be counterproductive when there is no evidence of compromise: users may choose predictable variations or write passwords down. Prefer long unique passwords, MFA, breach detection, risk-based controls, and immediate changes after exposure. Rotation remains important for secrets, keys, and certificates when required by risk, policy, ownership changes, or technical design.

Offboarding must disable the account, revoke sessions and personal access tokens, remove security-key registrations, rotate shared administrative secrets, disable service credentials owned by the departing person, and review recent privileged activity. Maintain an inventory and accountable owner for privileged and nonhuman credentials.

Secure Storage and Handling

• Use password managers for human passwords.
• Use hardware-backed keystores or hardware security modules for high-value private keys where practical.
• Use a secret manager to store, distribute, rotate, and audit application secrets.
• Encrypt secrets at rest and restrict access using least privilege and separate administrative roles.
• Protect backups with encryption, access controls, recovery testing, and separate key management.
• Keep secrets out of source code, public repositories, logs, screenshots, tickets, chat messages, and committed configuration files.

Environment variables and mounted secret files can separate a secret from application source, but they are not automatically safe. Environment values may be visible through process inspection, diagnostics, crash reports, child processes, or logs. Mounted files require filesystem permissions, container isolation, backup controls, and careful cleanup. Runtime retrieval from a secret manager or workload identity is often preferable to distributing a permanent secret.

openssl rand -base64 32

Use this command in a secure local environment to generate a high-entropy application secret. Put the result in an approved secret manager; do not paste a real value into documentation or source control.

ssh-keygen -t ed25519 -C "user@example.com"

Protect the generated private key with a passphrase and distribute only the public key. An SSH private key is itself a credential and should be inventoried, backed up securely when necessary, and revoked by removing its authorized registration when no longer trusted.

DATABASE_PASSWORD="retrieve-at-runtime-from-a-secret-manager"

This illustrates configuration separation, not a real secret. Restrict access to the delivery mechanism and review whether the process, diagnostics, or deployment platform can expose it.

Credential Threats

• Phishing and social engineering: Attackers persuade a person to disclose a password, approve a push, install software, or reveal recovery information.
• Credential stuffing: Reused credentials from one breach are tried against many services.
• Brute-force guessing: Many possible passwords are tested against one account or secret.
• Password spraying: A small set of common passwords is tried against many accounts to avoid per-account defenses.
• Keylogging and malware: Malicious software captures keystrokes, tokens, files, or authentication events.
• Session theft: An attacker obtains a cookie, access token, refresh token, or device session and uses it without knowing the password.
• Secret leakage: API keys, private keys, client secrets, and cloud credentials appear in repositories, logs, images, backups, or support conversations.
• Operational weaknesses: Shared accounts, excessive privilege, stale credentials, poor recovery, and missing ownership make misuse harder to attribute and contain.

API keys and cloud credentials are particularly dangerous when they are long-lived, broad, or copied across environments. A leaked private key may enable impersonation until it is revoked or replaced. A token may remain usable even after a password change unless the system explicitly invalidates its sessions or token family.

Defenses and Operational Controls

• Require MFA for important human and administrative accounts, preferring phishing-resistant methods.
• Use unique passwords and password managers.
• Apply least privilege: grant only the minimum access required for a task.
• Use role-based access control, just-in-time privileged access, and separate administrator accounts.
• Prefer short-lived, narrowly scoped tokens and workload identities over permanent machine keys.
• Apply rate limiting, progressive delays, lockout or risk-based controls, and detection of unusual login patterns.
• Run secret scanning in repositories and pre-commit checks to catch accidental publication.
• Monitor authentication, privilege changes, token issuance, key use, and failures.
• Keep audit trails that identify the principal, action, resource, time, result, and context, but never log the credential value itself.

A conceptual policy might grant a service account only read permission for the single storage location it needs. This is safer than granting broad administrator access because a leaked credential has a smaller blast radius.

User, Administrative, and Application Credentials

Interactive human credentials support actions such as signing in to a workstation or web application. Administrative credentials perform high-impact operations and should use separate accounts, stronger MFA, approval or just-in-time elevation, session recording where appropriate, and frequent access reviews.

Noninteractive credentials authenticate software. A service account belongs to an application or automated workload rather than an individual. API keys and OAuth client credentials can identify applications, while workload identity allows a deployed workload to obtain short-lived credentials from its runtime platform. Avoid shared credentials: assign actions to identifiable principals so that accountability, investigation, and revocation are possible.

Practical Examples

Personal account protection

A user generates a unique long passphrase in a password manager and registers a hardware security key for email and financial accounts. The password manager limits reuse, while the security key reduces the impact of password phishing.

Website password handling

A web application stores a salted password hash and verifies a login attempt by hashing the submitted password and comparing the result. It does not decrypt or retrieve a stored plaintext password.

Cloud workload access

A deployed workload receives a short-lived identity token from its runtime platform instead of embedding a permanent cloud access key in source code. This reduces distribution and exposure time.

Certificate-based service identity

A service presents a certificate during a TLS connection. The client verifies the hostname, expiration, signature chain, and trusted issuer before accepting the service identity. Disabling certificate validation is not a safe permanent solution.

Credential Incidents and Response

Possible compromise indicators include unfamiliar sign-ins, unexpected MFA prompts, new recovery methods, unexplained password resets, unusual API calls, tokens used from unexpected locations, certificate warnings, private-key access alerts, and secrets found in repositories or logs.

1. Contain access: Block suspicious principals, isolate affected systems, restrict network paths, and stop automated jobs if necessary.
2. Revoke or rotate: Revoke exposed passwords, API keys, certificates, private keys, and service credentials. Issue replacements with minimal scope.
3. Invalidate sessions and tokens: Revoke active sessions, refresh tokens, personal access tokens, and dependent credentials. Changing a password alone may not invalidate them.
4. Investigate use: Search authentication and audit logs for access, privilege changes, data retrieval, persistence, and related credentials.
5. Remediate exposure: Remove secrets from active systems, correct permissions, clean deployment artifacts, and address the original disclosure path. Removing a value from the latest source file does not make a previously committed value safe.
6. Notify appropriately: Follow organizational, contractual, legal, and regulatory requirements.
7. Learn and prevent recurrence: Add scanning, improve enrollment and offboarding, narrow permissions, update recovery procedures, and test the response.

User password: Disable or reset the account and revoke sessions; review sign-ins and recovery changes; issue a new unique password and require MFA; check reused accounts and stored payment or personal data.

API key: Disable the key immediately; search API and cloud logs for use; create a narrowly scoped replacement; inspect repositories, pipelines, logs, and dependent services.

Private key or certificate: Revoke the certificate or remove the public-key registration; investigate signatures, TLS use, and key access; generate a new key pair and certificate; check every host, backup, and trust store.

Access or refresh token: Revoke the token family and sessions; inspect token use, audience, scope, and issuance; issue a new token through the approved flow; check cached tokens and connected applications.

Service credential: Stop or isolate the workload if needed; review service and cloud audit logs; rotate or replace the credential and deploy safely; inspect shared secrets, scheduled jobs, and downstream systems.

Troubleshooting Credential Problems

Cannot sign in after changing a password

• An old password may be saved in a browser, mobile application, or operating-system credential store.
• An MFA challenge may be failing, or a device clock may be incorrect for time-based codes.
• The account may be locked, or the reset flow may not have completed.

Confirm the account and reset status, remove or update cached credentials, and use approved recovery procedures. Verify that the expected MFA method is enrolled rather than disabling MFA as a shortcut.

API returns unauthorized or forbidden

Check whether the credential is missing, expired, revoked, malformed, or sent in the wrong header. A valid credential may still lack the required scope or role, or it may belong to another environment. Check expiration, audience, issuer, authentication method, and least-privilege policy. Keep test and production credentials separate.

Private key or API key exposed in source control

Treat it as compromised immediately. Revoke or rotate it, invalidate dependent sessions or tokens, review access logs, remove the value from active code, move it to an approved secret-management system, and enable secret scanning. Do not rely on deleting the latest commit alone.

Certificate-based connection fails

Inspect expiration, hostname matching, certificate chain, trusted issuer, and system time. Renew or replace the certificate through the approved process. Do not permanently bypass certificate validation.

Service stops after secret rotation

The application may still use the old value, the replacement may not have reached every instance, or dependent systems may have been updated in the wrong order. Where supported, use a planned overlap period, verify deployment propagation and secret-manager access, monitor failures, and retire the old secret only after successful cutover.

Privacy, Usability, and Governance

Authentication design balances security with usability. A control that is too difficult may encourage unsafe workarounds, while a control that is too weak increases compromise risk. Provide accessible authenticators, backup options, clear enrollment guidance, and recovery processes that preserve strong identity checks.

Biometrics deserve special care. A fingerprint or face may be convenient for unlocking a local device, but biometric data is sensitive, difficult to change, and capable of revealing personal information. Prefer local biometric matching that unlocks a cryptographic credential rather than sending raw biometric data to every service.

Organizational policies should define acceptable use, prohibit credential sharing, specify retention and deletion, require ownership and inventory, describe compliance obligations, and mandate periodic access reviews. Review privileged and nonhuman credentials for owner, purpose, scope, age, last use, expiration, rotation history, and revocation capability.

Key Takeaways

• Credentials provide evidence for identity and access decisions; they are distinct from identities, accounts, permissions, and sessions.
• Use unique passwords with a password manager and prefer phishing-resistant MFA such as FIDO2 or WebAuthn passkeys.
• Protect private keys, API keys, tokens, and service credentials as carefully as passwords.
• Use least privilege, short lifetimes, scoped tokens, workload identity, secret managers, monitoring, and audit trails.
• Track the entire lifecycle from enrollment through rotation, revocation, recovery, and destruction.
• When exposure occurs, contain access, revoke or rotate credentials, invalidate sessions and tokens, investigate, remediate, and improve controls.