A certificate stored in software rather than protected by a hardware-backed mechanism such as a smart card. It can be easier to deploy but often creates more risk because it is simpler to copy, misplace, or leave active outside its intended lifecycle.
Expanded Definition
A soft certificate is a digital certificate stored in software, such as on a filesystem, in an application store, or inside a secrets repository, rather than anchored to a hardware-backed trust boundary. In NHI and machine identity programs, the practical concern is not the certificate format alone but the way private keys, issuance paths, and renewal rules are handled around it.
Definitions vary across vendors when they describe adjacent terms such as software certificate, file-based certificate, or exportable certificate. NHI Management Group treats soft certificates as a risk posture, not a certificate type: if the credential can be copied, backed up, or moved without a hardware control, it should be governed as a soft certificate. That distinction matters because the same certificate can be acceptable in one workflow and dangerous in another depending on where the private key lives and how it is protected. For broader identity context, see the NIST Cybersecurity Framework 2.0 and NIST’s identity guidance.
The most common misapplication is treating any certificate stored in software as low risk, which occurs when teams equate convenience with adequate lifecycle control.
Examples and Use Cases
Implementing soft certificates rigorously often introduces key-handling and rotation overhead, requiring organisations to weigh deployment speed against exposure if the host or repository is compromised.
- A CI/CD pipeline writes a client certificate and private key to disk for automated service-to-service authentication, then fails to remove the file after deployment.
- An application uses a file-based certificate for outbound TLS, but the private key is also copied into backup images and disaster recovery tooling.
- A contractor receives a software-stored certificate for temporary access, but there is no synchronized offboarding step when the engagement ends, a pattern that aligns with issues highlighted in the Ultimate Guide to NHIs — What are Non-Human Identities.
- An ops team rotates certificates manually and validates them only during outages, rather than using lifecycle automation or inventory controls recommended by NIST Cybersecurity Framework 2.0.
- A legacy service stores a certificate in software because no hardware module is available, making compensating controls such as strict filesystem permissions and monitoring essential.
In NHI operations, soft certificates are often accepted as a transitional control when hardware-backed options are unavailable, but they should be paired with strong ownership, rotation, and revocation processes.
Why It Matters in NHI Security
Soft certificates matter because they can become durable, copyable machine credentials with a much wider blast radius than teams expect. Once a certificate and its private key are stored in software, compromise of the host, repository, backup, or CI/CD path can expose an entire trust relationship. That is why machine identity failures frequently translate into outages and incidents: NHI Management Group research shows that 53% of organisations have experienced a security incident directly related to machine identity management failures, and 45% report certificate expiry as the leading cause of outages in the SailPoint Critical Gaps in Machine Identity Management report.
Soft certificates also create governance problems when ownership is unclear, when inventory is incomplete, or when renewal is manual. Those conditions are common across machine identity programs, especially where certificates are embedded in code, config files, or orchestration systems. For NHI security teams, the key issue is not whether a certificate is “soft” in the abstract, but whether it can be tracked, rotated, and revoked before it outlives its intended use. The Sisense breach illustrates how exposed credentials can turn a routine identity asset into a breach amplifier. Organisations typically encounter the full operational cost of soft certificates only after an expired, copied, or forgotten certificate causes an outage or unauthorised access, at which point the term 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Soft certificates increase secret exposure and lifecycle risk for machine identities. |
| NIST CSF 2.0 | PR.AC-1 | Certificate-based access depends on controlled identity issuance and authentication. |
| NIST SP 800-63 | Digital identity guidance informs assurance and authenticator handling for certificates. | |
| NIST Zero Trust (SP 800-207) | Zero trust relies on continuously verified machine identities, including certificate use. | |
| OWASP Agentic AI Top 10 | Agentic systems often rely on software-stored certificates for tool and service access. |
Treat certificate issuance and use as access control assets with explicit ownership and review.
Related resources from NHI Mgmt Group
- How should teams manage shrinking certificate lifecycles in NHI environments?
- What is the difference between certificate management and NHI governance?
- Should organisations treat certificate expiry as an operational risk or a security risk?
- How should security teams govern certificate lifecycles across hybrid environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
