Quick answer. As of September 2026, every phased date in the Second Amendment to Part 500 has passed, and a Microsoft 365 and Entra ID tenant can carry the sections on multi-factor authentication (section 500.12), access privileges (section 500.7), encryption (section 500.15) and much of monitoring (section 500.14) once they are configured, but it does not carry them by default, and the audit trail durations in section 500.6 are longer than Microsoft’s default audit retention. Counting from the November 1, 2023 effective date, according to the Part 500 text DFS publishes, the last requirements, multi-factor authentication for any individual accessing any information system and the documented asset inventory, applied from November 1, 2025, so calendar 2026 is the first full year that the April 15, 2027 filing covers with every amended requirement in force. That filing is signed by the entity’s highest-ranking executive and its CISO and must rest on documentation sufficient to demonstrate material compliance, which is evidence the tenant holds only if someone configured it to be kept.

Every April your CISO and your highest-ranking executive sign a statement to the New York State Department of Financial Services about the prior calendar year, and IT gets the question that decides how that goes: what can the Microsoft 365 tenant actually show? The answer comes section by section. Some sections are configuration the tenant can carry once it covers everyone, one section asks for records kept longer than Microsoft keeps them by default, and several sections are program and governance duties no tenant setting satisfies. This page walks those sections in DFS’s words and Microsoft’s. Every DFS and Microsoft page cited here was read on September 24, 2026.

The regulation text quoted on this page is the Cybersecurity Requirements for Financial Services Companies text DFS publishes on its Cybersecurity Resource Center, and its first line reads “Please note this is not an official version of the Second Amendment to Part 500.” The page describes what that text says and what Microsoft documents; whether your entity is covered, exempt or a Class A company is your determination with your counsel. Microsoft’s own Title 23 NYCRR Part 500 page says “Your organization is wholly responsible for ensuring compliance with all applicable laws and regulations.”

The Phased Dates Are Behind You; the Filing Is Not

If your plan still treats the Second Amendment as a list of upcoming deadlines, the calendar has already moved past every one of them. The Cybersecurity Requirements for Financial Services Companies text says “The second amendment to this Part shall become effective November 1, 2023.” It then gives covered entities periods to comply, starting with “Covered entities shall have 180 days from the effective date of the second amendment to this Part to comply with the new requirements set forth in the second amendment to this Part” and setting different periods for named sections, from “30 days from the effective date of the second amendment to this Part to comply with the new requirements specified in section 500.17 of this Part” to “two years from the effective date of the second amendment to this Part to comply with the new requirements specified in sections 500.12 and 500.13(a) of this Part”.

The table does the arithmetic from those periods. DFS’s pages read for this page print the periods, not these calendar dates, so each date carries its label.

New requirements, as DFS’s text groups them Period in DFS’s text Date
The new requirements in section 500.17 30 days, as stated in DFS’s text December 1, 2023, counting from the November 1, 2023 effective date
The new requirements set forth in the Second Amendment, where no other period is given 180 days, as stated in DFS’s text April 29, 2024, counting from the November 1, 2023 effective date
Section 500.4, section 500.15, section 500.16 and section 500.19(a) one year, as stated in DFS’s text November 1, 2024, counting from the November 1, 2023 effective date
Section 500.5(a)(2), section 500.7, section 500.14(a)(2) and section 500.14(b) 18 months, as stated in DFS’s text May 1, 2025, counting from the November 1, 2023 effective date
Section 500.12 and section 500.13(a) two years, as stated in DFS’s text November 1, 2025, counting from the November 1, 2023 effective date

The filing is the part that recurs. The Cybersecurity Requirements for Financial Services Companies text says “Annually each covered entity shall submit to the superintendent electronically by April 15 either:” a certification of material compliance or an acknowledgment of noncompliance, and a certification “shall be based upon data and documentation sufficient to accurately determine and demonstrate such material compliance”. DFS’s most recent industry letter, Guidance on How to Conduct and Use Risk Assessments Required by the DFS Cybersecurity Regulation, dated September 10, 2026, says “This Guidance does not create new obligations.” Treat 2026 as the first year in which every amended section is in scope of the filing, and check the evidence, from access review records to audit log retention, now rather than in March.

Multi-Factor Authentication: Every Sign-In Path, Not Only the Portal

A tenant where MFA covers the Microsoft 365 portal but not an older mail protocol, a direct application login or an API connection is the gap DFS’s guidance names. Section 500.12(a) of the Cybersecurity Requirements for Financial Services Companies text says “Multi-factor authentication shall be utilized for any individual accessing any information systems of a covered entity”, and the same sentence goes on to a narrower list for an entity that qualifies for the limited exemption in section 500.19(a). Section 500.12(b) adds “If the covered entity has a CISO, the CISO may approve in writing the use of reasonably equivalent or more secure compensating controls.”

DFS’s Cybersecurity FAQs settle three questions a Microsoft 365 tenant raises. On scope: “Cloud-based email, document hosting, and related services are Information Systems that require the use of MFA.” On single sign-on: “However, SSO alone does not meet the requirements of Section 500.12.” On enforcement: “DFS expects Covered Entities to ensure that MFA enforcement is centrally managed, applies consistently to all federated and integrated systems, and cannot be bypassed through legacy logins, direct application access, or API connections that circumvent SSO controls.” The same page says “Section 500.12 does not mandate the use of any specific type of MFA.” In its answer on push notifications, which also lists safeguards such as number matching, it says “push-based MFA is not phishing-resistant”.

In Entra ID the mechanism is Conditional Access, and Microsoft puts the configuration on you. Microsoft’s Shared responsibility in the cloud page lists, under responsibilities you always retain, access management: “You’re responsible for implementing and managing access controls, including role-based access control (RBAC), multifactor authentication, and conditional access policies.” Microsoft’s Conditional Access authentication strengths page says “Administrators can specify an authentication strength to access a resource by creating a Conditional Access policy with the Require authentication strength control.” and its built-in strengths include one named “Phishing-resistant MFA”. A policy that requires MFA or an authentication strength carries section 500.12’s requirement only where it reaches every user, every app and every sign-in path; the exclusions list is where an examiner’s question lands.

A second identity provider is a second place MFA has to be enforced and kept consistent with DFS’s centrally managed expectation, and consolidating identity providers is one answer; that decision is covered on How Do I Hire Consultants to Migrate Us Off Okta Onto Microsoft Entra ID Without Breaking Access?. Which phishing-resistant methods to roll out first, and how applications that cannot use modern sign-in get MFA in front of them, are separate decisions. List every sign-in path, including service accounts and API access, and record where MFA is enforced on each.

Access Privileges, and What Class A Companies Add

The annual access review in section 500.7 is a gap in any tenant where nobody scheduled one. Section 500.7(a) of the Cybersecurity Requirements for Financial Services Companies text asks each covered entity, based on its risk assessment, to “limit the number of privileged accounts and limit the access functions of privileged accounts to only those necessary to perform the user’s job” and to “periodically, but at a minimum annually, review all user access privileges and remove or disable accounts and access that are no longer necessary”. To the extent passwords are used, section 500.7(b) asks for a written password policy that meets industry standards.

Microsoft documents the Entra ID mechanisms. Its What are access reviews? page says “User access can be reviewed regularly to make sure only the right people have continued access.” Its What is Microsoft Entra Privileged Identity Management? page says “Organizations can give users just-in-time privileged access to Azure and Microsoft Entra resources and can oversee what those users are doing with their privileged access.” and “Using Privileged Identity Management requires licenses.” Licensing for both is covered on Microsoft Entra ID Governance for Regulated Enterprises: Product Scope, Licensing, and Audit-Defensible Implementation. A review that runs and leaves no record does not help the filing: keep the completed reviews and the removals they produced.

Class A companies carry more. Section 500.7(c) of the Cybersecurity Requirements for Financial Services Companies text says “Each class A company shall monitor privileged access activity and shall implement:” “a privileged access management solution” and “an automated method of blocking commonly used passwords for all accounts on information systems owned or controlled by the class A company and wherever feasible for all other accounts”. The text names no product; whether Privileged Identity Management or a separate privileged-access vault fills that line is its own decision. Microsoft’s Eliminate bad passwords using Microsoft Entra Password Protection page says “The global banned password list is automatically applied to all users in a Microsoft Entra tenant.” and “When users change or reset their passwords, these banned password lists are checked to enforce the use of strong passwords.” Set against section 500.7(c), that is Microsoft’s documented behavior at password change or reset for users in the tenant; accounts on systems that do not use those passwords are still in the text’s reach.

Section 500.1 of the Cybersecurity Requirements for Financial Services Companies text says “Class A company means a covered entity with at least $20,000,000 in gross annual revenue in each of the last two fiscal years”, goes on to say which affiliates’ operations count toward that revenue, and then sets two alternatives, the first being “over 2,000 employees averaged over the last two fiscal years, including employees of both the covered entity and all of its affiliates no matter where located” and the second a revenue test. Whether your entity is a Class A company is a determination for your entity and its counsel; this page quotes the test and stops. Schedule the access review, keep its record, and decide which accounts Privileged Identity Management covers before the next filing.

Audit Trail: Where Microsoft’s Defaults Are Shorter Than the Text

A certification signed on a tenant whose audit records rolled off months ago is the failure this section exists to prevent. Section 500.6(a) of the Cybersecurity Requirements for Financial Services Companies text reads “(a) Each covered entity shall securely maintain systems that, to the extent applicable and based on its risk assessment:” and its second item is systems that “include audit trails designed to detect and respond to cybersecurity events that have a reasonable likelihood of materially harming any material part of the normal operations of the covered entity”. Section 500.6(b) then says each covered entity “shall maintain records required by paragraph (a)(1) of this section for not fewer than five years and shall maintain records required by paragraph (a)(2) of this section for not fewer than three years.”

Microsoft Learn documents shorter defaults. Its Learn about auditing solutions in Microsoft Purview page says “In Audit (Standard), the system retains records for 180 days, which means you can search for activities that occurred within the past six months.” Its Manage audit log retention policies page says the Audit (Premium) default policy “retains all Exchange Online, SharePoint, OneDrive, and Microsoft Entra audit records for one year.” and “To retain audit logs for 10 years, the user who generates the audit log must also have a 10-year audit log retention add-on license in addition to an E5 license.” Microsoft Learn adds, of that ten-year policy, “This policy isn’t retroactive and can’t retain audit logs that were generated before the 10-year audit log retention policy was created.” Its Microsoft Entra data retention page says “Microsoft Entra ID audit and sign-in logs are separate from the Microsoft 365 Unified Audit Log (UAL).”

The Microsoft 365 audit log is not automatically your section 500.6 audit trail; your risk assessment decides what the audit trail includes. If it places Microsoft 365 or Entra ID records inside the section 500.6(a)(2) audit trail, the default retention is shorter than the three years for those records, as stated in section 500.6(b) of the Part 500 text. How to export and keep Entra audit and sign-in logs past their own retention is a separate how-to. Decide the retention route before records roll off, because a retention policy created later does not bring back the months already lost.

Asset Inventory, Encryption and Monitoring

If your section 500.13 inventory is a device list exported from Intune, it is missing fields the text asks for. Section 500.13(a) of the Cybersecurity Requirements for Financial Services Companies text asks for written policies and procedures designed to “produce and maintain a complete, accurate and documented asset inventory of the covered entity’s information systems”, tracking for each asset, as applicable, its owner, location, classification or sensitivity, “support expiration date” and recovery time objectives, plus how often the inventory is updated and validated. Microsoft’s See device details in Microsoft Intune page says “The Devices feature provides more details about the devices you manage, including their hardware and the apps installed.” That is one input; the owner, classification, support expiration and recovery fields, and the systems that are not managed devices, come from your own records.

Encryption is on in Microsoft 365, and the decisions around it stay yours. Microsoft’s Encryption page says “With Microsoft 365, your data is encrypted at rest and in transit” and its Shared responsibility in the cloud page keeps with the customer, under data, “You’re responsible for your data, including data classification, data protection, encryption decisions, and compliance with data governance requirements.” Section 500.15(a) of the Part 500 text asks for a written policy requiring encryption that meets industry standards, “to protect nonpublic information held or transmitted by the covered entity both in transit over external networks and at rest”. The written policy is what a reviewer reads; the tenant’s default encryption is what the policy describes.

For monitoring, section 500.14(a) asks every covered entity for risk-based controls to monitor the activity of authorized users, controls against malicious code, and at least annual cybersecurity awareness training. Section 500.14(b) of the Cybersecurity Requirements for Financial Services Companies text asks each Class A company, unless the CISO has approved compensating controls in writing, for “an endpoint detection and response solution to monitor anomalous activity, including but not limited to lateral movement” and “a solution that centralizes logging and security event alerting”. Microsoft documents its own products for both lines: the Overview of endpoint detection and response page says “Endpoint detection and response capabilities in Defender for Endpoint provide advanced attack detections that are near real-time and actionable.” and the What is Microsoft Sentinel security information and event management (SIEM)? page says “Microsoft Sentinel is a cloud-native SIEM solution”. Which solution you name for section 500.14(b), and who watches its alerts, is your decision.

The Checklist, in One Table

The table below is the section-by-section map to hold against the tenant before the filing. Each row rests on the DFS text and the Microsoft pages quoted above.

DFS section Microsoft 365 or Entra ID feature Microsoft documents Not on by default, or needs a licence Evidence to keep, as an export or record
Section 500.12, multi-factor authentication for any individual accessing any information system Conditional Access requiring MFA or an authentication strength Enforced only where policies reach every user, app and sign-in path Policy exports, the exclusions list, and the CISO’s written approval of any compensating control
Section 500.7(a), least privilege and an access review at least annually Access reviews; Privileged Identity Management Reviews run only when scheduled; Privileged Identity Management requires licenses Completed review records and the removals they produced
Section 500.7(b), a written password policy where passwords are used Microsoft Entra Password Protection supports the policy The written policy is not a tenant setting The approved written policy
Section 500.7(c), Class A: privileged access monitoring, a privileged access management solution, blocking commonly used passwords Privileged Identity Management; the global banned password list Banned-list checks run at password change or reset, for users in the tenant Privileged access activation history, password protection settings, and any CISO written approval of infeasibility
Section 500.6, audit trail records kept for the periods the text sets, where applicable Microsoft Purview Audit Microsoft Learn documents Audit (Standard) and Audit (Premium) default retention shorter than section 500.6(b) sets, and ten-year retention that needs an add-on license and is not retroactive; Entra ID logs are separate The retention policy, exported records, and the risk-assessment decision on what the audit trail includes
Section 500.13(a), a documented asset inventory Microsoft Intune device details Intune does not track owner, classification, support expiration date or recovery time objectives The inventory with the fields the text lists, and its update frequency
Section 500.14(a), monitoring authorized users, malicious-code controls, annual training Microsoft Purview Audit records user and admin activity Training and several controls are program work, not tenant settings Monitoring configuration and training records
Section 500.14(b), Class A: endpoint detection and response, centralized logging and alerting Microsoft Defender for Endpoint; Microsoft Sentinel Separate products and licensing decisions Deployment coverage, or the CISO’s written approval of compensating controls
Section 500.15, encryption in transit and at rest under a written policy Microsoft 365 encryption at rest and in transit Encryption decisions and the written policy stay yours The written encryption policy and any CISO-approved compensating controls
Section 500.17(b), the annual filing and its supporting records Microsoft Purview Compliance Manager premium template An assessment view is not the filing Every record supporting the certification or acknowledgment, kept for the period the text sets

For the last row, the Cybersecurity Requirements for Financial Services Companies text asks each covered entity to maintain “all records, schedules and other documentation and data supporting the certification or acknowledgment for a period of five years”, and DFS’s Cybersecurity FAQs say “Covered Entities do not need to send supporting documentation when they submit a Certification of Material Compliance”. The records stay with you, and they have to exist when someone asks for them.

What the Tenant Does Not Carry

A configuration project scoped to all of Part 500 spends money on sections a Microsoft tenant cannot hold. Five limits apply.

  • Program, governance and people duties, such as the cybersecurity program, policies, governance, the risk assessment, the third-party service provider policy, incident response and notices, are supported by tenant configuration and not satisfied by it; Microsoft’s Title 23 NYCRR Part 500 page puts responsibility on your organization, and its shared-responsibility page keeps data and access decisions with you.
  • Application security under section 500.8, for in-house and external applications, sits outside the tenant; choosing who builds and secures those applications is covered on How to Choose a Custom App Development Firm for Financial Services.
  • A broker-dealer’s books-and-records retention is a different rule from the section 500.6 audit trail and is not covered here.
  • If your entity may qualify for an exemption under section 500.19, which sections apply changes; DFS’s Cybersecurity Requirements for Regulated Entities page says the sections that apply depend on whether an entity qualifies for an exemption or is a Class A company, and that determination is your entity’s.
  • A Compliance Manager assessment is a view of configured controls, not the filing. Microsoft’s Title 23 NYCRR Part 500 page says “Compliance Manager offers a premium template for building an assessment for this regulation.” and its Compliance Manager regulations list includes “New York – 23 NYCRR Part 500”; for customers at the A5, E5 and G5 subscription levels it says “In addition to the Microsoft Data Protection baseline, you can choose any three premium regulations to use for free.”

DFS also keeps responsibility where it sits when the CISO is not an employee: its Cybersecurity FAQs say “If the Covered Entity’s CISO is employed by a Third-Party Service Provider or an Affiliate, the Covered Entity retains responsibility for compliance with the Cybersecurity Regulation”.

What to Require From Whoever Configures It

Before you choose who configures the tenant, decide what it must leave behind: the audit records and review exports that have to exist in April. Hold any team, internal or external, to these criteria.

  • Require a section-by-section map like the table above, with the export, log or record named for each row.
  • Require each export and review record to be kept as it is produced, not rebuilt at filing time.
  • Require the audit retention route to be decided before records roll off.
  • Require every sign-in path to be enforced centrally, including service accounts and API access.
  • Require people who have done identity work in regulated financial services, and senior, US-based delivery.
  • Require a plain statement that the filing is signed by your highest-ranking executive and your CISO, and that no configuration signs it for them.

How i3solutions approaches Microsoft 365 compliance implementations across regulated sectors is set out on Microsoft 365 Compliance Consulting: CMMC, HIPAA, SOC 2, and NIST for Regulated Enterprises.

How i3solutions Answers

If you need Microsoft 365 and Entra ID configured to carry the sections a tenant can carry, and the evidence file behind the filing produced, that is project work i3solutions delivers under Embedding Governance into How the Enterprise Operates and Scales. i3solutions has deep experience implementing identity governance for enterprises in aerospace and defense manufacturing, financial services, and healthcare, including environments with CMMC and ITAR obligations. i3solutions governs identity and access for regulated Microsoft estates with senior, U.S.-based engineers and leaves an audit-defensible record. i3solutions maps governance to named control families, enforces it in the platform through Entra ID, Purview, and Azure Policy, and evidences it continuously rather than reconstructing it at audit.

i3solutions has done hundreds of Okta to Entra ID conversions. That migration work is regular delivery for enterprises, and financial services is among the regulated sectors where i3solutions delivers it. Microsoft 365 compliance implementations by i3solutions span defense, healthcare and financial services environments. i3solutions has been a Microsoft partner since 1997 and has delivered 600+ implementations across aerospace and defense, financial services, and health sciences. i3solutions teams maintain dedicated compliance specialists who understand CMMC, HIPAA, SOC 2, and financial services regulations within Microsoft environments, providing audit trail documentation and access control frameworks that reduce audit preparation time by 60%. Where your team needs more hands, i3solutions can embed IAM and compliance specialists in it. The people who do the work are senior and US-based.

Two boundaries stay where the regulation and the engagement model put them. The certification or acknowledgment is signed by your highest-ranking executive and your CISO, and coverage, exemption and Class A questions are your entity’s to determine with counsel. i3solutions configures monitoring tools as project work and does not run SOC monitoring or alert handling as an ongoing managed security operations service.

Key Takeaways

  • Every phased Second Amendment date has passed, so the filing due April 15, 2027 covers the first full calendar year with every amended requirement in force.
  • DFS says cloud email and document hosting require MFA and that single sign-on alone does not meet section 500.12; enforce MFA on every sign-in path.
  • According to the Part 500 text DFS publishes, section 500.6 sets three and five years for audit trail records where they apply, and Microsoft’s default audit retention is shorter; decide retention before records roll off.
  • Class A companies add privileged access management, blocking of commonly used passwords, endpoint detection and response, and centralized logging; the Class A determination is the entity’s.
  • The filing rests on documentation the entity keeps; no tenant setting, score or report signs it.

Frequently Asked Questions

Does Part 500 require MFA for Microsoft 365?

Yes, unless a limited exemption narrows it. According to the Part 500 text DFS publishes, section 500.12(a) says “Multi-factor authentication shall be utilized for any individual accessing any information systems of a covered entity”, and DFS’s Cybersecurity FAQs say “Cloud-based email, document hosting, and related services are Information Systems that require the use of MFA.”

Is single sign-on through Entra ID enough for NYDFS MFA?

Not on its own. DFS’s Cybersecurity FAQs say “However, SSO alone does not meet the requirements of Section 500.12.” and “DFS expects Covered Entities to ensure that MFA enforcement is centrally managed, applies consistently to all federated and integrated systems, and cannot be bypassed through legacy logins, direct application access, or API connections that circumvent SSO controls.”

How long does Part 500 require audit trail records to be kept, and how long does Microsoft 365 keep them?

According to the Part 500 text DFS publishes, section 500.6(b) says each covered entity “shall maintain records required by paragraph (a)(1) of this section for not fewer than five years and shall maintain records required by paragraph (a)(2) of this section for not fewer than three years.” Microsoft Learn says “In Audit (Standard), the system retains records for 180 days, which means you can search for activities that occurred within the past six months.” and that the Audit (Premium) default policy “retains all Exchange Online, SharePoint, OneDrive, and Microsoft Entra audit records for one year.” Microsoft Learn also says “To retain audit logs for 10 years, the user who generates the audit log must also have a 10-year audit log retention add-on license in addition to an E5 license.”

Does Entra ID’s banned password list meet the Class A requirement to block commonly used passwords?

This page sets Microsoft’s documented behavior beside DFS’s text and does not answer yes or no. According to the Part 500 text DFS publishes, section 500.7(c) asks a Class A company for “an automated method of blocking commonly used passwords for all accounts on information systems owned or controlled by the class A company and wherever feasible for all other accounts”. Microsoft Learn says “The global banned password list is automatically applied to all users in a Microsoft Entra tenant.” and “When users change or reset their passwords, these banned password lists are checked to enforce the use of strong passwords.”

When did the last Second Amendment requirements take effect?

On November 1, 2025, counting from the November 1, 2023 effective date. According to the Part 500 text DFS publishes, “The second amendment to this Part shall become effective November 1, 2023.” and covered entities had “two years from the effective date of the second amendment to this Part to comply with the new requirements specified in sections 500.12 and 500.13(a) of this Part”.

Who signs the annual Part 500 filing?

The entity’s highest-ranking executive and its CISO. According to the Part 500 text DFS publishes, “Annually each covered entity shall submit to the superintendent electronically by April 15 either:” a certification or an acknowledgment, and it “shall be signed by the covered entity’s highest-ranking executive and its CISO”.

Planning the Audit Evidence Before the Next Filing

If your team needs a section-by-section review of what your Microsoft 365 and Entra ID tenant carries under Part 500, and of the audit and access review records it keeps, before the next annual filing, the next step is a conversation about your tenant and your evidence file.

Contact a senior architect