OWASP NHI4:2025 Insecure Authentication Deep Dive Introduction: The Era of Non-Human Identities Beyond Humans

Today's IT infrastructure, automation, and cloud environments are no longer operated solely by humans. Non-Human Identities (NHIs), such as service accounts, APIs, microservices, IoT devices, and bots, play a crucial role in the modern technology ecosystem. They access systems and data and automate tasks without direct human intervention.

The number of NHIs is increasing exponentially. Recent research indicates that NHIs already far outnumber humans, with one report estimating an average of 46 NHIs per human. It's predicted that the number will exceed 45 billion by 2025, and in DevOps environments specifically, NHIs outnumber humans by at least 45 to 1.

This explosive growth of NHIs has fundamentally changed the attack surface. Focusing solely on human account security is no longer sufficient. The vast scale of NHIs demands a shift in security management approaches. Manual management is impossible, and most NHIs reside in security blind spots, posing significant risks. Therefore, specialized tools for automatically detecting, managing, and protecting NHIs are essential. Cremit is also focusing on these NHI security challenges, particularly the difficulties of Secret Sprawl and detecting hidden NHIs.

OWASP NHI Top 10: A Critical Security Compass

Against this backdrop, the Open Web Application Security Project (OWASP) released the OWASP NHI Top 10 list to identify major security threats related to NHIs and provide practical guidance to developers and security professionals. This list serves as an important benchmark for raising awareness about NHI security and establishing effective response strategies. The Cremit blog has previously covered other NHI threats such as NHI1 (Improper Offboarding), NHI2 (Secret Leakage), and NHI3 (Third-Party Supply Chain Risk).

NHI4:2025 Insecure Authentication Deep Dive – The Attacker's First Door

This article provides an in-depth analysis of the fourth item on the OWASP NHI Top 10 list: NHI4:2025 Insecure Authentication. Insecure authentication encompasses all security vulnerabilities that can arise in the process of an NHI proving its identity and accessing protected resources. It is a critical threat vector frequently exploited by attackers as the initial entry point for infiltrating systems and stealing data.

Why is This Important?

For our technical audience at Cremit, including developers, security professionals, and DevOps engineers, understanding and preparing for NHI4 is crucial for building and protecting secure applications, APIs, and infrastructure. This is especially true in cloud and automated environments. Cremit strives to provide insights and solutions for these challenges. Through this article, we aim to help you understand the complexities of NHI4 and formulate effective defense strategies.

Dissecting NHI4: The Many Faces of Insecure Authentication

Threat Definition: What is 'Insecure Authentication' for NHIs?

In the context of NHIs, insecure authentication means more than just using incorrect passwords. It includes all inherent vulnerabilities in the entire process of verifying an NHI's identity and granting access permissions. This involves weaknesses in credential management, use of insecure communication protocols, flawed authorization logic, and more.

Common Pitfalls and Symptoms

Insecure authentication in NHI environments manifests in various forms:

1. Weak, Default, or Hardcoded Credentials:

• Many NHIs use easily guessable passwords (like 'admin'/'password') during initial setup or continue using default API keys/tokens without changing them.
• Hardcoded credentials are a particularly serious problem. Embedding sensitive information like API keys, secret tokens, and encryption keys directly into source code, configuration files, or environment variable files (.env) is extremely risky. If code repositories are hacked (e.g., New York Times, Emerald Whale cases), CI/CD pipelines are exposed, or code is accidentally uploaded to public repositories like Docker Hub (cases where over 100,000 valid secrets were found), hardcoded information can immediately lead to severe security incidents. Collaboration tools like Slack, Jira, and Confluence can also become channels for secret leakage.
• Hardcoding improves development convenience but is akin to giving attackers direct access to the system upon code exposure. According to GitGuardian analysis, millions of secrets are leaked on GitHub annually. Interestingly, research shows that AI coding assistants like GitHub Copilot, while boosting productivity, can also increase the likelihood of secret leakage by 40%. Therefore, the importance of tools (SAST/detection tools) that automatically detect secrets early in the development process is growing. Cremit also emphasizes the importance of such secret detection and identifying hidden secrets, offering related solutions.

2. Risks of Secret Sprawl and Poor Management:

• Secret Sprawl refers to the uncontrolled proliferation of secrets like API keys, tokens, certificates, and passwords across various locations such as code, configuration files, multiple vaults, and cloud storage (e.g., S3).
• When these scattered secrets are not managed centrally, tracking, periodically rotating, and revoking them becomes nearly impossible. Many organizations store secrets in multiple locations, making it difficult for security teams to gain a unified view and manage them effectively. The dispersion of secrets means an increased attack surface, where each leaked secret can serve as a foothold for system compromise. Cremit's AWS S3 NHI detection feature is part of the effort to address such sprawl issues.

3. Neglected Lifecycle Management: Orphaned Keys and Long-Lived Secrets:

• Failure to properly manage the entire lifecycle of NHI credentials—creation, storage, usage, rotation, and revocation (offboarding)—can lead to serious security problems.
• Long-Lived Secrets, i.e., static API keys or passwords with no or very long expiration dates that are not rotated periodically, are particularly dangerous. One study found that over 70% of NHIs are not rotated within the recommended timeframe, with the average rotation period being a staggering 627 days. Even more alarming is the fact that 70% of secrets first discovered in public repositories in 2022 were still valid years later.
• The continued validity of leaked credentials indicates a failure in the systems for periodic secret rotation and revocation. This highlights the importance not only of preventing leaks but also of quickly mitigating the damage after a leak occurs. Attackers finding keys leaked years ago still have a high chance of using them to access systems. Therefore, automated, enforced secret rotation and robust offboarding (related to NHI1) are not just recommendations but essential security measures.
• This issue is directly linked to NHI1: Improper Offboarding. Failure to promptly remove access rights for decommissioned services or departed employees leaves valid credentials vulnerable to exploitation by attackers.

4. Insecure Communication Channels and Weak Protocols:

• Using unencrypted channels for data communication between NHIs (APIs, services, etc.) makes them vulnerable to Man-in-the-Middle (MitM) attacks. Attackers can eavesdrop on communication or hijack the NHI itself.
• Relying solely on static API keys and not employing stronger mechanisms like mutual authentication (Mutual TLS, mTLS) is a common weakness. Simple API key authentication, while widely used, lacks mutual verification capabilities and is inherently weaker and more susceptible to interception than mTLS or dynamic credential methods. API keys are often not protected by two-factor authentication (2FA) like user logins, making their leakage potentially more damaging. Technologies like SPIFFE/SPIRE overcome the limitations of static keys, enabling mTLS implementation using short-lived SVIDs based on identity rather than network trust. This suggests a need to move beyond basic API key authentication towards stronger, identity-based mutual authentication for sensitive NHI communications.

5. Risks of Excessive Privileges (Violation of Least Privilege):

• NHIs are often granted far more permissions than they actually need. Research findings are alarming: 96% of leaked GitHub tokens had write permissions, 95% had full repository access, and 99% of GitLab API keys had full or read-only access.
• Such excessive privileges make it easier for attackers, after compromising a single NHI, to move laterally within the system or escalate privileges by leveraging those permissions. In the New York Times hack, a single GitHub token with excessive permissions allowed access to all repositories. In the Dropbox Sign breach, a compromised service account with high privileges led to customer database access.
• Excessive privileges act as a damage multiplier in breach incidents. The compromise of a single NHI with overly broad access can bypass other defenses and lead to catastrophic data loss or system takeover. Therefore, applying the Principle of Least Privilege—granting NHIs only the minimum necessary permissions—is as critical as protecting the credentials themselves. This implies a need not just for better authentication, but also for better authorization management.

Ripple Effects: Real-World Consequences of NHI4 Vulnerabilities

Beyond theoretical risks, insecure NHI authentication can lead to severe and tangible consequences:

• Unauthorized Access and Data Breaches: Sensitive customer information, Personally Identifiable Information (PII), financial data, and corporate intellectual property can fall into attackers' hands.
• System Compromise and Takeover: Attackers can use compromised NHIs as a foothold for lateral movement or privilege escalation to gain control over the entire environment (e.g., CI/CD pipeline attacks).
• Service Disruption and Downtime: Disruption of critical service operations can severely impact business continuity (reports of certificate-related outages).
• Ransomware Deployment: Compromised NHIs can be exploited as the initial infiltration vector for ransomware attacks (reports of increasing ransomware and double extortion).
• Financial Losses: Direct financial damages arise from incident response and recovery costs, regulatory fines, and revenue loss (mention of rising data breach costs).
• Reputational Damage and Loss of Trust: Loss of customer trust and damage to brand reputation can have long-term negative impacts on business.
• Supply Chain Attacks: Compromised NHIs in one system can trigger a chain reaction, leading to attacks that affect partners or customers (NHI3 mention) (e.g., BeyondTrust/US Treasury supply chain incidents).
  
  

Learning from Real Breaches: Stories of NHI Authentication Failures

Examining real-world breach cases is crucial for understanding how theoretical risks translate into reality and recognizing the urgency of response. The table below summarizes recent major breaches exploiting insecure NHI authentication.

‍Detailed Analysis (Example - Dropbox Sign Breach)

The Dropbox Sign breach clearly illustrates how NHI4 failures can cascade into broader risks. The attack began by compromising a backend service account (an NHI) used by an automated configuration tool. The key NHI4 failures here were either weak security of the service account itself (e.g., inadequate protection measures) or it possessing excessive permissions.

The consequences of this initial breach were extensive. Attackers gained access not only to user emails, usernames, phone numbers, and hashed passwords but also to critical authentication information like API keys and OAuth tokens. Even information of signing participants who hadn't created accounts was exposed.

Notably, the compromise of one privileged NHI led to the mass exposure of other authentication credentials (API keys, OAuth tokens). This demonstrates how an initial NHI4 failure (insecure service account authentication/authorization) can directly lead to the theft of credentials needed for other NHI authentications, exponentially expanding the attack surface and necessitating extensive remediation efforts like rotating all keys and tokens. Dropbox had to reset passwords, force logouts for all user sessions, and rotate all API keys and OAuth tokens after the incident. This case clearly shows how interconnected various aspects of NHI security are.

Strengthening Defenses: A Zero Trust-Based, Multi-Layered Approach to NHI Authentication Security

Effectively countering the threat of insecure authentication in NHI environments hinges on rigorously applying the Zero Trust security model to NHIs as well. The principle of "Never Trust, Always Verify" must govern every NHI access request. Explicit authentication and authorization are required for every interaction, regardless of network location, achieved through Continuous Authentication and Authorization.

Principle 1: Implement Strong Authentication Methods

1. Use Short-Lived, Dynamic Credentials:

• Static, long-lived secrets are risky, making it crucial to transition to short-lived, dynamically generated credentials.
• OAuth 2.0: Widely used for delegating permissions to other services and obtaining short-lived access tokens (OAuth abuse cases underscore its importance).
• SPIFFE/SPIRE: A robust, modern standard for workload identity. It issues automatically rotated, cryptographically verifiable short-lived identity documents (SPIFFE Verifiable Identity Documents, SVIDs - typically X.509 certificates or JWTs) to workloads. SPIFFE/SPIRE provides secure introduction mechanisms to solve the initial trust bootstrapping problem ("where does the first credential come from?") and enables mTLS implementation without static secrets. Its status as a graduated project of the Cloud Native Computing Foundation (CNCF) adds to its credibility.
• Technologies like SPIFFE/SPIRE represent a fundamental shift in NHI authentication. They move the focus from managing static secrets to managing verifiable identities, a much more secure and suitable approach for dynamic cloud-native environments. Traditional methods struggle with managing static secrets (leakage, rotation failures, etc.). SPIFFE/SPIRE directly addresses this by issuing short-lived, automatically rotated SVIDs based on workload attestation instead of pre-shared secrets. This eliminates the need for static credentials for workload-to-workload authentication, solves the initial bootstrap problem, aligns perfectly with Zero Trust principles, and addresses key NHI4 weaknesses.

2. Perform Context-Based Verification:

• Don't just verify credentials when an NHI requests access. Make access decisions based on a comprehensive assessment of contextual information, including time, location, behavioral patterns, and the request environment. This acts as an additional safeguard.

3. Mutual TLS (mTLS) for Secure Service-to-Service Communication:

• Reiterating the importance of mTLS for encrypting communication between services and APIs and ensuring mutual authentication on both sides. It provides significantly stronger security than simple API key authentication.

4. Apply MFA to NHIs Where Possible:

• While applying Multi-Factor Authentication (MFA) to automated systems can be challenging, consider scenarios requiring additional authentication factors (e.g., approval steps) for high-risk operations or under specific conditions. Although MFA is not a silver bullet (one study reported MFA was involved in 50% of incidents), it remains an important security layer. Cloud providers like AWS and Azure strongly recommend MFA for privileged human users, which indirectly helps protect the NHIs they manage.

Principle 2: Master Secure Secret Management

1. Detect Secrets Before They Leak (Shift-Left):

• Detecting secrets early in the Software Development Lifecycle (SDLC) is crucial.
• SAST/DAST: Static Application Security Testing (SAST) analyzes code without executing it, while Dynamic Application Security Testing (DAST) tests running applications. SAST is particularly effective at finding hardcoded secrets and insecure coding practices. DAST finds runtime issues but doesn't directly identify secrets hidden in code.
• SAST is vital for finding hardcoded secrets (a major NHI4 attack vector). However, SAST or DAST alone may not be sufficient. They are complementary, and specialized secret scanning tools often provide more focused detection capabilities. Furthermore, tools alone are not enough; process matters. One study noted leaks still occur even in repositories using secret management solutions. SAST can sometimes produce too many results, making prioritization difficult. This means SAST/DAST are necessary but not sufficient. Integrating specialized secret detection tools, like Cremit's solutions, into the CI/CD pipeline can complement general SAST/DAST, offering more focused and rapid issue identification.
• Cremit's secret detection capabilities (Probe engine, Nebula repository, SDLC integration) assist in this early detection.

2. Utilize Centralized Secure Vaults:

• All secrets—API keys, certificates, passwords—should be stored securely in dedicated vaults like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, not in code or configuration files. Access to these vaults must be strictly controlled.

3. Automated Secret Rotation: A Necessity, Not an Option:

• The problem of leaked credentials remaining usable makes periodic secret rotation critical. Manual rotation is error-prone and unmanageable at scale, necessitating automated rotation processes. Leveraging tools or platforms that support this is highly recommended.

4. Eliminate Hardcoding Through Secure Development Habits:

• Establish secure coding standards, provide relevant training to developers, and encourage the use of secret management tools from the outset.

Principle 3: Establish Comprehensive NHI Lifecycle Management

1. Gain Visibility: Discover and Inventory All NHIs:

• Achieving complete visibility into all NHIs across all environments (cloud, on-premises, SaaS) is paramount. You can't protect what you don't know exists. Utilize tools or platforms that automatically discover and inventory NHIs. Cremit's detection features contribute to this visibility.

2. Enforce the Principle of Least Privilege:

• Strictly adhere to the principle of granting each NHI only the minimum permissions necessary to perform its tasks. Assigned permissions should be reviewed periodically.

3. Automated Provisioning and Secure Offboarding (Links to NHI1):

• Automate the process of creating NHIs with appropriate (minimal) permissions. An automated process to disable or delete NHIs when applications or services are decommissioned, or when associated personnel leave, is essential. This directly helps mitigate NHI1: Improper Offboarding risks.

4. Continuously Monitor for Anomalous Behavior:

• Implement systems to monitor NHI activities (API calls, resource access, etc.) in real-time. Use Anomaly Detection techniques to identify and respond to abnormal access attempts (e.g., access from unusual locations, excessive login failures, privilege escalation attempts).

Principle 4: Tailor Security to the Environment

1. Leverage Cloud-Native Best Practices:

• Major cloud providers offer specific features designed to improve NHI authentication security over traditional static credentials. Leveraging these native capabilities is important, but requires understanding the nuances and best practices of each platform.
• AWS: Use IAM roles (instance profiles) for EC2 instances or other services instead of long-term access keys. Use temporary credentials via STS. Utilize AWS Secrets Manager. Apply least privilege and use IAM conditions. Monitor activity with CloudTrail. Regularly clean up unused resources.
• Azure: Utilize Managed Identities (system-assigned or user-assigned) to avoid embedding credentials in code. User-assigned identities are often preferred for flexibility and reduced management overhead. Apply RBAC with least privilege. Pay attention to lifecycle management (user-assigned identities and role assignments require manual deletion). Use Azure Key Vault for other secrets.
• GCP: Use Workload Identity Federation to allow external workloads (e.g., from GitHub Actions, AWS, Azure) to access GCP resources without service account keys. Configure pools, providers, attribute mappings, and conditions carefully for security. Using a dedicated project for federation management is recommended. Apply least privilege via IAM bindings for the federated identity or impersonated service account.
• AWS, Azure, and GCP each offer unique approaches (IAM Roles, Managed Identities, Workload Identity Federation). While the goal (secure, credential-less authentication) is similar, the implementations differ significantly. This implies that multi-cloud environments require either platform-specific expertise or an abstraction layer or platform capable of managing NHIs consistently across clouds. Applying concepts from one cloud directly to another may not be effective.

Principle 5: Consider Specialized NHI Security Platforms

1. The Role of Dedicated Solutions: Specialized platforms are emerging to address the complexity of NHI security, aiming to provide a unified approach.
2. Key Capabilities: Synthesizing descriptions from various vendors reveals common functionalities (often overlapping, but painting a holistic picture):

• Discovery and inventory of NHIs across all environments (multi-cloud/hybrid)
• Posture management (identifying risks, misconfigurations)
• Contextualization (understanding ownership, usage, permissions)
• Lifecycle management (automated provisioning, rotation, revocation)
• Integration with or provision of secret management tools
• Threat and anomaly detection (NHI-DR)
• Automated remediation
• Secure access control
• Classification

3. How Cremit Contributes to Solving NHI4: Cremit has particular strengths in early detection of exposed secrets, understanding NHI sprawl, and providing tools for secure development (DevSecOps focus). Cremit can integrate with or complement broader NHIM platforms.

Looking Ahead: Regulatory Compliance, Innovation, and Vigilance

Regulatory Pressure: Understanding Mandates like EO 14144

Regulations such as U.S. Executive Order 14144 are significant drivers for enhancing NHI security. While this order specifically impacts federal agencies and contractors, it influences industry-wide best practices.

Key relevant requirements include:

• Enhanced Identity Management: Mandates adoption of phishing-resistant authentication standards (e.g., WebAuthn).
• Improved Secret Management: Emphasizes strengthening key management and rotation.
• Software Attestation Requirements: Requires software suppliers to attest to secure development practices (including secrets handling).
• Push for Zero Trust Architecture: Stresses the implementation of Zero Trust principles.
• AI and Cybersecurity: Accelerates research and development into using AI for cybersecurity.

Regulatory mandates like EO 14144 codify many of the best practices needed to combat NHI4. They exert pressure, particularly in sectors like federal contracting, to elevate NHI security standards, shifting NHI security from a 'nice-to-have' to a 'must-do'.

The Need for Continuous Adaptation and Improvement

NHI security is not a one-time task but an ongoing process. Threats constantly evolve, and environments continuously change. Therefore, strategies must be consistently monitored, regularly reviewed, and continuously improved as needed.

Conclusion

NHI4:2025 Insecure Authentication is one of the most critical and pervasive threats in modern systems. It serves as a primary gateway for attackers to infiltrate systems, and the consequences can be devastating.

Key defense strategies to strengthen NHI security posture include:

• Strong Authentication: Adopt dynamic credentials, mTLS, and context-based verification.
• Rigorous Secret Management: Detect early, use secure vaults, and automate rotation habitually.
• Comprehensive Lifecycle Management: Inventory all NHIs, apply least privilege, monitor continuously, and ensure secure offboarding.
• Leverage Cloud-Native Features and Consider Specialized Tools.
• Underpinning all of this must be a Zero Trust mindset.

Cremit is committed to helping organizations overcome these complex challenges, particularly in secret detection and visibility. Proactive and continuous effort is essential to protect valuable assets from the ever-increasing security threats related to NHIs. We hope this discussion enhances your awareness of NHI security and aids in practical security improvements.