NYDFS Part 500 Final Phase Is Live: The Asset Inventory and MFA Duties You Must Now Evidence

Two requirements everyone assumed they had years to sort out went live on 1 November 2025. If your asset inventory is a spreadsheet last touched in 2023, and your MFA stops at the VPN, you are now looking at examination findings, not future deadlines.

The Second Amendment to New York’s cybersecurity regulation, 23 NYCRR Part 500, was adopted on 1 November 2023 and phased in over two years. The two-year tranche was the one people quietly deferred, because it contained the two obligations that are genuinely hard to fake: a maintained asset inventory under section 500.13(a), and expanded multi-factor authentication under section 500.12. Both are now in force. This is a reading of what they demand of the technology function, and what a NYDFS examiner will actually ask you to produce.

The inventory is not a spreadsheet you export once

Section 500.13(a) requires each covered entity to implement written policies and procedures designed to produce and maintain a complete, accurate and documented asset inventory of its information systems. Read that sentence slowly, because every clause is load-bearing. It is not “have a list of assets”. It is a documented process that produces and maintains a list that is complete and accurate. The deliverable the regulation cares about is the mechanism, not the artefact.

The rule then names the minimum attributes the inventory must track for each asset: owner, location, classification, support expiration date, and recovery time objectives. And it requires your policy to state the frequency at which the inventory is updated and validated. That last clause is where most firms will fail. A static list has no frequency; a maintained inventory does. If your written procedure does not say “reconciled monthly against the CMDB and the cloud provider’s resource inventory, validated quarterly by the asset owner”, you have a list, not the thing 500.13 asks for.

Two of the named attributes are the ones IT teams habitually leave blank. Support expiration date — end-of-life — is the field that turns an inventory into a risk register. An asset past vendor support is an unpatched asset by definition, and an examiner who sees an EOL date in the past with no compensating control noted has found a finding. Recovery time objective ties the inventory to your continuity plan; an asset with no RTO has never been triaged for how quickly it must come back, which means your continuity planning has a hole the inventory now makes visible.

A schema that holds the five mandated fields

The cleanest way to make an inventory auditable is to define the record structure explicitly and validate every entry against it, so an asset cannot enter the register with a mandated field left null. Here is a minimal JSON Schema that encodes the 500.13 attributes and forces the fields the rule names — adapt the enumerations to your own classification and criticality scales.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Information system asset record (23 NYCRR 500.13)",
  "type": "object",
  "required": [
    "asset_id", "name", "owner", "location",
    "classification", "criticality",
    "support_expiration", "recovery_time_objective_hours",
    "last_validated"
  ],
  "properties": {
    "asset_id": { "type": "string" },
    "name": { "type": "string" },
    "owner": {
      "type": "string",
      "description": "Named accountable individual, not a team alias"
    },
    "location": {
      "type": "string",
      "description": "On-prem site, cloud account/region, or SaaS tenant"
    },
    "classification": {
      "enum": ["public", "internal", "confidential", "nonpublic-information"]
    },
    "criticality": {
      "enum": ["low", "moderate", "high", "mission-critical"]
    },
    "support_expiration": {
      "type": "string",
      "format": "date",
      "description": "Vendor end-of-support date; past dates require a linked compensating control"
    },
    "recovery_time_objective_hours": {
      "type": "integer",
      "minimum": 0,
      "description": "Agreed RTO; must reconcile with the continuity plan"
    },
    "compensating_control_ref": {
      "type": ["string", "null"],
      "description": "Required when support_expiration is in the past"
    },
    "last_validated": {
      "type": "string",
      "format": "date",
      "description": "Populated by the update/validation cycle named in policy"
    }
  }
}

The value is not the schema itself; it is running it in the pipeline that writes to the register, so a null owner or a missing RTO fails validation rather than sitting silently in a spreadsheet. The last_validated field is what lets you evidence “maintained” — a report of records not validated within your stated frequency is precisely the exception list an examiner will want, and precisely the one you want to see first.

MFA is now the whole access surface

Section 500.12 as amended broadens the MFA obligation well past its old perimeter. The earlier rule reached remote access, privileged accounts and third-party applications. The expanded requirement pushes MFA across access to information systems by any individual, not only remote sessions and not only systems holding nonpublic information. The scoping question has inverted: it is no longer “which systems need MFA” but “which systems are exempt, and can I defend the exemption”.

The rule leaves the form of MFA open but expects a reasoned choice; NYDFS has signalled a preference for phishing-resistant factors over SMS or push. Where a covered entity cannot deploy MFA on a given system, the CISO may approve reasonably equivalent or more secure compensating controls in writing, reviewed at least annually. That written approval is not a formality — it is the artefact that stands between a legacy system and a finding. If you have systems that genuinely cannot take MFA, the deliverable is the signed, dated, annually-reviewed CISO approval, held where you can produce it on the day. Privileged accounts remain the sharpest edge here, and the access-governance bar NYDFS now sets for privileged access is where examiners have been concentrating.

Why these two arrived together

The pairing is not accidental. You cannot demonstrate MFA coverage across the access surface if you cannot enumerate the access surface, and the access surface is the asset inventory. An examiner testing 500.12 will reach for your 500.13 inventory to check whether every information system that should carry MFA does. A gap in the inventory becomes a gap in the MFA evidence automatically. The two obligations audit each other, which is why deferring both and then rushing both is the worst available strategy.

This is the same discipline other regimes now demand of the technology estate. The evidentiary posture is identical to what firms have had to build for DORA in the EU, and to the way Saudi Arabia’s PDPL expects the architecture itself to demonstrate compliance. The regulators have converged on a single expectation: the estate must be able to describe itself, on demand, and prove it keeps that description current.

What to check this week

Open the asset inventory. If the owner column contains team names rather than people, if support-expiration and RTO are mostly empty, or if there is no written statement of how often the list is validated and no record that it has been, you are not compliant with 500.13 — you have a spreadsheet wearing an inventory’s name. Then pull the list of systems with no MFA, and for each one find the signed CISO approval. The systems for which you cannot find one are your examination findings, sitting in the open, waiting for someone other than you to notice them first.