The import is only the bootstrap step. After the initial data is loaded and verified, the application should switch to reading and writing relationships in SpiceDB directly. If teams stop at the import, they still carry the same coupling and operational limitations of the old model, only in a new format.
What the import actually does
An import into SpiceDB is a migration step, not the end state. It is used to load an existing authorization model and relationship set so the system can start from a known baseline. After that bootstrap, SpiceDB becomes the source of truth for permission checks, relationship updates, and future authorization changes.
The practical shift is that authorization stops being a one-time data copy and becomes an operating dependency. Reads should come from SpiceDB, writes should go to SpiceDB, and the application should stop treating the old store or legacy policy file as the place where access decisions are still made. If you keep dual-maintaining both, divergence is almost guaranteed.
That is why import success should be judged by what happens next, not by whether the initial data load completed. The application should verify the imported relationships, switch request paths over, and then use the live authorization API for ongoing checks and mutations. The import only makes sense if it is followed by that cutover.
Why the old model cannot remain in parallel
Staying on the old model after import preserves the same coupling that usually motivated the migration in the first place. The system still depends on legacy schemas, bespoke authorization code, or ad hoc synchronization, so teams do not gain the operational clarity that a dedicated relationship store is meant to provide.
There is also a correctness issue. When one system is treated as the real policy source and another is treated as the operational source, the two eventually drift. New permissions, revocations, and relationship changes then need reconciliation logic, which reintroduces the very complexity the import was supposed to remove.
For teams moving from legacy authorization patterns, the better mental model is to treat import as a controlled handoff. The migration ends when the application no longer needs the old model for live decisions. Until that point, the import is only a partial step, even if it appears complete from a data perspective. For broader identity and authorization lifecycle context, Ultimate Guide to NHIs and NHI Lifecycle Management Guide provide useful governance framing.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Import-to-cutover depends on retiring legacy access paths and enforcing the new source of truth. |
| Recommendation — Remove legacy authorization paths and enforce SpiceDB as the only live permission source. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | The question concerns how authorization is operated after migration and who is trusted to make decisions. |
| PR.PS-03 — Least Functionality | Keeping the old model active after import preserves unnecessary operational complexity and duplicate control paths. | |
| Recommendation — Define the post-import authorization authority and prevent parallel decision sources. Disable the legacy authorization path once SpiceDB is validated. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Authorization data migration often depends on controlled access to the data used to bootstrap and operate the system. |
| Recommendation — Protect bootstrap data and rotate any credentials used during migration. | ||
Practitioner Guidance
What to verify: Confirm that the application is no longer reading authorization truth from the legacy source after import. A common failure mode is leaving shadow reads, fallback logic, or periodic sync jobs in place, which quietly defeats the migration.
Implementation sequence: Load and validate the imported relationships, switch permission evaluation to SpiceDB, then update writes so new relationship changes are created there directly. If the old system still accepts writes, treat that as a temporary migration aid with a removal date, not a permanent architecture.
Common mistake: Teams often treat the import as a one-off data move and stop before operational ownership changes. That leaves them with duplicated control planes, slower troubleshooting, and a false sense that authorization has been modernised when only the storage format changed.
Practitioner takeaway: The real outcome of an import is not historical preservation, it is cutover. Once the data is in SpiceDB, the system should behave as if SpiceDB is the live authorization engine, or the migration has not actually finished.
Related resources from NHI Mgmt Group
- What happens when a malicious package uses a detached process to keep stealing data after installation ends?
- What happens after suspicious credentials are used to query backend data without authorization?
- What happens when edge authorization uses cached policy data that is not invalidated quickly enough?
- What happens when a data mapping process is not kept current after the first version is completed?
