They make access reviews more important because administrative rights are now distributed closer to the customer or partner edge. Reviews need to confirm tenant scope, role scope, and whether access still matches the business relationship. Offboarding must revoke portal access alongside the underlying admin entitlements.
Why This Matters for Security Teams
Tenant admin portals change the risk profile because they put privileged actions closer to the customer, partner, or reseller edge, where access is often granted for support, onboarding, or break-glass work. That makes access reviews less about a single role and more about whether the tenant scope, delegated scope, and business relationship still justify the privilege. It also means offboarding cannot stop at the portal account; it must remove the underlying admin entitlement, any NHI tied to that role, and any secrets or tokens that still permit access. NHI lifecycle discipline matters here, especially because only 20% of organisations have formal processes for offboarding and revoking API keys, according to the Ultimate Guide to NHIs. The practical issue is that portal access often outlives the contract, the project, or the support need unless review workflows are explicitly tied to tenant-specific entitlements and ownership changes. In practice, many security teams encounter stale tenant access only after a partner relationship has already ended, rather than through intentional review.How It Works in Practice
Effective tenant-portal governance starts by separating three things: the human or service identity that signs in, the portal role it activates, and the tenant or customer environment where that role applies. Reviews should verify all three. A user may still be appropriate for one tenant, but not another; a partner admin may need support rights without standing delegation; and an automation account may need access only for a named workflow window. Current guidance suggests treating portal entitlements as lifecycle-managed NHIs, not as ordinary application permissions. The NHI Lifecycle Management Guide and Top 10 NHI Issues both reinforce that revocation, rotation, and inventory are as important as initial issuance.Operationally, teams usually need a review packet that includes tenant name, delegated admin role, start date, last-used date, business sponsor, and whether the access is tied to a human or to an NHI such as an API key, service account, or automation token. Good practice is to pair access certification with joiner-mover-leaver events so that a contract end, vendor change, or project closure triggers both portal deprovisioning and secret invalidation. OWASP’s OWASP Non-Human Identity Top 10 is a useful external lens here because portal access often fails at the same control points as other NHI patterns: overprivilege, poor lifecycle control, and weak observability.
- Review tenant scope separately from global admin scope.
- Require named business ownership for each delegated portal grant.
- Revoke portal roles and the backing NHI credential together.
- Confirm token or key invalidation after offboarding, not just account disablement.
These controls tend to break down when portals are shared across many tenants and the provider lacks tenant-level usage telemetry, because administrators cannot prove who still needs which edge privilege.
Common Variations and Edge Cases
Tighter tenant-scoped controls often increases operational overhead, requiring organisations to balance review accuracy against support speed. That tradeoff is real in MSP, channel, and integration-heavy environments where one admin may legitimately support multiple tenants, but the approval basis differs per tenant. Best practice is evolving here, and there is no universal standard for exactly how often delegated portal access should be re-certified. Many teams use shorter review cycles for external admins and longer cycles for internal staff, but the important part is that the cadence matches the risk of the tenant relationship.Edge cases usually involve emergency access, dormant tenants, or service accounts that are embedded in automation. Emergency access should be explicitly time-bound and logged, not left as standing privilege. Dormant tenants should be checked for forgotten delegated access because inactivity does not equal absence of risk. For automation, offboarding must include secret revocation, certificate replacement, and any callback or API integration cleanup, otherwise the portal account may disappear while the machine-to-machine path remains live. The strongest control model is still least privilege plus explicit expiry, which aligns with the broader lifecycle guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and with breach patterns documented in the 52 NHI Breaches Analysis. The main failure mode is assuming that disabling the portal login also removes every delegated path into the tenant.
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-01 | Tenant portals often hide overprivileged and stale non-human access. |
| NIST CSF 2.0 | PR.AC-4 | Access review and offboarding are core identity and access governance tasks. |
| NIST Zero Trust (SP 800-207) | Tenant portals should not create standing trust across customers or partners. |
Inventory tenant-scoped NHIs and remove any portal grant that no longer has a business owner.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
