The Secure by Design Pledge is a voluntary commitment by software providers to work toward defined security goals over a set period. It is a governance signal, not a certification. The pledge focuses on practices such as secure development, disclosure, inventory, access control, encryption, and incident response.
Expanded Definition
The secure by design Pledge is a voluntary governance commitment that asks software providers to improve security outcomes over a defined period. It signals intent and accountability, but it is not a certification, a compliance badge, or proof that a product is secure. In NHI and agentic AI environments, the pledge matters because the software supply chain often includes service accounts, API keys, tokens, and automated workflows that can be weakened by insecure defaults, weak inventory discipline, or poor access control.
Definitions vary across vendors and policy programs, but the practical interpretation is consistent: the pledge should drive measurable security work, not marketing claims. It overlaps with established control ideas in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access control, auditability, configuration management, and incident response. It also aligns with the intent of the EU Cyber Resilience Act, which pushes security responsibility earlier in the product lifecycle.
The most common misapplication is treating the pledge as evidence of assurance, which occurs when procurement or security teams accept the statement without testing the provider’s actual controls and remediation discipline.
Examples and Use Cases
Implementing a Secure by Design Pledge rigorously often introduces delivery overhead, requiring organisations to weigh faster product shipping against stronger security engineering, documentation, and review discipline.
- A SaaS provider publishes a pledge and then backs it with secure defaults for API authentication, reducing the chance that newly deployed NHI credentials are exposed through weak configuration.
- A platform team ties the pledge to a published vulnerability disclosure process and tracks remediation time, which makes the commitment auditable instead of purely promotional.
- An identity or secrets product team uses the pledge to justify mandatory inventory of service accounts and tokens, a critical step given the visibility gaps described in the Ultimate Guide to NHIs.
- A developer tool vendor commits to encryption, key rotation, and access logging for automated agents, then validates those practices against guidance in the NIST control catalog.
- An enterprise security team uses the pledge as a procurement question: what changed in the product, what deadlines apply, and how will the provider prove progress over time?
For NHI-heavy environments, the pledge becomes meaningful only when it results in fewer standing secrets, tighter scope on automation permissions, and faster response to compromise indicators, all of which are recurring themes in the Ultimate Guide to NHIs.
Why It Matters in NHI Security
A Secure by Design Pledge matters because NHIs expand the blast radius of weak engineering decisions. When software is built without secure defaults, inventory discipline, or robust access control, service accounts and API keys often become the easiest path to lateral movement. NHI Mgmt Group data shows that 97% of NHIs carry excessive privileges, and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage.
That is why the pledge should be read as a governance signal for future risk reduction, not as an assurance that today’s environment is safe. It becomes especially important when third-party tools, CI/CD systems, and machine-to-machine integrations rely on persistent credentials that are hard to inventory and hard to revoke. The operational question is whether the provider is changing product behavior, not merely updating policy language.
Organisations typically encounter the consequences only after a secrets leak, token abuse, or service account compromise, at which point the pledge 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 surface, NIST CSF 2.0 and NIST AI RMF set the technical controls, and EU Cyber Resilience Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Secure by design depends on reducing risky defaults and exposed non-human identities. |
| NIST CSF 2.0 | GV.RM | A pledge is a governance commitment that should be tracked as risk management, not certification. |
| NIST AI RMF | Secure by design should reduce AI system risk through lifecycle accountability and controls. | |
| EU Cyber Resilience Act | The CRA pushes security responsibility into product design and development lifecycle practices. |
Use the pledge to drive lifecycle controls, monitoring, and documented risk treatment for AI-enabled systems.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
