Account Kit

Expanded Definition

An account kit is best understood as a bootstrapping artifact for a Passbolt account: a signed identity package that lets a client prove it is interacting with the right domain and trust context before any retrieval or login flow begins. In practice, that means the kit carries keying material plus enough related authentication data to establish initial confidence without exposing the underlying account. It is not the same as a password, and it is not merely a convenience file. It is a sensitive access artifact with its own lifecycle, handling rules, and revocation considerations.

Definitions vary across vendors because some products treat similar bootstrap packages as enrollment records, activation bundles, or recovery materials. In NHI governance, the important distinction is operational: the account kit exists to make first trust possible, while the account itself remains governed as a protected identity and access object. That means the kit must be treated like a secret-bearing credential, with careful storage, controlled delivery, and a defined retirement path aligned to identity lifecycle policy and least privilege principles described in the NIST Cybersecurity Framework 2.0.

The most common misapplication is treating the account kit as an ordinary onboarding file, which occurs when teams email it, copy it into shared drives, or leave it available after initial provisioning.

Examples and Use Cases

Implementing account kit handling rigorously often introduces onboarding friction, requiring organisations to weigh faster first access against tighter controls on distribution, expiry, and recovery.

• A security team provisions a new Passbolt tenant and uses the account kit to validate the client’s trust context before the first administrative login.
• A DevOps engineer stores the kit in a protected handoff workflow rather than a ticket attachment, reducing accidental exposure during account activation.
• An identity administrator rotates or retires the kit when a bootstrap event is complete, preventing reuse of stale trust material in a later login attempt.
• A governance team reviews the kit as part of NHI offboarding, because bootstrap artifacts can become lingering access paths if they are never invalidated.
• A platform owner compares the kit’s handling to broader NHI secret discipline described in Ultimate Guide to NHIs and aligns it to identity assurance practices in NIST Cybersecurity Framework 2.0.

When the term is used operationally, it usually appears in deployment, recovery, and onboarding flows where a client must validate the correct domain and account context before any secrets are exchanged.

Why It Matters in NHI Security

Account kits matter because bootstrap artifacts sit at the boundary between trust establishment and credential exposure. If the kit is copied, replayed, or stored without expiry controls, it can become a reusable entry point into an NHI-controlled environment. That risk is especially significant in ecosystems where secrets already sprawl across code, tickets, and shared storage. 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 makes a bootstrap package especially dangerous if it is handled casually.

For NHI security programs, the control question is not only whether the account kit works, but whether it is tightly bound to a lifecycle event, a specific domain, and a deliberate revocation step. The same governance logic that applies to service account secrets and API keys also applies here, because a bootstrap package can outlive its intended purpose if nobody owns its retirement. The Ultimate Guide to NHIs provides the broader lifecycle context, while NIST Cybersecurity Framework 2.0 helps map the control expectation to access governance and protective processes.

Organisations typically encounter the need to govern an account kit only after a provisioning artifact is reused, forwarded, or found in an unexpected place, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What happens when a human uses an NHI account?
• What happened in the demo account left active in production scenario and what does it reveal?
• What makes a super NHI different from an ordinary service account?
• When does a service account become a compliance problem?