Because many renewal processes rely on historical spend and informal ownership rather than current usage and lifecycle evidence. If an app was approved once, it is often renewed by default even when users have changed roles or stopped using it. Renewal governance only works when it functions like recertification.
Why This Matters for Security Teams
SaaS renewal is not just a finance activity. It is a control point that decides whether access, spend, and risk continue for another term. When renewal owners rely on historical approvals instead of current usage, dormant apps, over-licensed tenants, and forgotten integrations survive by default. That pattern is especially dangerous in environments that already struggle with secret sprawl and lifecycle drift, as shown in Ultimate Guide to NHIs and the Guide to the Secret Sprawl Challenge.
NHI Management Group’s research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them. The same governance weakness shows up in SaaS renewals: if the process is not evidence-based, waste is simply re-authorised. Current guidance from the OWASP Non-Human Identity Top 10 reinforces that identities and secrets must be tied to lifecycle controls, not one-time approvals. In practice, many security teams discover renewal waste only after unused subscriptions, stale entitlements, and hidden service accounts have already been renewed for another year.
How It Works in Practice
The operational fix is to treat renewal as recertification, not rubber-stamping. That means every renewal request should answer three questions: is the service still in active use, who owns it now, and what evidence proves continued need. For SaaS, the evidence usually comes from actual login activity, SSO logs, admin actions, invoice-to-usage comparison, and business owner attestation. For non-human workflows, that evidence should also include API usage, integration health, and whether secrets or tokens remain in circulation.
A useful renewal workflow usually includes:
- Usage review across the last 60 to 120 days, not just annual spend history.
- Ownership re-confirmation so abandoned apps do not inherit stale approvers.
- Entitlement right-sizing before renewal, including seat reductions and role cleanup.
- Secret and token checks for connected automations, consistent with the Guide to NHI Rotation Challenges.
- Decision logging so renewals can be audited like any other access recertification.
This model aligns with zero trust thinking because it assumes approvals expire unless refreshed with evidence. It also maps cleanly to NHI lifecycle discipline described in the NHI Lifecycle Management Guide. The important point is that waste persists when procurement, IT, and security each see only part of the picture. When the same application also supports machine access or embedded secrets, renewal decisions must include both human licensing and workload identity signals from the start. These controls tend to break down when renewals are handled inside procurement systems with no telemetry from identity, endpoint, or application logs.
Common Variations and Edge Cases
Tighter renewal controls often increase coordination overhead, requiring organisations to balance spend reduction against business disruption and review fatigue. That tradeoff becomes real in globally distributed SaaS estates, where local teams buy tools outside central procurement, or in systems where an application is still low-use but critical for a single process. Current guidance suggests that not every low-usage app should be removed automatically; some should be downgraded, consolidated, or moved to a shared license model instead.
There is also no universal standard for how much usage is “enough” to justify renewal. Some teams use hard thresholds, while others require risk-based review for sensitive categories such as finance, customer data, or tools with embedded automation. The same caution applies when a SaaS platform holds service tokens or API keys: an apparently unused seat may still support a production integration. In those cases, the right decision may be to renew the service while removing inactive user seats and rotating the associated secrets, rather than treating the whole contract as necessary. That is why the Top 10 NHI Issues and Ultimate Guide to NHIs — Static vs Dynamic Secrets are relevant here: renewal waste often hides where human procurement meets machine access, not in the license ledger alone.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Renewals often prolong stale secrets and access without lifecycle review. |
| NIST CSF 2.0 | GV.OV-01 | Governance oversight is needed so renewals are evidence-based, not defaulted. |
| NIST AI RMF | GOVERN | Renewal logic should use documented governance, ownership, and accountability. |
Create a governed renewal process that validates ownership, usage, and risk before reauthorising spend.
