Tenant configuration integrity is the condition that identity policies, access rules, application assignments, workflows, and related settings remain accurate, complete, and recoverable. In disaster recovery, it is the baseline that determines whether an identity tenant can be restored to a known-good state after drift, deletion, or compromise.
Expanded Definition
Tenant configuration integrity refers to the assurance that an identity tenant’s policies, access rules, app assignments, conditional controls, workflow logic, and recovery settings are correct, complete, and restorable after change. In NHI operations, the term is broader than simple backup hygiene because it includes configuration drift detection, change control, and the ability to prove that the restored state matches the approved security baseline.
This matters because a tenant can remain technically available while still being functionally unsafe: a single altered app assignment, weakened conditional access rule, or missing privileged role binding can create silent exposure. Guidance varies across vendors on how much of the tenant state should be treated as recoverable security configuration versus operational metadata, so practitioners should define the scope explicitly in their own recovery standard. NIST Cybersecurity Framework 2.0 is useful here as a reference point for recovery and resilience outcomes, even though it does not prescribe tenant-specific mechanics.
The most common misapplication is treating tenant backup as integrity, which occurs when teams assume exported settings are usable without validation against the live policy baseline.
Examples and Use Cases
Implementing tenant configuration integrity rigorously often introduces administrative overhead, requiring organisations to weigh faster change velocity against stronger recovery assurance.
- After a misconfigured admin change, a restored tenant is compared against a known-good policy snapshot to confirm that MFA, conditional access, and privileged assignments match the intended state.
- During identity platform migration, app registrations, federation settings, and role bindings are exported, verified, and re-imported so the target tenant preserves security intent rather than just functional access.
- In incident response, teams use immutable config records to determine whether a malicious actor changed authentication flows or consent settings before access was abused.
- For service account governance, hidden workflow dependencies are checked so that automated approvals and secret rotation jobs still run after recovery.
- Following an outage, change logs are reconciled with tenant state to validate that recovery did not reintroduce legacy permissions or deleted safeguards.
For a real-world example of identity misconfiguration turning into broader compromise, see the Twitter Source Code Breach. For recovery and control mapping context, the NIST Cybersecurity Framework 2.0 helps organisations organise resilience expectations without conflating them with backup alone.
Why It Matters in NHI Security
Tenant configuration integrity is a control plane issue, not a documentation exercise. When a tenant is drifted, partially deleted, or restored from stale exports, NHI-related controls can fail in ways that are hard to spot: service accounts retain excessive access, automation keeps running with old trust paths, or approval workflows silently bypass review. NHIMG data shows that 97% of NHIs carry excessive privileges, which makes configuration errors especially dangerous because small policy deviations can expand blast radius immediately.
This is why integrity must cover both prevention and recoverability. A tenant that cannot be restored to an approved state after compromise leaves teams with no reliable way to re-establish trust. That risk becomes more severe in environments with many embedded credentials and automated permissions, where configuration drift can persist unnoticed until an incident exposes it. Organisations typically encounter the operational cost of tenant configuration integrity only after a failed recovery, at which point the missing baseline becomes the incident’s limiting factor.
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 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-08 | Configuration drift and recovery integrity are core NHI governance concerns. |
| NIST CSF 2.0 | RC.RP | Recovery planning depends on restoring trusted identity configurations, not just services. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on continuously trusted policy and access decisions. |
Reconcile tenant settings with least-privilege and explicit verification assumptions after every restore.
Related resources from NHI Mgmt Group
- Should organisations separate file integrity monitoring from configuration management?
- Who is accountable when an identity provider stays available but a tenant configuration is weakened or lost?
- Who is accountable when a multi-tenant authorization bypass lets one tenant influence another tenant's configuration?
- Configuration integrity
