A known weakness is a security issue attackers can readily identify and exploit, such as an exposed service, missing authentication, or a published vulnerability. These are often easier and cheaper to attack than novel flaws because exploit techniques, tooling, or proof of concept methods already exist.
Expanded Definition
A known weakness is a security condition that is already documented, observable, or broadly understood by attackers, making it easier to target than an undisclosed flaw. In NHI environments, that can include exposed service accounts, hardcoded credentials, missing authentication on an agent endpoint, weak token handling, or a published vulnerability in a dependency used by an AI agent or automation workflow.
Definitions vary across vendors on whether a known weakness must be publicly disclosed, internally discovered, or simply repeatable in practice. NHI Management Group treats the term operationally: if a weakness can be identified by scanning, enumeration, leaked documentation, or common exploit tooling, it belongs in the known-weakness category and should be prioritised for remediation. This is closely related to exposure management and differs from a theoretical design flaw because the attacker already has a practical path to exploitation. Guidance in the NIST Cybersecurity Framework 2.0 maps well to this reality because identification, protection, and recovery all depend on reducing obvious attack paths.
The most common misapplication is treating only CVEs as known weaknesses, which occurs when teams ignore exposed secrets, overprivileged identities, and misconfigured automation that attackers can exploit just as readily.
Examples and Use Cases
Implementing known-weakness management rigorously often introduces more review, scanning, and change-control overhead, requiring organisations to weigh faster delivery against reduced exposure.
- An AI agent with an unauthenticated tool endpoint can be enumerated and abused immediately, even if the underlying model is sound.
- A service account with long-lived credentials stored in source code creates a known weakness that adversaries can harvest from repositories or build logs. The Ultimate Guide to NHIs documents how often secrets are left outside secure vaults and why that matters.
- A published library vulnerability in a chatbot orchestration stack becomes a known weakness as soon as the exploit path is public and reproducible.
- An exposed cloud metadata or token endpoint gives attackers a repeatable route to credential theft, privilege escalation, or lateral movement.
- A misconfigured vault or CI/CD secret store can turn an ordinary deployment issue into an immediately exploitable condition, especially when tooling already exists to enumerate it.
For broader identity and risk framing, the NIST Cybersecurity Framework 2.0 is useful because it treats known exposure as a lifecycle problem, not a one-time finding.
Why It Matters in NHI Security
Known weaknesses are especially dangerous in NHI security because non-human identities are machine-scaled, persistent, and often overconnected to tools, pipelines, and APIs. Once one weakness is exposed, attackers can move quickly from discovery to exploitation without having to invent a new technique. That is why NHI Management Group reports that Ultimate Guide to NHIs found 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage. The practical lesson is that visibility and rotation alone are not enough if obvious weaknesses remain in place.
Known weaknesses also undermine Zero Trust efforts because they create paths that bypass policy intent. A leaked token, exposed service account, or unauthenticated agent action can nullify segmentation and least-privilege controls in one step. The NIST Cybersecurity Framework 2.0 reinforces the need to identify, protect, detect, respond, and recover around these issues, not merely catalogue them.
Organisations typically encounter the operational cost of known weaknesses only after a breach, when remediation, credential rotation, and incident response become unavoidable to address.
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 address the attack surface, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Known weaknesses often arise from exposed identities, secrets, and misconfigurations covered by NHI risk controls. |
| NIST CSF 2.0 | ID.RA-1 | The framework requires identifying and analysing known threats and vulnerabilities across the environment. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on eliminating obvious trust-bypass paths created by known weaknesses. | |
| NIST SP 800-63 | Credential strength and lifecycle issues become known weaknesses when authentication is weak or reusable. | |
| NIS2 | NIS2 drives risk treatment and incident resilience for exploitable vulnerabilities and exposed services. |
Continuously identify known weaknesses and prioritise remediation by attackability and impact.
Related resources from NHI Mgmt Group
- What should organisations do when a VPN bypass exposes the weakness of edge-based trust?
- Who is accountable when a known exploited Office vulnerability remains unpatched?
- How should security teams reduce breach risk when known vulnerabilities and credential abuse remain the main entry paths?
- When does a control failure become a material weakness?
