Secret import is the process of moving credentials, notes, and other protected data from one vault or tool into another. It must preserve data type, ownership, and security context, because migration mistakes can create duplicates, break formats, or leave sensitive material exposed in unmanaged locations.
Expanded Definition
secret import is the controlled transfer of protected credentials, tokens, API keys, certificates, and sensitive notes from one vault, platform, or repository into another. In NHI operations, the goal is not simple file movement. The import must preserve ownership, secret type, metadata, version history, access policy, and rotation state so the receiving system can govern the secret correctly. That matters because a key imported as the wrong data type, or without its policy context, can become unusable, overexposed, or silently duplicated.
Definitions vary across vendors on whether secret import includes bulk migration, one-time onboarding, or only API-driven ingestion. NHI Management Group treats it as any transfer that changes the authoritative system of record for a secret. This is closely related to vault migration, but not identical: migration is the project, while import is the operational act that loads the protected data into the new control plane. The OWASP Non-Human Identity Top 10 places secret handling failures among the most common sources of exposure, which is why import flows must be designed as security operations, not administrative convenience. The most common misapplication is treating import as a simple copy action, which occurs when teams move secrets without validating ownership, lifecycle state, and destination permissions.
Examples and Use Cases
Implementing secret import rigorously often introduces migration friction, requiring organisations to weigh cleaner governance against temporary operational complexity and outage risk.
- Moving application API keys from a legacy password manager into a centralized enterprise vault while preserving app ownership and rotation schedules.
- Onboarding CI/CD credentials into a secrets manager after a review finds them embedded in build tooling, as documented in the Guide to the Secret Sprawl Challenge.
- Importing certificates and signing keys from one cluster environment to another without flattening the chain of custody or changing expiry tracking.
- Bulk loading service account tokens after a merger, then reassigning ownership and access controls before production cutover.
- Rehydrating secrets into a new vault after incident containment, using the patterns described in the Ultimate Guide to NHIs – Static vs Dynamic Secrets.
In practice, import workflows should validate format, tag source system, confirm destination policy, and trigger immediate rotation where the imported secret may already have been exposed. A related external reference is the OWASP Non-Human Identity Top 10, which helps frame why import is part of the control surface.
Why It Matters in NHI Security
Secret import is a high-risk transition point because it can quietly turn a managed secret into an unmanaged one. If ownership is lost during import, rotation stops. If the destination system receives duplicates, services may keep using old values long after administrators believe migration is complete. If import tooling logs payloads or stores temporary files, sensitive material may be exposed outside the vault boundary. NHI Management Group reports that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes disciplined import controls especially important when consolidating sprawl. The same body of research also shows that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, underscoring that poor transfer handling is not a theoretical problem.
Import governance should therefore include approval, format validation, destination scoping, post-import verification, and decommissioning of the source copy when appropriate. It is also important to understand surrounding ecosystem risks such as pipeline compromise and exposed automation tokens, as seen in the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack. Organisations typically encounter secret import failures only after a migration, leak, or service outage, at which point secret import 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, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret import is a core control point for preventing secret sprawl and exposure. |
| NIST CSF 2.0 | PR.AC-1 | Imported secrets must be assigned and governed under explicit access control policies. |
| NIST Zero Trust (SP 800-207) | SC-3 | Secret import affects trust boundaries and must assume no implicit trust in source or destination. |
| NIST SP 800-63 | AAL2 | Imported credentials still need assurance suitable for the access they unlock. |
| NIST AI RMF | Secret handling is a governance issue because AI systems may ingest or expose protected data. |
Document import risks, constrain data exposure, and monitor AI-connected workflows for secret leakage.
