The administrative control area where tenant-wide security and access policies are configured for a platform. These settings determine how users authenticate, what login methods are allowed, and which guardrails apply across the organisation rather than at the individual account level.
Expanded Definition
Organization Settings are the tenant-level controls that define how a platform behaves for every user, workspace, and connected workload under a single administrative boundary. In NHI and IAM operations, these settings govern authentication methods, session policy, login restrictions, device or network guardrails, and sometimes default access workflows. They are distinct from user-level preferences because they set the security posture for the entire organisation, not for one account.
Definitions vary across vendors, but the security meaning is consistent: this is where administrators establish baseline control over identity assurance and platform-wide access boundaries. That makes Organization Settings closely related to NIST Cybersecurity Framework 2.0 governance and access practices, especially where centralized policy enforcement supports repeatable control. In NHI environments, the same pattern applies to service accounts, API keys, and agent identities that inherit defaults from the tenant rather than being tuned individually.
Because these settings often affect every identity in the tenant, they should be treated as security-critical change surface, not administrative convenience. The most common misapplication is leaving permissive defaults in place after setup, which occurs when teams assume the platform’s out-of-the-box configuration is secure enough for production.
Examples and Use Cases
Implementing Organization Settings rigorously often introduces some administrative overhead, requiring organisations to weigh centralized consistency against the speed of local team onboarding.
- Requiring SSO for all users in a tenant so that password policy, MFA, and conditional access are enforced centrally rather than by project team.
- Restricting approved login methods to reduce exposure from weak or inconsistent authentication paths, especially in environments that also manage machine identities.
- Setting default session duration and reauthentication rules to reduce the chance that a compromised browser session can be reused for privileged changes.
- Applying platform-wide guardrails for API access so service accounts and automation agents inherit a minimum security baseline from the tenant.
- Using organisation-wide controls as part of a Zero Trust program, aligned to the broader governance model described in the Ultimate Guide to NHIs and the policy direction in NIST Cybersecurity Framework 2.0.
For NHI-heavy platforms, organisation settings may also determine whether tokens can be created, whether third-party integrations are allowed, and whether administrators can override defaults without review. That matters because Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which means a weak tenant baseline can amplify every downstream access decision.
Why It Matters in NHI Security
Organisation Settings often become the control point that decides whether an NHI program is defensible or fragmented. If tenant-wide authentication options are too broad, teams may accidentally permit weak login paths that undermine MFA, token governance, and Zero Trust enforcement. If the settings are too permissive for integrations, secrets and automation credentials can spread across tools without a consistent control baseline. This is where NHI security becomes operational, because platform defaults can either constrain privilege or silently expand it.
The risk is not theoretical. NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That kind of exposure is harder to contain when organisation-wide settings allow broad authentication, weak guardrails, or inconsistent administrator exceptions. The governance lesson is simple: tenant settings should be reviewed with the same discipline as privileged access and secrets policy.
Organisations typically encounter the consequences only after a misconfigured tenant, exposed credential, or unauthorized integration has already been exploited, at which point Organization Settings become 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-01 | Tenant-wide auth and guardrails shape NHI exposure and baseline security. |
| NIST CSF 2.0 | PR.AC-1 | Access control governance begins with centrally defined platform policy. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust depends on centralized policy enforcement and continuous access control. |
| NIST SP 800-63 | AAL2 | Authentication assurance settings influence whether platform login meets assurance needs. |
| NIST AI RMF | Governance and accountability require clear configuration control over system-wide settings. |
Treat organization settings as governed AI and identity risk controls with documented ownership.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
