A write-only attribute is a value OpenTofu can send during creation or update without retaining it for later reads. It helps prevent one-time secrets, such as initial passwords, from being written into state. The control is useful, but only when the provider implements it correctly.
Expanded Definition
In OpenTofu, a write-only attribute is designed for values that must be submitted to a provider during creation or update but should not be retained in state for later reads. This pattern is most relevant for one-time secrets, such as bootstrap passwords, temporary enrollment tokens, or initial API credentials, where persistence would create unnecessary exposure.
The concept matters because state is often the most sensitive artifact in an infrastructure workflow. A properly implemented write-only attribute reduces the chance that a secret will be copied into local files, remote state backends, plan output, or downstream tooling. That said, the control is only as strong as provider behavior and surrounding workflow hygiene. OpenTofu is the runtime mechanism, but the security outcome depends on whether the provider truly treats the value as non-readable and whether operators prevent accidental duplication elsewhere. For identity and secret handling, this aligns with the broader control logic described in the NIST Cybersecurity Framework 2.0, especially where data protection and access restriction intersect.
The most common misapplication is assuming a write-only attribute eliminates secret exposure everywhere, which occurs when the same value is echoed into variables, logs, or external secret stores outside the provider path.
Examples and Use Cases
Implementing write-only attributes rigorously often introduces debugging and reconciliation constraints, requiring organisations to weigh reduced secret exposure against reduced visibility into what was sent to the provider.
- Supplying an initial password for a newly created service account so the provider can provision the account without storing that password in state.
- Sending a short-lived enrollment token during bootstrap, then immediately replacing it with a managed secret after first use.
- Passing a one-time certificate enrollment secret to an automation workflow where later reads are unnecessary and would only broaden exposure.
- Using a temporary bootstrap credential while delegating long-term access to a separate secrets workflow governed outside of OpenTofu.
These use cases are strongest when paired with secret lifecycle controls, because write-only handling is not a substitute for rotation, offboarding, or visibility. NHI Management Group notes in the Ultimate Guide to NHIs that 79% of organisations have experienced secrets leaks, which makes one-time secret handling a practical risk-reduction measure rather than a theoretical convenience. In standards terms, the pattern complements NIST Cybersecurity Framework 2.0 guidance around limiting unnecessary data retention.
Why It Matters in NHI Security
Write-only attributes matter because NHI compromise often begins with secret persistence, not with sophisticated exploitation. If a bootstrap credential survives in state, logs, or pipeline outputs, it becomes part of the attack surface long after its intended use. This is especially relevant in service account provisioning, API onboarding, and agentic workflow initialization, where a single leaked value can unlock downstream systems with machine speed.
NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means the surrounding environment often undermines even a correctly designed write-only control. The risk is not just disclosure, but drift between intended secret lifespan and actual retention across infrastructure layers. Where provider implementations are inconsistent, security teams should treat the attribute as a containment aid, not a guarantee.
Organisations typically encounter the consequences only after a secret is recovered from state, at which point write-only handling 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 Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Write-only secret handling reduces retained secret exposure in state and logs. |
| NIST CSF 2.0 | PR.DS | This term supports data security by limiting unnecessary retention of secret values. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust limits exposure by minimizing trust in stored credential material. |
| NIST SP 800-63 | AAL2 | Initial secret handling affects authenticator strength and lifecycle assurance. |
| OWASP Agentic AI Top 10 | LLM-03 | Agent workflows can leak bootstrap secrets through prompts, logs, or tool calls. |
Treat write-only attributes as a containment measure and verify secrets are not reusable from state.
Related resources from NHI Mgmt Group
- How should security teams govern AI tools that write into workspace settings?
- How do security teams decide whether HRIS write-back is safe in joiner automation?
- What breaks when a document parser can write files outside its temp directory?
- How should security teams write an access onboarding and termination policy?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
