Secure by default means the safest configuration and workflow is the one the system encourages by design. For identity products, that usually means least privilege, auditability, and revocation paths are built into the normal user journey instead of being added as manual exceptions later.
Expanded Definition
Secure by default is the design principle that the safest usable state is the starting state, not a hardening step reserved for security teams. In NHI and agentic AI systems, this means privileges begin narrow, secrets are protected from the first deployment, audit trails are enabled automatically, and revocation or rotation paths are part of normal operations rather than emergency procedures.
Definitions vary across vendors when this phrase is used to describe onboarding, policy enforcement, or product configuration. In NHI governance, the concept is broader than “secure settings” because it also includes lifecycle controls such as issuance, rotation, delegation, and offboarding. A system can look locked down while still failing secure by default if it forces operators to grant broad permissions, store secrets manually, or disable logging to make workflows function. The standard-setting lens in NIST Cybersecurity Framework 2.0 aligns with this expectation by treating protective controls as part of ordinary system design, not optional add-ons. NHIMG’s guidance on the Ultimate Guide to NHIs reinforces that safe defaults matter because NHI sprawl and privilege creep are operational realities, not edge cases.
The most common misapplication is assuming a product is secure by default simply because it ships with authentication enabled, which occurs when the surrounding workflow still permits over-privileged access, weak secret handling, or disabled auditability.
Examples and Use Cases
Implementing secure by default rigorously often introduces friction for operators, requiring organisations to weigh faster initial deployment against stronger controls that reduce long-term remediation.
- A cloud service account is created with read-only access and time-bound elevation only after explicit approval, so the first usable state is also the least risky state.
- An API credential is issued into a managed vault with rotation enabled automatically, rather than being exposed in code or passed through a ticketing workflow.
- An agentic workflow logs tool calls, token use, and policy decisions by default, creating a defensible audit trail without requiring manual toggles after go-live.
- A platform uses fail-closed authorization for NHI actions, so if policy is missing or validation fails, the agent cannot continue with broad access. This design pattern is consistent with the identity-first guidance in the Ultimate Guide to NHIs.
- Default onboarding templates for service identities apply least privilege from the start, reflecting the access model recommended in NIST Cybersecurity Framework 2.0 rather than retrofitting controls later.
These examples are strongest when the default path also covers revocation, because secure issuance without secure removal still leaves lasting exposure.
Why It Matters in NHI Security
Secure by default matters in NHI security because failure often happens before a security team even reviews the system. NHIs scale faster than human governance processes, and NHIMG reports that NHIs outnumber human identities by 25x to 50x in modern enterprises, while 97% carry excessive privileges. When the default design encourages broad access, manual secret handling, or delayed rotation, the environment quickly accumulates hidden risk. That is why the Ultimate Guide to NHIs is so focused on lifecycle visibility, rotation, and offboarding as core controls rather than optional maturity items.
The security consequence is not just a weaker baseline, but a system that normalises exceptions. Once exceptions become the usual operating mode, audit evidence becomes incomplete, incident response slows, and least privilege turns into a manual campaign instead of an architectural property. Secure by default also supports zero trust because it reduces the number of identities that can act without explicit context, which is essential when service accounts, API keys, and agents are frequent breach paths.
Organisations typically encounter the cost of non-default security only after a secrets leak, an over-permissioned agent action, or a failed offboarding event, at which point secure by default 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 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 | Covers weak secret handling and default exposure of NHI credentials. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access governance are core to secure-by-default design. |
| NIST Zero Trust (SP 800-207) | Zero trust expects explicit verification and minimal standing access by design. |
Set default entitlements to least privilege and require explicit elevation for higher access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
