What is the difference between platform-supported and tenant-configured identity controls?

What the boundary really is between platform-supported and tenant-configured controls

Platform-supported controls are built into the service and exist before your team writes a policy, such as identity uniqueness, token handling, or protected authentication plumbing. Tenant-configured controls are the organisation-specific settings, rules, and evidence you must define and maintain, such as MFA requirements, password policy, session timeout, inactivity handling, and exception tracking.

The practical difference is ownership and default state: platform-supported controls reduce implementation burden, but they do not by themselves prove compliance or good hygiene. Tenant-configured controls are where policy becomes enforceable behaviour, and that is usually what auditors and assessors want to see.

Why this distinction matters for control design and audit evidence

For identity controls, the question is not whether the platform can do something in principle, but whether the tenant has actually turned it on, scoped it correctly, and documented the operating rule. A service may provide secure authentication plumbing, but your organisation still has to decide who must use MFA, when prompts occur, how break-glass access is handled, and what happens when accounts go inactive.

This matters because CMMC and similar evidence reviews do not stop at feature availability. They look for the implemented control state, the policy decision behind it, and the operational evidence that the setting is active across the intended population.

That distinction is also why control catalogs and identity guidance often separate the mechanism from the administrative choice. Identity platforms may expose an option, but the tenant is responsible for making that option part of an enforceable control environment, not just a capability sitting in the console.

How to evaluate a control: default capability, configurable policy, or compensating process

When you assess an identity control, treat it as one of three things: platform-native capability, tenant-applied configuration, or a compensating process outside the product. The control is strongest when the platform enforces it by default and the tenant only verifies scope. It is weaker when the tenant must consciously enable it and maintain it over time. It is weakest when the organisation is relying on manual process to substitute for missing enforcement.

That is why a control inventory should record not only identity provider capabilities, but also which settings are mandatory, which are inherited from a tenant template, and which need periodic review because administrators can change them. The same logic applies to lifecycle governance: a setting that exists in the platform is not the same thing as a setting that is standardised, documented, and checked.

For teams mapping identity operations, the useful test is simple: if the service were reconfigured by an admin tomorrow, would the control still be present automatically, or would it need re-enabling? If it needs re-enabling, it is tenant-configured and should be treated as an operational control, not a service guarantee.

Risk and Threat Considerations

The main risk is assuming a service capability is already a control. That creates false assurance, especially where MFA, password policy, or inactivity handling are only available after tenant configuration. In shared services, mis-scoped settings can also leave a subset of users, apps, or privileged accounts outside the intended protection boundary.

Failure mechanism: The tenant records a platform feature as implemented evidence, but the actual control remains disabled, partially scoped, or overridden by a weaker exception path.

Impact: Attackers, insiders, or simple administrative drift can exploit the gap to retain access longer than intended, bypass stronger authentication expectations, or leave stale accounts and weak authentication paths exposed.

Practitioner Guidance

What to verify: Separate “available in the platform” from “enforced in the tenant” in your control register. For each identity control, keep evidence of the specific setting, scope, and owner, not just a product screenshot or vendor statement.

What to prioritise: Give tenant-configured controls the highest scrutiny when they affect authentication strength, account inactivity, privileged access, and exception handling, because those are the settings most likely to drift or be scoped inconsistently.

Common mistake: Treating platform defaults as if they were immutable controls. If a setting can be changed by an administrator, it needs governance, review, and periodic revalidation.

Practitioner takeaway: The question is not whether the platform can support the control, but whether your tenant configuration makes the control real, repeatable, and provable under audit.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• What is the difference between patching a vulnerability and reducing identity blast radius?
• What is the difference between native platform access controls and identity-centric data governance for Snowflake?
• What is the difference between traditional Active Directory and a cloud-based multi-tenant identity platform for MSPs?