A non-final software build used for testing before general release, often marked as alpha, beta, or release candidate. In identity infrastructure, pre release builds support staged validation, but they should be treated as controlled testing artifacts rather than production baselines because behaviour can still change.
Expanded Definition
A pre release build is a controlled, non-final software artifact used to validate functionality, security, and operational readiness before general availability. In NHI and identity infrastructure, the term applies not only to application code but also to agents, connectors, secret-handling components, and deployment pipelines that may behave differently from the production release. The practical distinction is that a pre release build is intentionally incomplete or still subject to change, so it should be assessed as a testing input rather than a stable baseline.
Definitions vary across vendors when pre release artifacts are bundled with preview features, feature flags, or staged rollout channels. The operational standard is simpler: if the build can still change without formal production change control, it remains pre release and must be isolated from production trust decisions. That matters in identity systems because NIST Cybersecurity Framework 2.0 emphasises controlled risk treatment, and pre release software is inherently higher risk until verification completes.
The most common misapplication is treating a release candidate as production-ready simply because it passes smoke tests, which occurs when teams skip environment parity and sign-off checks.
Examples and Use Cases
Implementing pre release build governance rigorously often introduces schedule friction and environment overhead, requiring organisations to weigh faster validation against the cost of tighter controls and re-testing.
- An identity platform team deploys a beta secret rotation service into staging to verify that token refresh logic works before production cutover, then blocks all real secrets from the test environment.
- A security engineering group evaluates a release candidate for an agentic workflow engine against the practices described in Ultimate Guide to NHIs while ensuring the build cannot access production vaults or customer data.
- A CI/CD pipeline promotes an alpha build of an API gateway integration to a canary segment so the team can detect authentication regressions before broader rollout, using the change as a test artifact only.
- An access management team validates a pre release connector against NIST Cybersecurity Framework 2.0 outcomes to confirm logging, rollback, and recovery requirements are satisfied.
- A governance board requires that any pre release build handling NHI secrets be signed, inventory-tracked, and time-limited so it cannot silently become an unmanaged operational dependency.
Why It Matters in NHI Security
Pre release builds become risky when teams confuse testing convenience with trustworthiness. In NHI environments, a build that can still change may also change its secret storage, API permissions, telemetry, or outbound network behaviour. That can create false assurance during validation and leave service accounts, tokens, or certificates exposed if the test artifact is granted production-like access. NHI Mgmt Group data shows that Ultimate Guide to NHIs reports 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is why pre release handling must include strict isolation and revocation planning.
For governance, the key issue is not whether the build is newer or more polished, but whether its identity posture is bounded: no production secrets, no standing elevated access, and no unmanaged promotion path. That aligns with NIST Cybersecurity Framework 2.0 expectations for protected change control and resilient recovery.
Organisations typically encounter the consequences only after a failed cutover, leaked token, or privilege misconfiguration, at which point the pre release build becomes operationally unavoidable to investigate and retire.
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, OWASP Agentic AI Top 10 and CSA MAESTRO 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-01 | Covers lifecycle control and safe handling of non-production NHI artifacts. |
| OWASP Agentic AI Top 10 | A-03 | Preview agent or tool builds can alter execution behavior before release. |
| NIST CSF 2.0 | PR.DS | Addresses protecting data and secrets during software testing and change. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust limits trust in non-final components until verified. |
| CSA MAESTRO | SPM | Agentic and cloud security guidance requires staged validation before deployment. |
Keep pre release builds away from production secrets and verify protection controls before rollout.
Related resources from NHI Mgmt Group
- Who should be accountable for secrets hidden inside build and release pipelines?
- What should organisations do when an AI tool participates in build or release workflows?
- Why does a pre-build review matter in IAM and NHI programmes?
- When should organisations prioritise runtime protection over pre-release checks?
