Non-Human Identity Security: Protecting Service Accounts, API Keys, and Machine Identities
The identity attack surface enterprises defend most vigorously is the human one: federated SSO, MFA enforcement, conditional access policies, and privileged access management for human administrators. Meanwhile, a parallel identity ecosystem operates with minimal governance: thousands of service accounts, API keys, OAuth client credentials, and workload tokens that authenticate to the same sensitive systems using credentials that have not been rotated in years, that exist in source repositories accessible to anyone with read access, and that carry permissions accumulated through years of ad hoc expansion.
Non-human identities (NHIs) have become the fastest-growing attack surface in enterprise environments not because attackers have become more sophisticated, but because the gap between how well human identities are governed and how poorly machine identities are governed has widened as cloud adoption accelerated. Modern cloud-native architectures generate NHIs at scale: every Lambda function, every Kubernetes pod, every CI/CD pipeline step, every SaaS integration creates one or more machine identities that need access to resources and need credentials to prove that access is authorized.
The SolarWinds breach demonstrated how a compromised build pipeline identity can provide attackers with persistent access across thousands of customer environments. The Okta 2023 breach involved attackers pivoting through a service account to access customer support tooling. These are not isolated incidents but illustrations of a systematic weakness: NHIs are the path of least resistance into environments where human identity controls have matured to the point where direct credential compromise is harder.
What Non-Human Identity Actually Means
Non-human identity encompasses several distinct categories of machine credential that are worth distinguishing because they have different risk profiles and different remediation approaches.
Service accounts in Windows environments are Active Directory accounts created for use by Windows services, scheduled tasks, and applications. They authenticate using passwords or Kerberos tickets, and in many organizations these passwords are set to never expire and are known only in configuration files or the memory of the administrator who created them years ago. Linux service accounts are similar: user accounts created for daemons and applications, often with shell access disabled but with SSH keys or passwords that provide authentication to other systems.
API keys are static credentials issued by SaaS platforms, cloud providers, and internal services that allow programmatic access without interactive authentication. API keys are particularly problematic because they are frequently copied into environment variables, configuration files, CI/CD system settings, and source code repositories, where they proliferate across multiple storage locations and become difficult to revoke cleanly when they need to be rotated.
OAuth client credentials are the client ID and client secret pairs used in the OAuth 2.0 client credentials flow for machine-to-machine authentication. These are conceptually equivalent to API keys but operating within an OAuth authorization framework that provides token expiry and scope restriction that raw API keys often lack.
Cloud workload identities are the native identity mechanisms provided by cloud platforms: AWS IAM roles attached to EC2 instances and Lambda functions, Azure managed identities assigned to virtual machines and app services, GCP service accounts attached to compute resources, and Kubernetes service accounts assigned to pods. These are conceptually superior to API keys because they provide short-lived credentials through instance metadata services rather than requiring static credential storage, but they still carry risk when over-permissioned.
The scale of NHIs in modern environments is significant. CyberArk's 2024 Identity Security Threat Landscape Report found that the average enterprise has approximately 45 non-human identities for every human user. In a 2,000-employee organization, that implies roughly 90,000 machine identities that require governance.
The NHI Attack Surface
The NHI attack surface divides into four categories that require different detection and remediation approaches.
Hardcoded secrets in source code
API keys, service account passwords, database connection strings, and OAuth client secrets embedded directly in source code are the most immediately exploitable NHI risk. GitGuardian's State of Secrets Sprawl 2024 found that approximately 1 in 10 code commits on public GitHub repositories exposes at least one secret. Internal repositories are no safer in practice, since they are accessible to all engineers and frequently synced to developer workstations that are themselves attack targets. Attackers who compromise a developer laptop or gain read access to an internal repository can harvest active credentials without triggering any authentication alerts because the credentials are in a file, not in use.
Long-lived API keys with no expiry
API keys issued by cloud providers, SaaS platforms, and internal services that never expire create an indefinitely growing window of exposure. Every day a credential is not rotated is another day an attacker who compromised it previously can continue using it undetected. Many SaaS platforms issue API keys with no mandatory expiry by default, placing the rotation burden entirely on the customer. Organizations that do not have automated rotation in place for these credentials accumulate exposure over time as credentials proliferate across systems and developers change roles.
Over-privileged service accounts with standing access
Service accounts accumulate permissions through the path of least resistance: when a new integration requires a new permission, adding it to an existing service account is faster than creating a scoped account. The result is service accounts that started as narrow integrations and evolved into broadly privileged identities with access spanning production databases, email systems, cloud management APIs, and internal tooling. An attacker who compromises a service account with this permission profile has a lateral movement capability equivalent to a compromised administrator account, without the monitoring that administrator accounts typically receive.
Orphaned machine identities from decommissioned systems
When a system is retired, its service accounts, API keys, and OAuth credentials frequently outlive it. Application owners are aware of the decommission; the identity team is not always notified. Orphaned credentials that remain active in cloud platforms, Active Directory, and SaaS systems represent standing access with no business justification and no owner who would notice if the credential were used. Attackers who discover orphaned credentials through source code repositories or credential stores have a clean persistence mechanism that generates no authentication alerts because the credential is technically authorized.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Secrets Management: The Foundation
Secrets management platforms provide the foundational control layer for NHIs that rely on secret-based authentication. The core capabilities are centralized storage with encryption at rest, access control that limits which workloads can retrieve which secrets, automatic rotation that changes credentials on a schedule or on demand, and complete audit logging of every secret retrieval.
The dynamic secrets pattern is the most powerful capability that distinguishes mature secrets managers from simple encrypted credential stores. Rather than storing a long-lived database password that all application instances share, Vault (and similar platforms with dynamic secrets support) generates a unique, temporary database credential for each application request with a configurable time-to-live. The credential is valid only for the duration needed, is unique to the requesting workload, and expires automatically. If a credential is exfiltrated, it expires before most attackers can use it at scale. This eliminates the rotation problem for supported secret types because there is nothing to rotate: each use generates a new credential.
The major secrets management platforms differ in deployment model, learning curve, and ecosystem integration. HashiCorp Vault is the most widely deployed open-source secrets manager, offering dynamic secrets for databases, cloud credentials, PKI certificates, and SSH keys through a plugin architecture. Its flexibility comes with operational complexity: Vault requires infrastructure management, high availability configuration, and policy engineering expertise. OpenBao, the CNCF-hosted fork of Vault following HashiCorp's license change, provides the same capabilities under an open-source license for organizations concerned about vendor dependency.
AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager are cloud-native secrets managers that trade Vault's flexibility for operational simplicity within their respective cloud ecosystems. They integrate natively with cloud IAM for access control, require no infrastructure management, and support automatic rotation for cloud-native credential types. Their primary limitation is portability: they are not well suited for multi-cloud environments or on-premises workloads.
CyberArk Conjur is CyberArk's secrets management engine for machine identities, designed as an extension of CyberArk's PAM governance model. Conjur provides dynamic secrets and centralized audit logging with the enterprise support and compliance audit trail that regulated organizations require. It is tightly integrated with CyberArk's broader platform, making it a natural extension for organizations already running CyberArk PAM.
Workload Identity: The Modern Pattern
The ideal NHI security architecture eliminates secrets for workloads that can use attestation-based identity instead. Workload identity frameworks provide cryptographic identity to running workloads based on verifiable platform properties rather than stored credentials, removing the secret storage and rotation problem entirely for supported deployment patterns.
SPIFFE (Secure Production Identity Framework for Everyone) and its reference implementation SPIRE define an open standard for workload identity attestation. SPIRE agents running on each node attest the identity of workloads based on platform-verifiable properties: Linux process attributes, Kubernetes pod identity (verified against the Kubernetes API), AWS EC2 instance identity documents, or similar attestation mechanisms. The agent issues each workload a SPIFFE Verifiable Identity Document (SVID), which is a short-lived X.509 certificate or JWT token cryptographically asserting the workload's identity. SVIDs are rotated automatically by the SPIRE infrastructure before they expire, with no action required by the workload.
Cloud provider workload identity mechanisms achieve similar results within their respective ecosystems. AWS IAM roles for service accounts (IRSA) in Kubernetes allow pods to assume AWS IAM roles through OIDC federation with the Kubernetes API server, receiving temporary AWS credentials through the standard EC2 metadata service interface without any stored credentials. Azure managed identities allow Azure-hosted workloads to authenticate to Azure services using Microsoft Entra ID tokens retrieved from the instance metadata service, with no credentials stored in the application. GCP service accounts attached to Compute Engine instances and Cloud Run services provide the same capability in the GCP ecosystem.
The architectural shift from secret-based to attestation-based workload identity eliminates several attack categories simultaneously: hardcoded secrets have nothing to hardcode, rotation problems have no credentials to rotate, and secret sprawl cannot occur because secrets are never issued. The operational constraint is that attestation-based identity requires the workload to run in an environment that supports the attestation mechanism, which excludes some legacy on-premises deployment patterns and third-party SaaS environments where the workload execution environment is not under the organization's control.
NHI Discovery and Governance
The foundational prerequisite for NHI security is knowing what NHIs exist. Organizations consistently underestimate their NHI count because machine identities are created through many different paths: IT-provisioned service accounts, developer-created OAuth applications, CI/CD system credentials added by engineering teams, and SaaS platform API keys created by business users with admin access to third-party tools. Without systematic discovery, security programs govern only the NHIs they know about while the unknown population accumulates risk.
NHI discovery requires different approaches for different identity types. Active Directory service account discovery can be performed through AD queries that identify accounts with Service Principal Names set, accounts that have not authenticated recently, accounts with passwords set to never expire, and accounts with group memberships providing elevated privileges. Cloud IAM discovery involves querying each cloud provider's IAM APIs to inventory all service accounts, roles, and access keys, then cross-referencing with resource access logs to identify credentials that have not been used recently.
Secrets in source code require dedicated scanning tools. GitGuardian and Trufflehog are the most widely deployed open-source and commercial tools for detecting secrets committed to source repositories. GitHub's native secret scanning (available on GitHub Advanced Security) provides continuous scanning of repositories as code is pushed. These tools identify API keys, OAuth tokens, database connection strings, private keys, and other credential patterns across commit history, not just in the current state of each file.
SaaS-connected OAuth application discovery is a growing requirement as organizations accumulate dozens of third-party applications with OAuth grants to corporate Google Workspace, Microsoft 365, or Salesforce environments. Tools like Nudge Security, Grip Security, and similar SaaS security platforms discover OAuth application connections through identity provider logs and API queries, identifying what third-party applications have access to corporate identity systems and what permissions those connections carry.
The governance workflow after discovery follows a consistent pattern: classify each discovered NHI by sensitivity based on what resources it can access, identify or assign an owner responsible for the NHI, enforce a rotation or expiry policy appropriate to the credential type, and configure monitoring for anomalous usage patterns that might indicate the credential has been compromised.
Entro Security
Purpose-built NHI discovery and governance platform that connects to cloud providers, secrets managers, source repositories, and SaaS platforms to build a unified inventory of all machine identities and secrets across the environment. Provides risk scoring, owner attribution workflows, and rotation policy enforcement.
Silverfort
Provides service account discovery and MFA enforcement for Active Directory and cloud environments. Silverfort's unique capability is applying MFA or conditional access policies to service accounts and legacy systems that cannot support standard MFA through a protocol-level proxy, without requiring changes to the services themselves.
GitGuardian
Developer security platform focused on secrets detection in source code repositories. GitGuardian monitors commits across public and private repositories for credential patterns, integrates with CI/CD pipelines to block secrets from being merged, and provides incident management workflows for remediating secrets that have already been exposed.
Trufflehog
Open-source secret scanning tool from Truffle Security that searches git history and current repository state for credential patterns across hundreds of secret types. Available as a standalone CLI tool, GitHub Action, and CI/CD integration. Trufflehog verifies discovered secrets against the respective service APIs to distinguish live credentials from expired or already-revoked secrets.
Vendor Landscape for NHI Security
The NHI security vendor landscape spans four distinct categories that address different layers of the problem, and most mature NHI programs use tools from multiple categories rather than relying on a single platform.
HashiCorp Vault and OpenBao
Open-source secrets management with maximum flexibility. Vault supports dynamic secrets for databases, cloud credentials, PKI, and SSH, with a plugin architecture that extends to additional secret types. OpenBao is the CNCF-hosted open-source fork that preserves the Vault API while removing licensing constraints. Best suited to engineering-led organizations with the operational maturity to manage Vault infrastructure and develop integration policies. The learning curve and operational overhead are the primary barriers for organizations without dedicated identity engineering resources.
CyberArk Secrets Manager and Conjur
Enterprise PAM extension to machine identities with strong governance and audit capabilities. CyberArk Conjur provides secrets management for CI/CD pipelines and cloud workloads within the CyberArk governance model, with comprehensive audit logging and integration with CyberArk's broader PAM workflows. Best suited to organizations already running CyberArk PAM that want to extend governance to machine identities without a second vendor relationship. Higher total cost than open-source alternatives but includes enterprise support and compliance audit depth.
Cloud-Native Secrets Managers (AWS, Azure, GCP)
AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager provide operational simplicity within their respective cloud ecosystems at the cost of portability. Each integrates natively with the cloud provider's IAM for access control, supports automatic rotation for cloud-native credential types, and requires no infrastructure management. Best suited to organizations with a primary cloud and limited multi-cloud requirements. Combined cost across all three providers for a multi-cloud deployment can exceed Vault at scale.
Entro and Astrix (NHI Governance Layer)
Entro Security and Astrix Security (now part of CrowdStrike) provide NHI discovery, classification, and governance capabilities that sit above the secrets management layer. Rather than managing secrets themselves, these platforms build a comprehensive inventory of all NHIs across secrets managers, cloud providers, SaaS platforms, and source repositories, then provide risk scoring, owner attribution, and anomalous usage detection. Best suited as a governance and visibility layer in organizations that have already deployed one or more secrets management platforms but lack unified visibility.
Venafi
Machine identity management with a specific focus on certificate and cryptographic identity at enterprise scale. Venafi's Control Plane manages the lifecycle of TLS/SSL certificates, code signing certificates, SSH keys, and machine identities across hybrid and multi-cloud environments. Best suited to large enterprises with significant PKI infrastructure, certificate sprawl problems, or regulatory requirements for certificate lifecycle management. Venafi's scope is deliberately broader than secrets management, covering all cryptographic machine identities rather than application credentials specifically.
The bottom line
Non-human identity security is not a future problem. Organizations running cloud-native workloads, CI/CD pipelines, and SaaS integrations already have NHI populations that vastly outnumber their human user accounts and that are governed with a fraction of the rigor applied to human identities. The consequence is a systematic attack surface that sophisticated threat actors exploit routinely, as demonstrated in the SolarWinds build pipeline compromise and the Okta service account pivot.
The remediation sequence follows a logical order: discovery before governance, governance before remediation, and secrets elimination (through workload identity) before secrets management. Organizations that skip discovery and attempt to manage NHIs they have not yet inventoried will secure a small fraction of their attack surface while the ungoverned majority persists. Starting with a comprehensive NHI discovery project, prioritizing remediation by privilege level and credential age, and progressively replacing long-lived secrets with workload identity attestation for cloud workloads is the path from an ungoverned NHI population to a defensible machine identity program.
Frequently asked questions
What is the difference between a service account and a human user account from a security perspective?
A service account is a digital identity created to be used by an application, script, or automated process rather than by a human. From a security perspective, service accounts differ from human accounts in several important ways that increase their risk profile. Human accounts are typically subject to MFA enforcement, password complexity requirements, regular recertification reviews, and behavioral monitoring for anomalous login patterns. Service accounts are frequently excluded from MFA requirements because the services using them cannot complete an interactive authentication challenge. They often use static, long-lived credentials because the services that hold them cannot participate in modern rotation workflows without application changes. Service accounts also tend to accumulate permissions over time. When a new integration requires access to a resource, the path of least resistance is often to add permissions to an existing service account rather than create a new, scoped identity. Over months and years, this produces service accounts with permissions far exceeding any individual workflow they support. The result is that a compromised service account credential frequently grants broader access than a compromised human account, with less monitoring in place to detect that the credential has been stolen and is being used by an unauthorized party. This combination of over-privilege, weak credential hygiene, and limited monitoring makes service accounts a high-value target for attackers who have established initial access and are looking to escalate and move laterally.
How do non-human identities differ from secrets management?
Non-human identity (NHI) is the broader category: any identity used by a system rather than a human, including service accounts, API keys, OAuth client credentials, certificates, and workload identities. Secrets management is the specific practice of securely storing, distributing, rotating, and auditing the credentials and sensitive configuration values that NHIs use to authenticate. The relationship is that secrets management is one of the primary security controls for NHIs that rely on secret-based authentication. If a service account authenticates using a password or a fixed API key, a secrets manager provides a secure place to store that credential, automates its rotation, controls which services can retrieve it, and logs every retrieval for audit purposes. Secrets management does not address NHIs that use certificate-based or attestation-based identity rather than secrets. Workload identity frameworks like SPIFFE/SPIRE, AWS IAM roles for service accounts (IRSA), and Azure managed identities provide identity to workloads through short-lived attestation rather than stored secrets. These NHIs do not benefit directly from secrets management because they do not use stored credentials; instead, they receive temporary credentials at runtime based on their attested identity. A complete NHI security program addresses both: secrets management for NHIs that must use secrets, and workload identity frameworks to eliminate secrets where possible by replacing them with attestation-based credentials.
What is SPIFFE and why does it matter for workload identity?
SPIFFE (Secure Production Identity Framework for Everyone) is an open standard for workload identity that provides a vendor-neutral way for services to prove their identity to other services without using shared secrets. SPIFFE defines a standard identity document called an SVID (SPIFFE Verifiable Identity Document), which is a short-lived X.509 certificate or JWT token that cryptographically asserts the identity of a workload. SPIRE (SPIFFE Runtime Environment) is the reference implementation of SPIFFE that automates SVID issuance and rotation. SPIRE agents run on each node and attest workload identity based on verifiable platform properties: process attributes, Kubernetes pod identity, AWS instance identity documents, or similar platform-specific attestation mechanisms. Because SVID certificates are short-lived (typically valid for hours rather than years) and automatically rotated, the credential exposure window from any individual stolen SVID is minimal. SPIFFE/SPIRE matters for workload identity because it replaces the dominant pattern of shared API keys and long-lived service account tokens with cryptographic identity attestation. Two services that both have SPIFFE identities can establish mutual TLS connections where each party proves its identity cryptographically, without any shared secret that could be stolen from a configuration file or environment variable. This eliminates the entire attack surface of hardcoded credentials for service-to-service communication in environments that adopt SPIFFE.
How does CyberArk's approach to NHI differ from HashiCorp Vault?
CyberArk and HashiCorp Vault approach non-human identity security from different starting points that reflect their original design intent. HashiCorp Vault (and its open-source fork OpenBao) is a secrets management engine designed to be the central store for all sensitive configuration values across an organization's infrastructure. Vault's strengths are dynamic secret generation (creating temporary database credentials, cloud credentials, and PKI certificates on demand for specific workloads), flexible authentication method support (allowing services to authenticate using AWS IAM, Kubernetes service accounts, OIDC tokens, or AppRole credentials), and an open plugin architecture that supports a broad range of secret backends. Vault is engineering-heavy to operate: it requires infrastructure management, policy definition, and integration work that demands identity engineering expertise. CyberArk approaches NHI security as an extension of its PAM (Privileged Access Management) platform. CyberArk Conjur is CyberArk's secrets management engine for machine identities, and it integrates tightly with CyberArk's broader vault infrastructure, session recording, and privileged access workflow capabilities. CyberArk's NHI approach emphasizes the governance and audit capabilities that complement its PAM controls: comprehensive audit logs, integration with PAM workflows for approving high-risk machine identity access, and enterprise support that appeals to compliance-driven security programs. In practice, Vault is the more common choice for cloud-native and DevOps-oriented organizations that want maximum flexibility and are willing to invest engineering effort. CyberArk Conjur is the more common choice for organizations already standardized on CyberArk PAM that want to extend their existing governance model to machine identities without adding a separate vendor.
What happened in the GitHub Actions supply chain attacks and how did NHI play a role?
GitHub Actions CI/CD pipelines have been the subject of multiple supply chain attacks in which attackers targeted NHIs, specifically the repository secrets, workflow tokens, and third-party Action credentials that pipelines use to authenticate to external systems during build and deployment processes. The most instructive example is the compromise of the Codecov bash uploader in 2021, in which attackers gained access to Codecov's build environment and modified the uploader script to exfiltrate environment variables (including CI/CD secrets) from any pipeline that used the script. Because CI/CD pipelines routinely inject credentials into the environment for build steps (AWS access keys, container registry credentials, deployment tokens), the compromised script harvested active credentials from hundreds of organizations before the attack was discovered. A separate pattern involves the reuse and overpermissioning of the GITHUB_TOKEN, the automatic credential generated for each GitHub Actions workflow run. Workflows that use overly broad GITHUB_TOKEN permissions allow a compromised or malicious workflow step to push code, modify releases, or access other repository resources. The GitHub Actions permission model allows workflow authors to request only the permissions their workflow actually needs, but default settings in many organizations grant broader permissions than necessary. These attacks illustrate the core NHI risk in CI/CD environments: pipelines accumulate credentials that provide access to production systems, those credentials are often stored without rotation or tight scope, and the supply chain of third-party Actions introduces code that executes in the context of those credentials without the same scrutiny applied to first-party code.
How should organizations prioritize NHI remediation when they discover thousands of service accounts?
Discovering thousands of service accounts is a common finding when organizations conduct their first NHI inventory, and the volume typically makes comprehensive remediation impractical in a single project cycle. Effective prioritization follows a risk-based framework that focuses remediation effort on the service accounts with the highest potential impact if compromised. The first prioritization dimension is privilege level. Service accounts with domain admin rights, administrative rights on cloud management planes, or access to credential stores create the highest impact if compromised. These should be addressed first, regardless of how many lower-privilege accounts also need attention. The second dimension is authentication credential type. Service accounts using passwords that have never been rotated (common in legacy Windows environments where passwords are set to never expire) and API keys embedded in source code or configuration files represent immediate remediation targets because the credential may already be compromised. The third dimension is orphaned accounts. Service accounts with no recent authentication activity (typically no logins in 90 or more days) and no identified application owner represent both a security risk and an opportunity for quick wins: many can be disabled or deleted without operational impact, immediately reducing the attack surface without requiring coordination with application teams. The fourth dimension is accounts with anomalous access patterns relative to their expected behavior. Service accounts that have recently accessed systems or made API calls outside their historical pattern may indicate active exploitation rather than misconfiguration, and should be treated as potential incident indicators rather than routine remediation items.
What compliance frameworks are beginning to address non-human identity requirements?
NHI governance is increasingly appearing in compliance frameworks as a specific control requirement, reflecting the recognition that traditional human identity governance controls do not adequately address machine identity risks. PCI DSS v4.0, effective for full compliance by March 2025, strengthened requirements for service account management under Requirement 8.6, which now explicitly covers system and application accounts. Organizations must document all system accounts, define their purpose and access scope, implement strict access control based on least privilege, and change authentication credentials periodically or upon evidence of compromise. NIST SP 800-207 (Zero Trust Architecture) identifies service accounts as a category of non-person entities (NPEs) that require authentication and authorization controls equivalent to those applied to human identities. The NIST Cybersecurity Framework 2.0 expanded its identity governance guidance to more explicitly address non-human identities in the Identify and Protect function categories. CISA's Secure by Design principles and the Office of the National Cyber Director's National Cybersecurity Strategy implementation have both identified machine identity management as a priority area, with specific guidance on eliminating default credentials and hardcoded secrets in software products. For organizations under SOC 2, the Common Criteria related to logical access controls (CC6.1 through CC6.3) are increasingly interpreted by auditors to require documented service account inventories, access scope justification, and evidence of rotation controls for machine credentials.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.