The CISA Known Exploited Vulnerabilities Catalog lists flaws that are already being used in real attacks. For practitioners, inclusion signals that patching has moved from routine hygiene to urgent remediation because exploitation is no longer hypothetical.
Expanded Definition
The CISA Known Exploited Vulnerabilities Catalog is a curated list of software flaws that CISA has confirmed are being actively exploited in the wild. In NHI operations, the catalog matters because exploited vulnerabilities often become the entry point for service account theft, token replay, lateral movement, or secret extraction rather than just endpoint compromise. As a public prioritisation signal, it is broader than a vendor patch bulletin and narrower than a full threat-intelligence feed. It tells defenders which weaknesses have crossed from theoretical exposure to demonstrated abuse, so remediation can be driven by exploitation evidence rather than severity scores alone. That distinction aligns closely with guidance from CISA cyber threat advisories and the operational lessons captured in Ultimate Guide to NHIs. Definitions vary across vendors when they try to extend the catalog into generic risk scoring, but no single standard governs that yet. The most common misapplication is treating catalog inclusion as a compliance checkbox, which occurs when teams patch only internet-facing systems and ignore embedded secrets, service account dependencies, and downstream automation.
Examples and Use Cases
Implementing catalog-driven remediation rigorously often introduces scheduling and change-control friction, requiring organisations to weigh fast containment against application uptime and deployment risk.
- A platform team uses the catalog to prioritise an externally exposed API server that hosts workload credentials, then accelerates patching before attackers can harvest tokens.
- A security operations group maps catalog items to 52 NHI Breaches Analysis findings to identify patterns where exploited software led to compromised service accounts.
- An identity engineering team checks whether a vulnerable secret management component could expose API keys stored in CI/CD pipelines, then rotates credentials after remediation.
- A cloud operations team uses CISA cyber threat advisories to coordinate patch windows for a fleet of automation hosts running privileged agents.
- A governance team treats catalog entries as a trigger for cross-functional review when a flaw affects systems that mint, store, or validate machine credentials.
Why It Matters in NHI Security
The catalog is important because exploited vulnerabilities are frequently the opening move in attacks against non-human identities, especially where secrets are hard-coded, poorly vaulted, or left unrotated. NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which shows why patch prioritisation cannot stop at classic endpoint hygiene. When a flaw is already weaponised, every exposed automation path becomes more urgent: secret stores, CI/CD runners, orchestrators, privileged APIs, and integration layers all need review. This is particularly relevant because 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs. In practice, the catalog helps security leaders connect vulnerability management to identity containment and revocation decisions, not just patch deadlines. Organisations typically encounter the real cost only after an exploited flaw has already been used to access a service account, at which point the catalog becomes operationally 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 and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.1 | Prioritisation of known exploited flaws supports governance-led risk decisions. |
| NIST AI RMF | GOV-5 | Operational risk treatment should respond to confirmed exploitation evidence. |
| NIST Zero Trust (SP 800-207) | PL-1 | Zero trust planning assumes vulnerabilities can be weaponised against identity paths. |
| OWASP Non-Human Identity Top 10 | NHI-07 | Exploited software often exposes secrets, service accounts, or NHI control paths. |
Escalate remediation when a flaw is confirmed exploited, especially where AI or automation depends on it.
Related resources from NHI Mgmt Group
- When should organisations prioritise remediation of known exploited vulnerabilities over routine patch work?
- 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?
- Who is accountable when identity-service vulnerabilities are exploited in hybrid environments?
