NYDFS SaaS deadlines expose identity and audit gaps in 2025

At a glance

What this is: This piece argues that NYDFS Part 500 turns SaaS into a regulated control surface where MFA, access review, asset inventory, and non-human privilege management all need auditable evidence.

Why it matters: It matters because SaaS sprawl and unmanaged integrations now sit inside financial-services compliance scope, making identity governance a regulator-facing problem rather than just an IT hygiene issue.

By the numbers:

• The NYDFS Cybersecurity Division has indicated that the agency conducts roughly 400 to 500 reviews annually.
• A 2023 consent order included $1.2M in fines for failure to perform an adequate risk assessment to identify and remediate vulnerabilities.
• In 2024, a personal loan company was fined $4.2M citing multiple deficiencies, including failure to maintain and review user privilege.
• Obsidian Security has seen a +300% increase in SaaS breaches across its participation in incident response.

👉 Read Obsidian Security's NYDFS Part 500 SaaS compliance guidance

Context

NYDFS Part 500 is no longer a narrow banking controls discussion. For regulated financial firms using SaaS, the compliance burden now reaches identity governance, asset inventory, privilege review, and evidence generation across applications that were never designed around audit-first operations. That makes SaaS a direct concern for IAM and NHI control owners, not just GRC teams.

The practical problem is that SaaS environments mix federated users, local accounts, third-party integrations, and service identities that all need distinct oversight. Obsidian Security frames the issue around NYDFS deadlines, but the underlying governance gap is broader: organisations struggle to prove who or what has access, why that access exists, and whether it is still justified. That is a familiar NHI pattern, and it is typically underestimated until audit season or a breach forces the issue.

Key questions

Q: How should security teams prepare SaaS environments for NYDFS Part 500?

A: Start with a complete inventory of SaaS applications and the identities that can reach them, then verify MFA coverage, privilege review, and inactivity cleanup across human and non-human access paths. The goal is not a policy map alone. It is audit-ready evidence that every in-scope control is operating across live SaaS usage.

Q: Why do SaaS integrations create compliance risk under NYDFS?

A: Because integrations often hold persistent access, broad scope, and weak visibility compared with interactive user accounts. If teams do not review those connections as part of identity governance, they can miss the pathways that move regulated data outside intended controls. The risk is both security exposure and an inability to prove oversight.

Q: What is the difference between access review and credential review for SaaS?

A: Access review checks who or what should still have permission to a SaaS app or data set, while credential review checks whether the authentication mechanism itself is current, protected, and still in use. Both matter, but access review is the broader governance control because stale permissions often outlive the credential that created them.

Q: When does SaaS identity sprawl become a regulatory problem?

A: It becomes a regulatory problem when organisations can no longer show who owns each account, why each integration exists, and whether elevated access is still justified. At that point, the issue is not just operational complexity. It is loss of control evidence, which can become an audit finding and a breach multiplier.

Technical breakdown

Why NYDFS compliance for SaaS depends on identity inventory

NYDFS Part 500 requirements only become tractable when organisations can inventory every identity path into SaaS. That means more than listing applications. Teams need to distinguish federated logins, local accounts, app-to-app integrations, and non-human identities such as service accounts or OAuth grants. Without that separation, controls like MFA enforcement, access review, and inactivity pruning become partial at best because the organisation cannot tell which identities are human-managed and which are machine-operated. For SaaS, the real control surface is the identity graph around the application, not the application alone.

Practical implication: Build a complete SaaS identity inventory before trying to evidence compliance, or every other control will rest on incomplete data.

How MFA and privilege review fail in mixed human and non-human access

In SaaS, MFA is usually discussed as a user control, but the governance challenge extends to local accounts, exempted users, and integrations that inherit broad permissions through connected apps. Privilege review is therefore not a one-time access certification. It is a continuous assessment of who can reach sensitive data, which identities are operating without federation, and where elevated access remains after the original business need has passed. The failure mode is simple: compliance teams document the policy while technical teams never validate the real runtime access paths.

Practical implication: Treat MFA and privilege review as live entitlement controls, not quarterly documentation exercises.

Why shadow SaaS and idle integrations complicate audit evidence

SaaS sprawl creates hidden systems of record that do not show up cleanly in traditional IAM tooling. Shadow SaaS, inactive accounts, and old integrations can preserve access long after owners have moved on or business processes have changed. NYDFS-style evidence depends on proving that those stale paths are identified, reviewed, and removed. That is difficult when native logs are incomplete and when app owners do not know which integrations are still active. In practice, audit failure often comes from missing lifecycle visibility rather than from a single misconfigured setting.

Practical implication: Map dormant integrations and shadow SaaS into the same control workflow as production accounts and privileged users.

Threat narrative

Attacker objective: The objective is to exploit weak SaaS identity governance to reach regulated data while leaving the organisation unable to demonstrate effective control.

1. Entry often begins through a neglected SaaS identity path such as an over-privileged integration, stale local account, or unreviewed access grant.
2. Escalation occurs when the attacker uses that identity to reach privileged SaaS data or connected business systems with limited detection.
3. Impact follows when the organisation cannot quickly prove control effectiveness, increasing the likelihood of exposure, regulatory scrutiny, and compounded fines.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NYDFS is effectively turning SaaS identity governance into a regulated evidence problem. The regulation is not only asking whether controls exist. It is asking whether controls can be shown to work across federated users, local accounts, and connected applications. That shifts the centre of gravity from policy writing to continuous proof, and teams that cannot produce that proof will struggle in audit and incident response alike.

Non-human identities are now part of the compliance story, whether the regulation names them or not. SaaS integrations, service accounts, and delegated access grants are often the pathways that expand blast radius during both breaches and audits. A programme that excludes these identities from review is not complete, because the access path to regulated data is usually broader than the human user list suggests. Practitioners should treat NHI governance as part of the control baseline, not an adjacent project.

Identity blast radius is the right concept for NYDFS-era SaaS risk. The issue is no longer just whether a login is protected by MFA. It is how far one compromised account, stale integration, or forgotten local credential can travel across SaaS and connected systems. That is why access review, privilege minimisation, and lifecycle cleanup need to be measured together. The practical conclusion is that blast-radius reduction is now a compliance objective as much as a security one.

Compliance tooling will matter less than control design if ownership is unclear. Mapping NYDFS to SaaS controls can help with audit preparation, but mapping alone does not fix ambiguous ownership, incomplete inventories, or unmanaged exceptions. Organisations need a control model that ties each SaaS app, each integration, and each privileged identity to a responsible owner and a review cadence. Practitioners should re-evaluate whether their current governance model can answer that question without manual reconstruction.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, with inadequate monitoring and logging and over-privileged accounts each named by 37%.
• For a broader control baseline, see NHI Lifecycle Management Guide for the lifecycle steps that keep identities reviewable from creation through retirement.

What this signals

Identity governance for SaaS is moving toward continuous evidence, not periodic attestation. As NYDFS deadlines force more rigorous proof of control, teams will need to connect inventory, privilege, and exception management into one workflow. The organisations that treat SaaS identities as living assets rather than static records will be better placed to answer auditors and incident responders with the same data set.

Ephemeral access is not enough if orphaned access paths remain in place. The more SaaS estates rely on delegated access, the more the programme needs lifecycle discipline for integrations and local accounts. With only 1.5 out of 10 organisations highly confident in securing NHIs, according to The State of Non-Human Identity Security, the likely gap is not lack of policy but lack of trustworthy inventory.

Identity blast radius should become a board-level metric for regulated SaaS. If one stale integration or privileged account can widen the impact of a single compromise, then control owners need to measure how quickly access can be removed, rotated, and evidenced. That approach aligns more closely with NIST Cybersecurity Framework 2.0 than with traditional one-and-done access certification.

For practitioners

• Inventory every SaaS identity path Classify federated users, local accounts, service identities, and app integrations in the same register so control owners can see the full access graph.
• Prioritise MFA coverage for exposed access paths Verify that human users, local accounts, and any approved exceptions are documented, monitored, and removed when the business need ends.
• Review non-human privilege on a fixed cadence Set a review cycle for integrations and service accounts that checks scope, inactivity, and privilege drift against business ownership.
• Evidence remediation, not just policy mapping Link each NYDFS control to a dated remediation record, owner, and proof artifact so audits can trace what changed and when.

Key takeaways

• NYDFS Part 500 pushes SaaS security into identity and evidence management, not just technical hardening.
• Non-human identities and stale integrations are part of the regulatory risk surface because they expand access beyond visible user accounts.
• Teams should focus on complete inventory, privilege review, and proof of remediation if they want audits to be survivable.

Key terms

• Non-human identity: A non-human identity is any credentialed actor that is not a person, including service accounts, API keys, tokens, certificates, workloads, and AI agents. These identities often hold persistent access and can quietly expand blast radius if they are not inventoried, rotated, and reviewed like human accounts.
• SaaS identity inventory: A SaaS identity inventory is a continuously maintained record of every account, integration, and authentication path tied to a software-as-a-service application. It matters because compliance and security failures often come from what teams cannot see, especially local accounts, stale grants, and shadow integrations.
• Identity blast radius: Identity blast radius is the amount of systems, data, and downstream access a single compromised identity can reach. In SaaS environments, it is driven by privilege scope, delegated access, and forgotten integrations, making it a useful way to measure how quickly one account issue can become a regulatory and security problem.

Deepen your knowledge

SaaS identity inventory, lifecycle governance, and privilege review are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for regulated SaaS environments, it is worth exploring.

This post draws on content published by Obsidian Security: 2025 NYDFS deadlines expose SaaS security gaps and how to avoid fines. Read the original.