How can IAM teams support sustainability goals without weakening security?

Why This Matters for Security Teams

Sustainability goals often collide with identity sprawl, not security itself. The waste comes from repeated logins, long approval chains, manual onboarding, and credentials that sit unused but still need to be monitored, rotated, and audited. Those steps consume time, energy, and administrative effort without improving assurance. Current guidance suggests the better path is to remove friction that does not increase trust, while keeping strong identity proofing, conditional access, and lifecycle controls in place.

This matters because identity systems are now part of operational efficiency, not just control enforcement. If every service, workload, or contractor event triggers a heavy workflow, teams create hidden carbon, staffing, and risk costs at the same time. The security objective is to compress wasted control steps, not to relax the control model. That is consistent with the NIST Cybersecurity Framework 2.0, which pushes organisations toward outcome-based, risk-informed governance rather than blanket process overhead. It also aligns with NHIMG research such as the DeepSeek breach, where exposed secrets and poor identity hygiene created avoidable operational and security cost. In practice, many security teams encounter sustainability debt only after identity friction has already driven shadow workflows and exceptions.

How It Works in Practice

The practical pattern is to eliminate redundant identity events while preserving strong assurance at the points that matter. For human access, that usually means adaptive MFA, SSO, and risk-based reauthentication so people do not prove identity repeatedly when context has not changed. For non-human identities, it means shifting away from static secrets toward short-lived credentials, automated issuance, and lifecycle controls tied to workload need rather than calendar time. That reduces manual touchpoints and lowers the chance of stale access lingering in the environment.

A useful operating model is to distinguish between high-value decisions and low-value repetition. Security teams can preserve assurance by centralising policy at the identity provider, using RBAC only where roles are stable, and adding JIT provisioning for privileged actions that need temporary elevation. Zero standing privilege supports this approach by ensuring access exists only when a task is active. The NIST Cybersecurity Framework 2.0 is helpful here because it supports governance, access control, and continuous risk management without requiring a separate workflow for every event.

• Replace repeated approvals with policy-based conditional access where the same trust decision can be reused safely.
• Use JIT access for privileged operations instead of permanent elevated roles.
• Automate onboarding and offboarding so lifecycle control is continuous, not document-driven.
• Prefer short-lived secrets and workload identity for services, scripts, and integrations.

NHIMG research shows why this matters: the Azure Key Vault privilege escalation exposure illustrates how privilege and secret handling can amplify risk when identity workflows are too coarse. Where teams can safely remove wasted steps, they should, but these controls tend to break down when legacy applications require shared accounts, hard-coded secrets, or synchronous approvals for every access event because automation cannot reliably evaluate context there.

Common Variations and Edge Cases

Tighter access controls often increase implementation effort at first, so organisations need to balance lower operational waste against migration complexity and user impact. That tradeoff is especially visible in regulated environments, older SaaS estates, and hybrid infrastructure where identity patterns are inconsistent. There is no universal standard for this yet, but best practice is evolving toward context-aware access, short-lived credentials, and policy-driven automation rather than broad exceptions.

Edge cases usually fall into three groups. First, some systems cannot support modern federation or JIT, so teams may need compensating controls such as vault-backed secrets, stronger monitoring, and stricter segmentation. Second, highly sensitive workflows may justify extra approvals if the risk reduction is real, but only if those approvals are limited to exceptional cases. Third, sustainability metrics should not become a reason to weaken revocation, logging, or attestation. The goal is to reduce wasteful identity churn, not to reduce auditability.

The most effective programmes treat sustainability as a design constraint for identity architecture. That means fewer standing privileges, fewer manual tickets, fewer long-lived credentials, and fewer unnecessary revalidations. It does not mean fewer decisions about trust. For organisations moving in that direction, the safest path is to align lifecycle automation with risk signals, then measure whether control simplification reduced both operational load and exposure.

Related resources from NHI Mgmt Group

• How should security teams govern shadow AI without blocking productivity?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?