What is the difference between encryption at rest and encryption in transit under NYDFS Part 500?

Encryption at rest protects stored nonpublic information on disks, databases, or backups. Encryption in transit protects data moving across networks, especially external networks. Part 500 treats them differently because in-transit encryption has no compensating-control path for external network traffic, while at-rest encryption may use written CISO-approved compensating controls if encryption is infeasible.

Why the distinction matters under Part 500

Under nydfs part 500, the difference is not just technical wording. encryption in transit is aimed at protecting nonpublic information while it moves across networks, where interception and unauthorized access are direct concerns. Encryption at rest addresses stored data, where the main issue is exposure from lost media, stolen backups, database access, or unmanaged file systems.

That distinction affects compliance decisions because Part 500 treats external network traffic more strictly than stored data. If information crosses an external network, encryption is the expected baseline rather than an optional design choice. For stored data, the rule is more flexible when encryption is infeasible, but only if a CISO-approved compensating control is documented and defensible.

For teams that handle regulated data, the practical issue is not whether encryption exists somewhere in the stack, but whether it is applied at the right layer and can be shown to cover the actual data path. In practice, many organisations discover the gap only after a network path or storage exception has already been relied on in production.

How Part 500 applies the two controls in practice

Encryption in transit usually means protecting data as it moves between endpoints, such as application traffic, API calls, remote administration sessions, and file transfers. In a Part 500 context, the key question is whether the traffic traverses an external network. If it does, encryption is expected because the data is exposed to interception outside the organisation’s direct control.

Encryption at rest applies once information is stored on disks, in databases, in object storage, or in backups. The control objective is different: it reduces the impact of unauthorized access to stored information, including access through theft, misconfiguration, insider misuse, or compromise of the storage layer. Where encryption cannot be implemented, Part 500 allows a written compensating control path, but that path must be approved at the CISO level and should explain why encryption is infeasible, not merely inconvenient.

Use transport encryption for data moving across untrusted or external network segments.
Use storage encryption for databases, file systems, backups, snapshots, and exported data sets.
Document any at-rest exception with a specific infeasibility rationale and compensating safeguard.
Verify that key management, access control, and logging support the protection you claim.

This maps closely to general security control practice as described in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where cryptographic protection, access control, and auditability are expected to work together. For NHI-heavy environments, the same issue often shows up in secrets, service accounts, and API keys that are stored or transmitted as part of machine-to-machine workflows, which is why NHI governance remains relevant to encryption scope. The NHIMG overview at Ultimate Guide to NHIs — What are Non-Human Identities is useful when the encryption boundary includes machine credentials and automated systems.

These controls tend to break down when organisations assume TLS alone covers all exposure, while backups, exports, replicas, and service-to-service traffic remain outside the intended encryption boundary.

Common edge cases and where teams get it wrong

Tighter encryption coverage often increases operational overhead, so organisations have to balance compliance certainty against performance, key-management complexity, and legacy-system constraints.

One common mistake is treating “data protected somewhere” as equivalent to “data protected everywhere.” A database may be encrypted at rest while application logs, exports, message queues, or replication streams remain unprotected. Another common error is assuming internal traffic is automatically exempt. Part 500’s external-network emphasis means the location and trust boundary of the traffic matter, not just the protocol used.

There is also a practical distinction between policy and evidence. A security team may be able to state that encryption exists, but examiners usually want to see configuration, architecture, exception handling, and approval records that show the control is actually in force. Where encryption is infeasible at rest, the compensating control should be narrow, documented, and periodically revalidated rather than left as a permanent shortcut.

In current guidance, the safest interpretation is that transit encryption is the default expectation for exposed data flows, while at-rest encryption may be substituted only under a justified exception process. The difference matters most when legacy platforms, third-party integrations, or backup architectures make the real data path broader than the design diagram suggests.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.DS — Data Security	Encryption at rest and in transit are core data protection mechanisms.
	GV.RM — Risk Management Strategy	Part 500 exceptions and compensating controls are governed as risk decisions.
Recommendation — Apply PR.DS to protect stored and moving data with encryption and related safeguards. Use GV.RM to document encryption exceptions and approve compensating controls as risk decisions.
CIS Controls v8	3 — Data Protection	CIS Control 3 covers protecting data at rest and in transit with encryption and key handling.
Recommendation — Use CIS Control 3 to enforce encryption and protect sensitive data across storage and transport.
NIST SP 800-63	5 — Authenticator and Verifier Requirements	Part 500 transit protection often intersects with authenticated machine-to-machine exchange.
Recommendation — Apply SP 800-63 verifier requirements where protected transport depends on authenticated exchanges.
NIST Zero Trust (SP 800-207)	SC-7 — Boundary Protection	Transit encryption depends on trust boundaries and network path protection.
Recommendation — Use SC-7 to enforce protected boundaries for sensitive traffic crossing untrusted networks.

Practitioner Guidance

What to verify: Confirm which data flows actually cross external networks, then test whether those paths are encrypted end to end rather than assuming application-level intent is enough.

Decision rule: If the control exception is for stored data, require a written infeasibility statement and CISO approval; if the risk is network transit, treat encryption as mandatory rather than exception-driven.

What practitioners underestimate: Backups, replicas, logs, and machine-to-machine transfers often create the real exposure, so the compliance answer depends on the full data lifecycle, not the primary system only.

Practitioner takeaway: The critical judgment under Part 500 is to classify the data path correctly first, because the compliance burden changes once information leaves a trusted boundary or becomes a stored asset with an exception claim attached.