TL;DR: Neho’s exposed .env file left AWS credentials, API keys, and email service secrets accessible, creating phishing, code-signing, and cloud abuse risk, according to Entro Security. The incident shows that secrets management fails when discovery, rotation, and access control are treated as separate tasks instead of one governance chain.
At a glance
What this is: This is an analysis of Neho’s exposed cloud secrets and the governance failure that left credentials, API keys, and email-service access reachable.
Why it matters: It matters because IAM and NHI teams need secrets discovery, rotation, and privilege control to operate as one lifecycle, not disconnected hygiene steps.
Context
Neho’s incident is a cloud secrets governance problem, not just a misconfigured file. An exposed .env file can turn one operational mistake into broad credential exposure across databases, email services, and third-party tools, which is exactly where NHI governance breaks down.
For IAM and NHI programmes, the core issue is that secrets are often created, copied, stored, and reused across multiple systems without a single accountable lifecycle. When discovery, rotation, and access control are handled separately, teams lose track of who can use the credential, where it exists, and whether it still needs to exist.
The article also shows how quickly one exposed secret can become a wider identity problem. Database credentials, API keys, and email-sending access all behave like non-human identities once they are embedded in cloud workflows and service integrations.
Key questions
Q: What breaks when a .env file exposes live cloud secrets?
A: A single exposed .env file can collapse several controls at once because it often contains database passwords, API keys, and email service credentials. The failure is not just disclosure. It is the loss of ownership, scope, and revocation control over non-human identities that can be reused immediately for impersonation or service abuse.
Q: Why do exposed service account credentials create such broad risk?
A: Service account credentials often carry standing access into cloud, CI/CD, or SaaS systems, so one exposed secret can open multiple control paths at once. The risk is amplified when the credential has not been scoped tightly or tied to a clear owner. That is why secret exposure must be treated as identity governance, not just data leakage.
Q: How can teams tell whether secret rotation is actually reducing risk?
A: Teams should look at whether a rotated secret was ever exposed at runtime, whether it still works in downstream systems, and how quickly it can be revoked everywhere it matters. Rotation only reduces risk if the old credential cannot be reused and the replacement is not injected as another durable secret. Otherwise, the attack window remains open.
Q: Should IAM teams treat application secrets like machine identities?
A: Yes. Application secrets behave like machine identities because they authenticate systems, not people, and they need lifecycle governance just like any other non-human identity. IAM teams should apply inventory, access scope review, rotation, and offboarding discipline to those secrets instead of leaving them in ad hoc application ownership.
Technical breakdown
How exposed .env files turn into credential exposure
A .env file is a convenience layer for application configuration, but in practice it often becomes a concentration point for secrets. When that file is exposed, attackers or researchers can recover database passwords, API keys, SMTP credentials, and cloud service tokens in one place. The technical failure is not the file format itself but the assumption that a configuration file will remain private by default. In cloud-native environments, those values are effectively non-human identities because they authenticate systems, not people. Once disclosed, they can be replayed, embedded in phishing infrastructure, or used to impersonate legitimate services. Practical implication: treat environment files as secret-bearing assets, not harmless configuration.
Practical implication: inventory every environment file and verify that no credential-bearing file is reachable from public paths, repositories, or shared storage.
Why secret reuse multiplies impact across services
The incident matters because one exposed secret rarely stays isolated. Database credentials, email-sending credentials, and API keys each map to different downstream systems, so a single leak can create multiple abuse paths. That is why secrets governance must account for privilege scope, not just secret presence. If the same credential can access production data, send trusted email, or call external APIs, the blast radius extends well beyond the originating application. This is especially dangerous when secrets are reused across tools or when inactive services are left with valid credentials. Practical implication: model every secret by its reachable services and revoke anything that outlives its business purpose.
Practical implication: map each secret to the exact services it can reach and remove any credential whose scope no longer matches current use.
Why rotation without lifecycle control still leaves residual risk
Rotation is often treated as the answer to secret exposure, but rotation alone does not fix discovery, ownership, or access sprawl. If a secret was copied into logs, chat, code, or third-party tools before rotation, the exposure window still matters. The same is true when inactive services keep old credentials alive or when no owner can confirm whether a secret is still in use. Good secrets governance therefore combines discovery, classification, rotation, and offboarding into one chain. Practical implication: tie every rotation event to ownership and usage checks so that stale credentials do not remain silently valid.
Practical implication: require ownership validation before rotation and decommission credentials that are still valid but no longer in active use.
Threat narrative
Attacker objective: The objective is to reuse exposed service credentials to impersonate legitimate systems and expand access into email, cloud, and application workflows.
- Entry occurred through a publicly reachable .env file that exposed secrets tied to cloud and messaging services.
- Credential access followed when those secrets revealed database, email, API, and marketing-platform credentials in a single location.
- Escalation came from the range of systems those credentials could reach, including email delivery and cloud-connected services.
- Impact included phishing, software-signing abuse, and broader cloud misuse enabled by trusted service credentials.
NHI Mgmt Group analysis
Secrets governance failed because discovery, ownership, and revocation were treated as separate controls. The Neho case is not about a single leaked file so much as a broken lifecycle chain. Once a secret can be discovered in one place, copied into another, and left active after its original purpose changes, the programme no longer has a coherent control boundary. The implication is that secrets management must be governed as one end-to-end identity process, not as a collection of disconnected tasks.
Long-lived secrets create an identity blast radius that most teams still underestimate. Email credentials, API keys, and database passwords all function as machine identities with different levels of downstream trust. When one credential can sign messages, query data, or invoke external platforms, the security outcome is determined by the scope of that secret rather than by the application that stored it. The practitioner conclusion is to treat credential scope as the primary risk variable, not just whether the secret is encrypted at rest.
Exposed NHI secrets are usually a governance problem before they are a detection problem. The article shows that the risky condition existed because secrets were accessible, stale, and poorly contextualised. Monitoring can spot abuse, but it cannot compensate for an inventory that does not tell you which secret is still live, where it is used, and who owns it. The implication is that discovery and lineage are control prerequisites, not optional enhancements.
Ephemeral exposure windows still matter even when teams rotate keys later. The article notes that the file may have held obsolete data and inactive services, but obsolete does not mean harmless if the credentials were valid when exposed. A secret that exists for minutes can still be enough for phishing, spoofing, or service impersonation. The practitioner conclusion is that rotation must be paired with exposure detection and usage validation, or the programme only measures cleanup after the fact.
Secret enrichment is the missing governance layer in many NHI programmes. Knowing that a secret exists is not enough; teams need context such as owner, creation date, last rotation, and privilege scope to decide whether it should remain active. Without that metadata, access review and recertification become guesswork for non-human identities. The implication is that enriched inventory should become the governance baseline for cloud secrets, especially where service credentials outlive the teams that created them.
What this signals
Ephemeral exposure is still real exposure: a secret that is live for only a short period can still enable phishing, service impersonation, or cloud abuse if it is externally reachable. The governance question is not whether rotation eventually happened, but whether discovery and revocation were fast enough to close the trust window before reuse.
NHI programmes need a single control chain for secrets, because a credential is only as safe as its last copy in code, chat, logs, or collaboration tools. The practical shift is from protecting storage locations to governing secret lineage, ownership, and current privilege scope.
For practitioners
- Audit exposed configuration paths Search public web roots, repositories, CI artifacts, and shared storage for credential-bearing files such as .env, then remove any file that contains live secrets.
- Classify each secret by service reach Document whether a credential can access databases, email delivery, cloud APIs, or third-party tools so the team can see the real blast radius of each secret.
- Enforce owner-linked rotation Require a named owner to confirm usage before rotating a secret, then revoke credentials that no longer map to an active service or approved integration.
- Reduce standing privilege in secret-backed services Review whether exposed credentials can perform more than the application needs, and remove excess permissions from mail, API, and database access paths.
Key takeaways
- The Neho incident shows how exposed environment files can turn routine cloud configuration into a multi-service identity problem.
- The real weakness was not only disclosure but the absence of a joined-up lifecycle for discovery, rotation, and access control.
- IAM and NHI teams should govern secrets as live identities with owners, scope, and offboarding rules, not as static configuration values.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets exposed in a public .env file. |
| NHI-07 — Long-Lived Secrets | The article stresses the danger of secrets that remain valid after exposure. | |
| NHI-05 — Overprivileged NHI | The leaked credentials could reach multiple services with broader access than necessary. | |
| Recommendation — Scan exposed paths for leaked secrets and revoke credentials found in public or shared locations. Shorten secret lifetimes and eliminate credentials that remain valid beyond their active business need. Reduce secret permissions to the minimum service scope required for the application. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret rotation and revocation are core authenticator-management concerns. |
| Recommendation — Apply authenticator management controls to rotate, revoke, and track non-human credentials. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The incident involves exposed credentials used for abuse and downstream misuse. |
| Recommendation — Map exposed secret events to credential-access and exfiltration tactics in detection and response workflows. | ||
Key terms
- Secrets Governance: Secrets governance is the discipline of controlling where credentials are stored, who can use them, how long they remain valid, and how they are removed. It links discovery, rotation, offboarding, and auditability so that a secret does not outlive the legitimate need for access.
- Secret lineage: The traceable relationship between a secret and the systems, people, and services that depend on it. Good lineage tells you who owns the credential, where it is used, and what will break if it is revoked. It is the difference between a discoverable leak and a governable incident.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Identity Revocation Window: The short period after an identity change is initiated but before enforcement is complete everywhere. In cloud IAM, this window can allow a compromised principal to keep acting, create replacement credentials, or remove new restrictions before they fully apply.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI governance programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org