The previous article made the case that credentials are your biggest vulnerability. If you accept that premise, the question becomes practical: what do you actually do about it?

This is the implementation roadmap. It’s organized into phases because you can’t fix credential security overnight, and trying to do everything simultaneously creates chaos. The sequence matters—each phase builds on the previous one.

Phase 1: Discovery and Inventory (Weeks 1-4)

You can’t secure what you don’t know exists. Before implementing any controls, you need visibility into the actual state of credentials across your environment.

Enumerate All Identity Stores

Start with a complete list of where credentials live:

• Directory services: Active Directory, Entra ID (Azure AD), Okta, Google Workspace—wherever user identities are managed
• Local accounts: Servers and workstations with local user accounts that aren’t federated
• Application-specific accounts: Databases with their own authentication, SaaS applications with local users, legacy systems with internal credential stores
• Service accounts: Both in directory services and as application-specific accounts
• API keys and secrets: Cloud provider keys, third-party integration tokens, internal service credentials

Document each store: what type of credentials, how many accounts, what manages them, what password policies apply.

Identify Privileged Accounts

Not all credentials are equal. A compromised domain admin account is catastrophic; a compromised read-only user is manageable.

Categorize accounts by privilege level:

• Tier 0: Infrastructure admin—domain admins, cloud account root/admin, hypervisor access
• Tier 1: Server and application admin—database admins, server local admins, application admins
• Tier 2: User workstation admin—help desk accounts, developer workstations
• Tier 3: Standard users—no administrative access

For each tier, document: how many accounts exist, who uses them, how credentials are stored, when they were last rotated.

Check for Credential Exposure

Before implementing new controls, understand your current exposure:

External breach databases: Services like Have I Been Pwned (for individual checks) or commercial threat intelligence platforms can tell you which of your users’ credentials appear in known breaches. This is your immediate risk—these credentials should be forced to rotate now.

Code repositories: Scan your Git repositories (GitHub, GitLab, Bitbucket) for hardcoded credentials using tools like truffleHog, GitLeaks, or GitHub’s built-in secret scanning. Check commit history—a secret removed from current code but present in history is still exposed.

Internal documentation: Search Confluence, SharePoint, shared drives, and wikis for patterns like “password,” “credential,” “API key,” or actual credential formats. You’ll find things.

Configuration files: Audit config files, environment variables, and deployment scripts for hardcoded secrets.

This discovery phase is uncomfortable because it reveals problems. That’s the point. Document everything found—you’ll address it in later phases.

Phase 2: Emergency Remediation (Weeks 2-6, overlapping with Phase 1)

Some discoveries require immediate action. Don’t wait until inventory is complete to address critical findings.

Force Password Reset for Breached Credentials

Any credential appearing in a known breach database should be reset immediately. This isn’t optional or “when convenient”—these credentials are actively being tested by attackers.

If you can’t identify which specific accounts are compromised, consider a broader forced reset for high-risk populations. Yes, this creates user friction. A breach creates more friction.

Rotate Exposed Secrets

Credentials found in code repositories, documentation, or config files should be rotated immediately. Don’t just delete the exposure—the credential may already be compromised. Rotation is required.

For each exposed secret:

1. Generate a new credential
2. Update all legitimate uses to the new credential
3. Revoke the old credential
4. Verify services still function
5. Document the incident and how it happened

Disable Orphaned Accounts

During inventory, you’ll find accounts that shouldn’t exist: former employees, test accounts from three years ago, service accounts for decommissioned systems. Disable them immediately.

If you’re unsure whether an account is still needed, disable rather than delete. If someone complains, you can re-enable. If nobody notices, it was orphaned.

Phase 3: Foundational Controls (Weeks 4-12)

With visibility and emergency remediation complete, implement the baseline controls that every organization needs.

Deploy Enterprise Password Management

If you don’t have an enterprise password manager (not just personal managers like 1Password or Bitwarden used individually), deploy one. Options include:

• 1Password Business / Bitwarden Organizations: Good for general-purpose credential management with shared vaults
• Keeper, Dashlane, LastPass Enterprise: Similar capabilities with different feature sets
• CyberArk, Delinea (Thycotic), BeyondTrust: Privileged Access Management (PAM) solutions for high-value credentials—more complex, more expensive, more capability

The choice depends on scale and maturity. Smaller organizations can start with a general-purpose manager and migrate to PAM later. Larger organizations or those with significant regulatory requirements may need PAM from the start.

Key implementation steps:

1. Deploy the manager to all employees
2. Provide training on proper use
3. Migrate shared credentials from spreadsheets, docs, and individual memory into managed vaults
4. Establish policies for what must be stored in the manager

Don’t assume deployment equals adoption. Monitor usage and follow up with teams that aren’t using it.

Implement SSO Everywhere Possible

Every application that supports SAML, OIDC, or similar SSO integration should use it. This reduces password sprawl—one identity provider credential instead of dozens of application credentials.

Audit your application inventory:

• Which applications support SSO?
• Which are integrated?
• Which could be integrated but aren’t?
• Which don’t support SSO and should be replaced?

SSO integration takes effort per application, so prioritize by risk: applications with sensitive data or privileged access first, then work down the list.

Enforce Password Policies

Modern password guidance (NIST 800-63B) has evolved:

• Minimum 12 characters (longer is better, encourage passphrases)
• No composition rules (requiring symbols/numbers doesn’t improve security)
• No periodic rotation for standard users (only rotate on suspected compromise)
• Banned password lists (block common passwords and variants)
• Screen against breach databases (block known-compromised passwords)

For privileged accounts, policies should be stricter: longer minimums, regular rotation, additional authentication factors.

Implement these policies in your identity providers and enforce them consistently. Legacy systems that can’t enforce modern policies should be flagged for replacement.

Implement MFA for Critical Systems

MFA isn’t optional anymore. At minimum, require it for:

• All privileged/admin accounts
• VPN access
• Cloud console access (AWS, Azure, GCP)
• Email access
• Source code repositories
• Any system with access to sensitive data

Phishing-resistant MFA (hardware keys, passkeys) is preferred over SMS or TOTP, but any MFA is better than password-only.

Implementation typically requires:

1. Selecting MFA methods to support
2. Configuring identity providers
3. Enrolling users (often requiring IT support)
4. Enforcing MFA in conditional access policies
5. Handling edge cases (lost devices, break-glass accounts)

See the companion article on MFA and Passkeys for detailed implementation guidance.

Phase 4: Privileged Access Management (Weeks 8-20)

With baseline controls in place, focus on the highest-risk credentials: privileged accounts.

Implement Just-in-Time Access

Privileged access should be temporary, not permanent. Users request elevated access for a specific task, receive it for a defined period, and lose it automatically.

This reduces standing privileges—attackers who compromise a user account don’t automatically get the privileged access that account had permanently.

Implementation options:

• PAM solutions with checkout/checkin workflows
• Entra ID Privileged Identity Management (for Azure/Microsoft environments)
• AWS IAM Identity Center with temporary role assumption
• Custom workflows using your ticketing system and automation

The key metric: how many accounts have permanent admin access vs. temporary? The goal is moving toward zero permanent privileges for human users.

Segregate Privileged Access

Privileged accounts should be separate from daily-use accounts. A user’s regular account (for email, browsing, daily work) should not also be a domain admin.

This separation limits damage from phishing and workstation compromise. An attacker who captures daily-use credentials doesn’t automatically get privileged access.

Implementation:

• Create separate admin accounts for privileged tasks
• Require privileged accounts to authenticate from privileged access workstations (PAWs) or through a bastion/jump server
• Prohibit privileged accounts from email, web browsing, and other attack-surface activities

Vault and Rotate Service Account Credentials

Service accounts are often the worst offenders: created years ago, known by multiple people, never rotated, with more permissions than needed.

Move service credentials into a PAM vault that:

• Stores credentials securely
• Provides automated rotation
• Controls who can access (human users) and what can use (applications) the credentials
• Logs all access

Rotation frequency depends on risk, but quarterly is a common starting point. For highly privileged service accounts, monthly or even more frequent rotation is appropriate.

Phase 5: Detection and Monitoring (Ongoing)

Controls fail. Detection catches what prevention misses.

Monitor for Credential Abuse

Configure alerting for:

• Impossible travel: Login from New York, then login from London an hour later
• New device/location: First-ever login from a particular device, IP, or geography
• Failed authentication spikes: Credential stuffing produces failed login waves
• Privilege escalation: User suddenly accessing resources they’ve never touched
• Off-hours activity: Admin actions at 3 AM by someone who works 9-5

These aren’t always attacks, but they warrant investigation. Tune thresholds to balance alert fatigue against coverage.

Continuous Credential Exposure Monitoring

Phase 1 discovery should become a continuous process:

• Subscribe to breach notification services
• Integrate secret scanning into CI/CD pipelines (block commits with secrets)
• Periodically rescan code repositories and documentation
• Monitor dark web/underground forums for credential dumps (requires specialized services or threat intel feeds)

Regular Credential Audits

Schedule periodic reviews:

• Monthly: Check for new service accounts, review recent privilege grants
• Quarterly: Access reviews for privileged accounts—does everyone with admin still need it?
• Annually: Full credential inventory refresh, compare to previous year, identify drift

Tools Summary

For organizations starting from scratch, here’s a practical tool stack by organization size:

Small (< 100 users):

• Password manager: Bitwarden Organizations or 1Password Business
• MFA: Built-in options (Entra ID MFA, Google Workspace)
• Secret scanning: GitHub/GitLab built-in features
• Breach monitoring: Have I Been Pwned domain search

Mid-size (100-1000 users):

• All of the above, plus:
• PAM for privileged credentials: Delinea Secret Server, Keeper Security Secrets Manager
• SSO consolidation: Okta, Entra ID P2, JumpCloud
• SIEM/detection: Microsoft Sentinel, Splunk, or equivalent

Enterprise (1000+ users):

• All of the above, with enterprise-grade options:
• Full PAM platform: CyberArk, BeyondTrust
• Identity governance: SailPoint, Saviynt
• Threat intelligence integration: Recorded Future, Flashpoint for credential monitoring
• Extended detection: Identity threat detection platforms

Measuring Progress

Track these metrics to measure improvement:

• Coverage: Percentage of users with password manager enrollment
• SSO integration: Percentage of applications integrated with SSO
• MFA enforcement: Percentage of accounts with MFA enabled
• Privileged account ratio: Number of privileged accounts per 100 users
• Standing privilege reduction: Percentage of privileged access that’s just-in-time vs. permanent
• Credential exposure: Number of corporate credentials in breach databases
• Rotation compliance: Percentage of service accounts rotated per policy

Report these monthly. Improvement should be visible. If metrics aren’t moving, something’s wrong with implementation.

The Uncomfortable Truth

No amount of tooling eliminates credential risk. Humans reuse passwords. Phishing works. Infostealers steal.

The goal isn’t perfection—it’s making credential compromise harder to achieve and less damaging when it happens. Each phase of this roadmap adds friction for attackers and limits blast radius when controls fail.

Start where you are. Do Phase 1 even if you can’t immediately do Phases 4 and 5. Partial implementation of this roadmap is dramatically better than doing nothing while you wait for the perfect solution.