Ring's new default encryption does not make cloud processing disappear. It puts that processing behind a new key system, gives Ring's cloud a copy of each short-lived video key for up to 24 hours, and then deletes that copy. Your devices keep their keys.
That is meaningfully different from Ring's current default protection. It is also not end-to-end encryption. Under optional E2EE, Ring says its cloud member is removed from the camera's encryption group and never receives the video keys in the first place.
So the useful question is not, “Are my Ring videos encrypted?” Both paths encrypt them. The question is: who can decrypt a clip, for how long, and which features do you refuse to give up?
Rechecked September 1, 2026 for US Ring camera owners. TAKE is rolling out in phases starting this month and becomes the worldwide default only after the rollout is complete. Ring has not published a completion date. If your app has not invited you to enroll, do not assume the new architecture is already protecting that camera.
TAKE and E2EE draw the line in different places
| Choice | Who gets video keys? | Cloud features | The honest privacy boundary | | --- | --- | --- | --- | | Current default, before TAKE enrollment | Ring encrypts video in transit and at rest | Current account features | Do not describe this as TAKE until the app says the camera is enrolled | | TAKE | Your enrolled devices, plus a scoped Ring cloud member for active features | Designed to keep the full Ring feature set | Ring can temporarily decrypt video for enabled processing; its key copy is deleted on a rolling 24-hour schedule | | E2EE | Your enrolled devices; no Ring cloud member | Features that require Ring to process decrypted video are unavailable | Ring stores and transports encrypted video but says it cannot decrypt it, even temporarily |
The middle row is the new compromise. TAKE aims to keep Video Search, Smart Video Descriptions, Smart Alerts and Shared Users while sharply limiting how long Ring can independently process a recording. E2EE draws the harder line and accepts a smaller feature set.
Neither choice is automatically right for every camera. An outdoor doorbell used by several family members may need shared access and rich alerts. An indoor camera pointed at a private room may justify giving up more convenience. Ring says the setting can be managed per camera, so one household does not have to force every device into the same answer.
What “delete the key after 24 hours” actually means
Ring's August 26 white paper adds detail that the announcement leaves out.
Under TAKE, each camera belongs to a Messaging Layer Security group. Video content keys are derived in five-minute intervals. A cloud member holds the material needed to derive those keys inside AWS Nitro Enclaves, and Ring says feature services receive a key only when an active feature needs it. The key stays in the service's software boundary, is not written to disk, and is cleared from memory after processing.
Deletion is continuous rather than one midnight purge. As each key passes 24 hours, Ring says its service ratchets the underlying secret forward with a one-way function, discards the older value and keeps no database backup from which to rebuild it. Customer devices retain their own keys, so you can still watch an older recording.
There is an important second sentence. If you later choose an action that needs cloud processing — playing an older clip with connection-specific optimization, sharing it, or asking a feature to analyze older footage — the Ring app can push the needed key back to that service. Ring says this is initiated by your app, cannot be pulled by the cloud on its own and is discarded when the processing session ends.
In plain English: after 24 hours, TAKE is designed to stop Ring from independently opening an old clip with a retained cloud key. It does not promise that an old clip will never be temporarily processed again when you actively use a cloud-dependent function. E2EE is the option that keeps Ring out of the decryption path altogether.
This explanation comes from Ring's own architecture paper, not an independent audit. The paper describes access controls, enclave isolation, logging and irreversible deletion as designed. It does not prove from outside Ring that every production system behaves exactly that way.
Today's E2EE page lists 22 missing functions
Ring's current English-language support page names 22 features and functions that are unavailable on a camera enrolled in E2EE. Counted directly from that list, they break down like this:
| What changes today | Functions on Ring's current list | | --- | --- | | Sharing and places to watch | Shared User video access, Share Video Links, Ring.com video access, simultaneous Live View on multiple mobile devices, and viewing on Echo Show, Fire TV, tablets or third-party devices | | History and continuous context | Event Timeline, 24/7 Video Recording, Pre-Roll, Snapshot Capture and camera previews | | Alerts, verification and analysis | Video Search, Rich Notifications, Video Preview Alerts, Quick Replies, Bird's Eye View, Virtual Security Guard, Motion Verification, Video Verification, Person Detection, Video Descriptions, Single Event Alert and Familiar Faces |
That is a steep convenience cost. It is also not safe to treat the list as the final post-rollout answer.
Ring's new white paper says the updated E2EE architecture will keep functions that do not require cloud decryption, explicitly including Live View, event playback and 24/7 recording. Its launch article also says core playback and video sharing continue. Those statements do not line up neatly with the current support page, which still lists 24/7 recording, Event Timeline and share links as unavailable.
The likely explanation is timing: the support page describes E2EE as it works today, while the white paper describes the architecture rolling out with TAKE. Ring also warns that full feature compatibility will arrive over the rollout period. That is an inference from the dated documents, not a published reconciliation from Ring.
Until the live support page and enrollment screen agree, make the decision from the impacted-features screen shown for your exact camera, and save a copy before confirming. A feature promised in a white paper is not yet a feature on your account.
Six older models cannot use E2EE today
The current support page excludes six model generations from E2EE:
- Video Doorbell (1st Gen)
- Video Doorbell Wired
- Stick Up Cam (1st Gen)
- Spotlight Cam (1st Gen)
- Spotlight Cam (2nd Gen)
- Floodlight Cam (2nd Gen)
It also currently requires a compatible phone or tablet running iOS 17 or newer or Android 9 or newer, the latest Ring app, and limits enrollment to five Ring devices.
TAKE has a broader hardware path. Ring says newer cameras encrypt on the camera before video leaves the device. Older cameras without encryption-capable firmware are encrypted at cloud ingress instead. Those older cameras can use TAKE, but not E2EE.
That detail matters when “all Ring cameras” appears in a headline. The resulting TAKE key controls may be similar, but the point at which encryption begins is not. Check the exact model generation in Device Health or the product label; a family name such as Spotlight Cam is not specific enough.
Pick the boundary before the rollout picks the default
Leave a camera on TAKE if you need Ring's cloud analysis, shared household viewing, broad device playback or smart alerts and you accept Ring temporarily processing clips under the documented 24-hour key window. TAKE is designed for convenience with a shorter, controlled cloud-access period.
Choose E2EE if the central requirement is that Ring never receives the decryption keys for new recordings on that camera, even temporarily. Be ready to lose cloud-dependent functions, confirm current device compatibility and store the recovery method safely.
Wait before switching if TAKE has not reached the account, the in-app impacted-feature list conflicts with the feature you depend on, or the exact camera is one of the older E2EE exclusions. A phased rollout is not a return deadline. You gain nothing by making a privacy choice against documentation for a version you do not have.
Save this five-minute enrollment check
When the notice arrives, handle each camera separately:
- Record the exact model generation and whether TAKE is actually offered for it.
- Write down the three features that camera must keep — not every feature Ring can name.
- Open the E2EE impacted-features screen and compare it with the current support page.
- Decide whether temporary cloud decryption for those active features is acceptable in that camera's location.
- Save the recovery passphrase or confirm another documented recovery route before changing modes.
- Make one marked test recording, then verify live view, playback, sharing and alerts on every device that must use them.
The new white paper says changing modes affects new recordings and that older clips remain protected under their original mode. Ring's current legacy-E2EE support guidance, however, warns that leaving E2EE can remove access to previously recorded encrypted videos. Ring has not yet reconciled those migration statements publicly. If you already use legacy E2EE and have irreplaceable clips, do not unenroll until the app or Ring support confirms the migration path for your exact account. Do not use an important real incident as the first compatibility test.
This is a documentation comparison, not a hands-on security review. It cannot tell you whether Ring's implementation will withstand every attack. It can keep the marketing shorthand from making the decision for you: TAKE deletes Ring's lasting key copy after a controlled window; E2EE refuses that copy from the start.
For the separate question of where clips live, what extra hardware is required and what “local” does not guarantee, continue with the video-doorbell local-storage guide. If internet-outage behavior matters too, run the return-window outage test as a separate check. Encryption, storage and offline recording are three different promises.
