NYDFS Part 500 and End-of-Life Systems: The Asset Inventory Rule, and How to Show It

By Scott Bissett  ·  Last updated: October 31, 2026  ·  For IT, security and compliance teams at DFS-regulated banks, insurers and financial services companies, and the MSPs that serve them

The New York DFS cybersecurity regulation (23 NYCRR Part 500) now expects your asset inventory to carry the date each system's vendor support ends. Since November 1, 2025, section 500.13(a) has required each covered entity to keep written policies and procedures for a complete, accurate and documented asset inventory of its information systems, with a method to track, for each asset and as applicable, its owner, location, classification or sensitivity, support expiration date and recovery time objectives, and a set frequency for updating and validating the inventory. "Support expiration date" is the regulation's own term; the phrase "end of life management" appears once, in the list of areas the cybersecurity policy must cover (500.3(c)). Part 500 does not name a product or ban old software. What the inventory field does is make every unsupported system visible, and from there it has to show up in the risk assessment (500.9), in vulnerability management (500.5), in the CISO's annual report to the board (500.4(b)) and, by April 15 each year, in the certification of compliance or the acknowledgment of noncompliance the entity files with DFS (500.17(b)).

What section 500.13(a) says

Section 500.13 is headed "Asset management and data retention requirements". Subsection (a), added by the Second Amendment to Part 500, reads in substance:

• As part of its cybersecurity program, each covered entity must implement written policies and procedures designed to produce and maintain a complete, accurate and documented asset inventory of its information systems, and maintain the inventory in accordance with them.
• At a minimum, those policies and procedures must include (1) a method to track key information for each asset, including, as applicable, (i) owner, (ii) location, (iii) classification or sensitivity, (iv) support expiration date and (v) recovery time objectives; and (2) the frequency required to update and validate the inventory.

Three details in that wording matter in practice. The rule regulates your policies and procedures for the inventory, so an examiner will look at the written method as well as the spreadsheet or CMDB it produces. "As applicable" lets you leave a field empty where it genuinely does not apply, which is not the same as not knowing it. And "information system" is defined broadly in 500.1(i): any discrete set of electronic information resources, explicitly including specialized systems such as industrial and process controls, telephone switching and private branch exchange systems, and environmental control systems. The building management server and the old PBX are in scope.

Subsection (b), the other half of 500.13, is about securely disposing of nonpublic information that is no longer needed. It predates the amendment and is not the subject of this guide.

Where "end of life" appears

Section 500.3 requires a written cybersecurity policy, approved at least annually by a senior officer or the senior governing body, that addresses a list of areas based on the risk assessment. Since the Second Amendment, item (c) on that list is "asset inventory, device management and end of life management" (23 NYCRR 500.3(c)). DFS's implementation timeline describes end of life management as "phasing out unsupported technical products with weaknesses" (DFS, Cybersecurity Implementation Timeline). So the policy states how you retire or contain unsupported technology, and the inventory's support expiration date field tells you where that policy applies.

Who it applies to, and from when

Part 500 applies to every "covered entity": any person operating, or required to operate, under a license, registration, charter, certificate, permit, accreditation or similar authorization under New York's Banking Law, Insurance Law or Financial Services Law (500.1(e)). That takes in state-chartered banks, licensed branches of foreign banks, insurers, insurance agents and brokers, mortgage companies, money transmitters and virtual currency businesses licensed by DFS, among others. The Second Amendment took effect on November 1, 2023 (500.21(b)), and section 500.22 phased its new requirements in. The rows below are the sections that decide how end-of-life systems are handled.

Small businesses: the asset inventory still applies

The section 500.19(a) limited exemption covers a covered entity with fewer than 20 employees and independent contractors (counting its affiliates), or less than $7,500,000 in gross annual revenue in each of the last three fiscal years (counting its own business operations and its affiliates' business operations in New York), or less than $15,000,000 in year-end total assets including affiliates. It exempts such an entity from sections 500.4, 500.5, 500.6, 500.8, 500.10, 500.14(a)(1), (a)(2) and (b), 500.15 and 500.16. Section 500.13 is not on that list, and DFS's own requirements table puts "Asset inventory and data retention requirements (500.13)" among the sections a small business must comply with. A five-person insurance agency needs a written asset inventory method that tracks support expiration dates, just as a bank does; it is spared the vulnerability management section, not the inventory.

Class A companies: extra controls, same inventory

A Class A company (500.1(d)) is a covered entity with at least $20,000,000 in gross annual revenue in each of the last two fiscal years from its business operations and its affiliates' New York operations, and either over 2,000 employees averaged over the last two fiscal years or over $1,000,000,000 in gross annual revenue in each of them, counting affiliates as the definition specifies. Section 500.13 asks nothing extra of them. Their additional requirements sit elsewhere: independent audits of the cybersecurity program (500.2(c)), privileged access management and blocking of commonly used passwords (500.7(c)), and endpoint detection and response plus centralized logging and security event alerting (500.14(b)). Those tools are only as complete as the inventory that tells you which endpoints exist and which of them their vendor still supports.

How an unsupported system flows through Part 500

The support expiration date is one field. The rest of the regulation tells you what to do once it is in the past.

• Risk assessment (500.9). The assessment has to consider the information systems in use and the availability and effectiveness of controls, and its written procedures must say how identified risks are mitigated or accepted. A system past its vendor's support date is a risk to identify, rate and treat. A product reaching its end date is also a change in technology; if it materially changes your cyber risk, 500.9(a) calls for an update without waiting for the annual cycle.
• Vulnerability management (500.5). Automated scans find missing patches on supported software. On an unsupported system there may be no patch to find, which is why the inventory date matters: scans and the monitoring process tell you about new vulnerabilities, and 500.5(c) requires timely remediation prioritized by risk. Systems the scanners do not reach, which often includes legacy and specialized systems, need the manual review 500.5(a)(2) requires.
• Access privileges (500.7). Older systems are where remote control protocols, shared administrator accounts and missing access reviews tend to survive. 500.7(a)(5) requires all protocols that permit remote control of devices to be disabled or securely configured.
• Compensating controls in writing. Where an old system cannot do what the rule requires, Part 500 sometimes lets the CISO approve reasonably equivalent or more secure compensating controls in writing: for multi-factor authentication (500.12(b), reviewed at least annually) and for encryption of nonpublic information at rest (500.15(b), reviewed at least annually). A legacy application that cannot take modern authentication needs that written approval, not silence.
• The CISO's report (500.4(b)). Material cybersecurity risks and plans for remediating material inadequacies go to the board in writing at least annually. A core banking or policy administration platform past its support date, with no paid extended support, is the kind of item that belongs there with a plan and a date.
• Third-party service providers (500.11). Systems your vendors run with your nonpublic information sit outside your inventory but inside your risk. The minimum cybersecurity practices you require of them, and your periodic assessments, are where to ask whether the software they run for you is within vendor support.

What DFS has said about asset inventories

Risk assessment guidance (September 10, 2026)

DFS's industry letter of September 10, 2026, on how to conduct and use the risk assessments Part 500 requires, says it creates no new obligations, but it is the clearest statement of what DFS examiners look for. Among the common gaps DFS reports finding in examinations and investigations is "outdated or incomplete asset inventories" (DFS, risk assessment guidance). The letter says the inventory 500.13(a) requires should be the foundational input to the risk assessment, that a failure to account for assets gives an incomplete view of risk, and that entities should be able to show how the risk assessment informed control selection, compensating controls and risk acceptance. It recommends a risk register or comparable tracking process linking each identified risk to the controls that mitigate it, with the justification recorded whenever management accepts a risk.

The PHP alert (October 22, 2026)

On October 22, 2026 DFS sent regulated entities a cybersecurity alert about two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619 (the flaws behind PHP2Shell). Its first step was to identify affected systems: determine whether PHP is used across the organization, including internet-facing applications, and check with third-party service providers. For systems that cannot be patched promptly, it told entities to take them offline until appropriately secured. Both steps assume an inventory that records software versions and whether the vendor still supports them; a PHP branch past its end of life is exactly the system for which "apply the available update" may not be an option.

Enforcement: Order Express

On August 5, 2026 DFS announced that Order Express, Inc., a licensed money transmitter, would pay a $250,000 penalty under Part 500. The consent order, which applies the regulation as it read before the Second Amendment, found that the company's risk assessment did not consider cybersecurity risks specific to the company or the adequacy of its controls (500.9(a) and 500.2(b)), and that its policies and procedures for application and system updates, including patch deployment, covered only a small number of the third-party applications and software products it used, leaving it exposed to known vulnerabilities (500.3(g)). The investigation followed a ransomware attack on the company in 2022. Order Express qualified for the 500.19(a) limited exemption throughout, which did not protect it: the exemption does not reach the risk assessment or the cybersecurity policy. The order does not cite 500.13(a), which was not yet in force for the period it covers, but the failure it describes, update procedures that did not cover all the software in use, is the gap a complete inventory with support dates is meant to close.

What an examiner will ask for

Expect to be asked for documents, not assurances. For end-of-life systems, have ready:

• the written asset management policy and procedures required by 500.13(a), naming the fields tracked and the frequency for updating and validating the inventory;
• the inventory itself, showing for each asset its owner, location, classification or sensitivity, support expiration date and recovery time objective, and evidence that it was updated and validated on schedule;
• the cybersecurity policy, with its annual approval, addressing end of life management (500.3(c));
• the risk assessment and risk register entries for each asset past its support expiration date, with the controls applied or the documented risk acceptance and its justification;
• vulnerability scan results and the manual reviews of systems the scans do not cover (500.5(a)(2)), and remediation records showing risk-based priority (500.5(c));
• any written CISO approvals of compensating controls (500.12(b), 500.15(b)) for systems that cannot meet a requirement directly;
• the CISO's written report to the board, with the unsupported systems that are material risks and the plans to remediate them (500.4(b));
• proof that paid extended support is current where you rely on it: contracts, subscriptions and update history;
• the records behind the April 15 certification or acknowledgment, kept for five years (500.17(b)(3)).

The annual filing

Under 500.17(b), the certification of material compliance must be based on data and documentation sufficient to demonstrate it. If your inventory could not show support expiration dates across the prior calendar year, the regulation provides the other route: an acknowledgment of noncompliance that identifies each section not materially complied with, describes the nature and extent of the gap, and gives a remediation timeline or confirms remediation is complete. DFS's FAQ names a missing risk assessment as one example of material noncompliance requiring an acknowledgment. Because 500.13(a) applied only from November 1, 2025, the filing for calendar year 2026 is the first to cover a full year of it.

A worked example: what banks and insurers still run

Here is how products common in New York banks, insurers and their service providers look in the support expiration date column today. The dates and status badges in this table are refreshed from our lifecycle data at every build, so they stay current when a vendor moves a date.

Three patterns cover most estates. Assets past their support expiration date with no paid program need a high risk rating, compensating controls and a dated plan to go, all in the risk register. Assets past the vendor's standard date but under a paid program (ESU, Extended Life Cycle Support, Extended Support) still receive fixes, which is a legitimate control while the contract is current; record the program's own end date alongside. And assets whose date is announced but not yet reached need the decision recorded before it arrives, so the risk assessment update on that day finds a plan already in place.

How to fill the support expiration date field automatically

Most inventories already know the product and version of each asset. What they lack is the date, kept current: vendors move dates, add paid extensions and publish new end-of-support notices every month, and a field typed in once goes stale. endoflife.ai publishes end-of-life dates for 700+ products, and every answer names the source of its date.

1. The API, with a free key

Look up any product and version and get the status, the end-of-life date, days remaining or days past, and the source URL of the date. Get a free API key (emailed, no credit card); the API documentation covers batch lookups for a whole inventory export.

curl -H "X-API-Key: YOUR_KEY" https://api.endoflife.ai/v1/status/windows-server/2016

The response includes status, eol_date, days_past_eol, eol_date_source and eol_date_source_url. Writing eol_date into the support expiration date field and keeping the source URL beside it answers the examiner's next question, where the date came from. Run it on the schedule your 500.13(a)(2) procedure sets for updating and validating the inventory.

2. The scanner and SBOM check

Upload a CycloneDX or SPDX SBOM, or a package manifest, to the scanner for a one-off report of what in it has reached end of life. It suits the SBOM an application vendor or service provider gives you, and the runtimes, frameworks and libraries an inventory of installed programs misses, such as the PHP branch under a customer portal. How to audit an SBOM for end-of-life software explains the method, and unsupported software detection covers the wider approach.

3. Your PSA, RMM or monitoring tool

MSPs serving several regulated clients usually hold the inventory already. The HaloPSA integration writes end-of-life dates and their sources onto assets and can open a ticket for each asset past end of life, so every client's risk register item has an owner. Zabbix, Splunk, Datadog, Dynatrace, Grafana, a GitHub Action and an MCP server for AI assistants are on the integrations page. For the policy that 500.3(c) requires, the free EOL policy template sets remediation deadlines and an exception process you can adapt, and the MSP end-of-life audit walks through a client review.

Frequently Asked Questions

Sources

Read for this guide on October 30, 2026. DFS publishes the amended regulation as a PDF that it labels an unofficial version for identifying the changes; the official text is the New York Codes, Rules and Regulations on Westlaw, which did not answer our automated reads, so section text was checked against the Cornell Legal Information Institute's copy of the official NYCRR (which notes the 2023 amendment) as well as the DFS PDF.

• DFS, Second Amendment to 23 NYCRR 500 (the text DFS links as Part 500).
• 23 NYCRR 500.13, 500.3, 500.5, 500.17, 500.19, 500.21 and 500.22 (Cornell LII copy of the NYCRR).
• DFS, Cybersecurity Requirements for Regulated Entities and FAQs about the Cybersecurity Regulation.
• DFS implementation timelines: covered entities and Class A companies.
• DFS industry letters: Guidance on How to Conduct and Use Risk Assessments, Critical Vulnerabilities in PHP that Require Immediate Patching and Measures in a Heightened Cybersecurity Threat Environment.
• DFS, press release and consent order, Order Express, Inc.

Related Resources

• PCI DSS and end-of-life software: what Requirement 12.3.4 asks for
• HIPAA and end-of-life software
• DORA and legacy ICT systems
• Cyber Essentials and unsupported software
• How to Build a Software EOL Management Program That Survives an Audit
• The MSP end-of-life audit
• Every Windows Server version and its end-of-support date
• EOL Watch: lifecycle date changes, tracked as they happen