← back to blog

cloud phone encryption at rest and in transit: 2026 standards

cloud phone encryption is one of the questions that should have a clean technical answer. AES-256 at rest, TLS 1.3 in transit, modern cipher suites, no obvious gaps. it usually does, at the layers cloud phone vendors directly control. the more interesting question is what happens at the layers cloud phone vendors do not control, which is most of them.

cloudf.one encrypts data at rest on host filesystems with AES-256, encrypts the control plane with TLS 1.3, and encrypts ADB sessions with the standard ADB key exchange. that covers our infrastructure layer.

the application layer (apps installed on the phone), the device storage layer (Android’s own filesystem encryption), and the network layer (the carrier’s mobile path) are encrypted by other parties. this guide covers what cloudf.one provides, what other layers contribute, and where the boundaries actually fall.

what each layer encrypts

a cloud phone workflow has at least five layers where encryption matters.

the host filesystem layer. the disk on the host server where any persistent state from the phone (snapshots, audit logs, customer data) is stored. cloudf.one encrypts this with AES-256 using LUKS or equivalent at the volume level.

the device storage layer. the phone’s own internal storage. Samsung devices use file-based encryption (FBE) with hardware-backed keys at the device level. this is Android’s standard encryption, not something cloudf.one adds on top.

the network in-transit layer (control plane). TLS 1.3 between the customer’s browser or API client and the cloudf.one control plane. modern cipher suites only, no fallback to TLS 1.0 or 1.1.

the network in-transit layer (ADB and device session). ADB sessions use the standard ADB key authentication and an encrypted channel. cloud-phone control sessions over the network use TLS.

the network in-transit layer (egress from the phone). the path from the phone through the SG mobile carrier to the destination service. encryption here depends on the application protocol (HTTPS, TLS within app sockets) and the carrier’s network. cloudf.one does not add encryption to this path; we provide the carrier connection.

each of these is encrypted with appropriate standards in 2026. each is the responsibility of a different party.

what cloudf.one provides

honest scope. cloudf.one’s encryption controls cover the layers we operate.

at rest:

• host filesystems encrypted with AES-256 using LUKS-style volume encryption
• key management with hardware-backed keys where the colocation hardware supports it
• backup encryption with the same standards as primary storage

in transit:

• TLS 1.3 on the customer-facing control plane, with modern cipher suites
• TLS 1.2 minimum for backwards compatibility on legacy clients (with monitoring to detect any actual fallback)
• ADB sessions over encrypted channels
• internal service-to-service traffic encrypted with TLS or mTLS

key management:

• platform-managed keys for our infrastructure
• key rotation on documented schedules
• separation of duties for sensitive key operations

what is not in place:

• customer-managed encryption keys (CMEK or BYOK)
• per-customer key separation for at-rest data on shared hosts (data is logically separated, but the host disk is encrypted with one key per host)
• HSM-grade key storage for customer-specific keys

these are roadmap items for 2027 enterprise tier customers who want CMEK.

what other layers contribute

worth being clear about what cloudf.one does not provide because someone else does.

device-level encryption. Android’s file-based encryption on Samsung devices is hardware-backed and managed by Samsung Knox. when the phone is in a locked state, app data is encrypted with keys derived from the user’s lock screen credential and tied to the secure element. cloudf.one does not modify this; we benefit from it as it ships from the manufacturer.

application-layer encryption. apps installed on the phone (TikTok, banking apps, messengers) implement their own encryption for app-specific data. WhatsApp and Signal use end-to-end encryption for messages. banking apps use TLS plus app-specific protections. these encryption schemes are the apps’ responsibility.

carrier network encryption. mobile network traffic over LTE and 5G is encrypted between the device and the carrier’s network according to 3GPP standards. that protects you from passive interception on the radio layer. it does not protect you from the carrier itself or from attacks elsewhere in the path. for any traffic that needs end-to-end protection, application-layer TLS is what matters.

what to ask any cloud phone vendor about encryption

if encryption posture matters for your procurement, the questions:

• what encryption algorithms are used at rest?
• what is the minimum TLS version supported on the control plane?
• which cipher suites are enabled?
• how are keys managed and rotated?
• is customer-managed encryption (CMEK or BYOK) supported?
• is HSM-grade key storage available?
• what about backup encryption?
• what is the plan for post-quantum cryptography migration?

vendors that hedge on these answers should not be in your stack for encryption-sensitive workflows.

the post-quantum question

a brief note on the next horizon. NIST has standardized post-quantum cryptography algorithms (ML-KEM for key exchange, ML-DSA for signatures), and major providers are starting to deploy them in 2025 and 2026.

cloudf.one’s TLS stack supports hybrid key exchange (X25519 with ML-KEM) on the control plane where the client supports it. for at-rest encryption, AES-256 is widely considered post-quantum-resilient given current understanding, so no immediate migration is needed there.

post-quantum migration is an industry-wide multi-year effort. we will track standards and deploy as TLS libraries and clients roll out support.

practical controls that complement encryption

encryption is necessary but not sufficient. the controls that work alongside it.

minimize plaintext exposure. encrypt where it matters; do not assume encryption is a substitute for not collecting sensitive data in the first place.

audit access to encrypted data. encryption protects against passive disclosure. authorized access is logged and reviewed regardless. our cloud phone audit logs writeup covers the accountability layer.

isolate workflows. one customer’s data is not encrypted differently from another customer’s data on the same host today. logical separation, audit trails, and access controls do the heavy lifting. CMEK in 2027 will add per-customer key separation at the storage layer.

review TLS configuration. periodically test the control plane endpoints with tools like SSL Labs to confirm modern cipher suites are in use and weak ones are disabled. cloudf.one publishes test results on request for procurement reviews.

the simple decision

cloudf.one’s encryption posture is appropriate for most cloud phone workflows. AES-256 at rest, TLS 1.3 in transit, hybrid post-quantum key exchange where supported, audit logging on access.

for customers who require customer-managed encryption keys today, cloudf.one is on the roadmap for 2027 enterprise tier. for everyone else, platform-managed encryption is the standard pattern.

we would rather be honest that the at-rest encryption is one key per host, not one key per customer, than pretend otherwise. that is normal for most multi-tenant infrastructure providers, and it is what the encryption-at-rest claim actually covers.

try it within scope

if you want to evaluate cloudf.one’s encryption posture, the free 1-hour trial gives you a real Singapore phone with no card. inspect the TLS configuration, test the encryption handling, and validate the cipher suites during the trial.

start the free trial

frequently asked questions

what encryption is used at rest?

AES-256 with LUKS-style volume encryption on host filesystems. backups use the same standard.

what TLS version is required on the control plane?

TLS 1.3 is the standard. TLS 1.2 is supported for backwards compatibility with monitored fallback. TLS 1.0 and 1.1 are disabled.

does cloudf.one support customer-managed encryption keys?

not in the standard tier today. CMEK is on the roadmap for 2027 enterprise tier customers.

is the device storage encrypted?

yes, by Android’s file-based encryption on Samsung devices. that is device-level encryption from the manufacturer, not something cloudf.one adds on top.

what about post-quantum cryptography?

the control plane supports hybrid key exchange (X25519 with ML-KEM) where the client supports it. AES-256 at rest is post-quantum-resilient under current understanding. broader migration tracks NIST and IETF guidance.