FAQ
Cloud PGP & S/MIME FAQs
Straight answers to common questions about cloud-hosted PGP and S/MIME email encryption. Where a capability depends on configuration or integrations, the answer says so.
Cloud email encryption basics
What is cloud-hosted PGP email encryption?
Cloud-hosted PGP email encryption moves PGP processing from individual email clients or an in-house server to a managed encryption service. The organization routes eligible outgoing mail to the service, which applies policy, finds the recipient’s public key and encrypts or signs the message with PGP before delivery. Incoming PGP messages can also be routed to the service for decryption when it holds the appropriate private key.
CloudPGP offers this model using the underlying Echoworx platform. Senders keep using their normal email client while encryption decisions follow centrally managed rules. See Cloud PGP and How It Works.
How does cloud PGP differ from an on-premises PGP server?
With an on-premises PGP server, the organization installs, patches, secures and scales the encryption system itself and manages its keys and directories locally. With a cloud-hosted service, the encryption engine is operated as a service, and the organization’s main tasks become routing mail to it, setting policy and managing keys and directories through central administration.
Messages still use the OpenPGP standard, so partners do not need to change their PGP software. What changes is where processing happens and, depending on configuration, where private keys are held, so routing, key custody and partner testing should be planned. See Migration from on-premises PGP.
What is S/MIME email encryption?
S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for encrypting and digitally signing email with X.509 certificates. A certificate issued by a certificate authority binds a public key to an email address. To send an encrypted message, the sender needs the recipient’s certificate; to sign, the sender uses their own private key and certificate.
Many common email clients support S/MIME. In a cloud-hosted model, an encryption engine can perform these operations according to policy, and certificate lookup and lifecycle tasks can be managed centrally where integrations are configured. See Cloud S/MIME.
Can an organization use both PGP and S/MIME?
Yes. Many organizations exchange email with partners that have standardized on different technologies, so supporting both is common. A platform that handles PGP and S/MIME can apply the appropriate method based on policy and on the keys or certificates available for each recipient.
Supporting both does not remove compatibility requirements: a PGP message still requires a recipient with a PGP key and compatible software, and an S/MIME message still requires a recipient certificate and a compatible client. See PGP vs. S/MIME.
What is the difference between signing and encrypting email?
Encryption protects confidentiality: only holders of the right private key can read the content. A digital signature protects integrity and helps verify origin: the recipient can check that the message came from the holder of the signing key and was not altered after signing.
A signed-only message is not encrypted, so anyone who obtains it can read it. The two can be combined, and policy can decide when each is applied. Signing modes also determine which key signs a message; see S/MIME signing precedence.
Keys, certificates and directories
How are PGP public keys found and exchanged?
A sender must have the recipient’s public key to encrypt a PGP message. The underlying platform documents several ways to find or distribute keys: lookups against configured LDAP key servers or domain directories, a PGP key directory where public keys can be published and looked up, and attaching the sender’s public key to a protected message so the recipient can reply securely.
Organizations can also import keys they already hold. Which methods are used depends on the deployment. See Public-key discovery and exchange.
Can existing PGP keys be imported?
Yes. The underlying platform supports importing existing PGP keys, including private keys. This can help an organization move from an on-premises PGP environment while keeping its relationships with partners who already hold its public keys.
Imports should be planned carefully: decide which keys are still needed, how private keys will be transferred securely, and whether older keys are required to decrypt historical messages. See PGP key handling.
Where are PGP private keys held, and what does MYOK mean?
To encrypt, decrypt and sign messages on users’ behalf, a cloud encryption platform needs access to the relevant private keys, so in a hosted deployment those keys are generally maintained within the service. The exact arrangement depends on the deployment and should be confirmed for your account.
The platform’s documentation also describes Manage Your Own Key (MYOK), which relates to customer involvement in managing certain keys through AWS Key Management Service and hardware security modules. MYOK should not be read as meaning that every PGP or S/MIME message key is held only by the customer. See Key custody and customer control.
How are S/MIME certificates renewed?
It depends on where the certificate came from. For supported certificate authority integrations, the platform documents automated renewal and rollover, so new certificates can be issued and put into use before the old ones expire.
Certificates imported manually, or issued by a provider without a supported integration, may need to be renewed outside the platform and imported again. Automatic renewal therefore applies to supported integrations only. See Certificate issuance and lifecycle.
What are LDAP directories used for?
LDAP (Lightweight Directory Access Protocol) directories store information that other systems can query. In email encryption, they are used to find recipients’ PGP public keys and S/MIME certificates so that messages can be encrypted to them.
The platform can query compatible directories configured for a deployment, and administrators can control which directories are searched. Limiting lookups to trusted, maintained directories helps avoid encrypting to an outdated or incorrect key. See LDAP directories and key lookups.
Mail systems and recipients
Can encryption work with Microsoft 365 or Google Workspace?
Yes, through SMTP routing, subject to configuration. The documented pattern is to configure the mail platform to route eligible messages to the encryption engine and to accept processed messages back for delivery.
This is a routing integration rather than a native add-in. The precise inbound and outbound configuration depends on the tenant’s setup and on any secure email gateway in the mail path. See Mail platforms and gateways.
What happens when a recipient cannot receive PGP or S/MIME?
If no usable key or certificate is available for a recipient, the message cannot be encrypted to them with PGP or S/MIME. Depending on policy and configuration, the platform can use a supported alternative: delivery over validated TLS, a secure web portal where the recipient retrieves the message, or an encrypted PDF or document.
These alternatives protect different things. TLS protects the connection between servers, while portals and protected documents rely on how access credentials are set and shared. None of them is equivalent to PGP or S/MIME message encryption. See Find keys and deliver.
Does every recipient need an account?
No. Recipients who use PGP or S/MIME read messages with their own keys and software and do not need an account with the service.
For secure portal delivery, the access method depends on policy: recipients may register, use a passphrase set by the sender, enter a single-use PIN or sign in through an identity provider. Accountless access is available only for specific supported workflows. See Secure recipient portal access.
Can recipients use passkeys or multi-factor verification?
Where enabled, yes. The underlying platform supports passkeys for portal access, unlocked with a device PIN or biometric check that takes place on the recipient’s device, as well as verification by authenticator-app TOTP, text message or automated voice call.
Availability depends on policy and on the recipient’s device, and not every device supports passkeys. The methods also differ in phishing resistance: one-time codes offer less protection than passkeys. See Authentication & Access Control.
Can the service support secure PDFs and attachments?
The underlying platform covers protected PDF, Office document and ZIP attachment workflows. Depending on configuration, the recipient opens a protected file with a password set by the sender, a generated verification code sent through a separate channel, or a password the recipient maintains for repeated exchanges.
This protects the attachment itself, which is different from encrypting the whole message with PGP or S/MIME. See Encrypted document access.
Compliance, this website and support
Does cloud email encryption automatically satisfy GDPR, HIPAA or PCI DSS?
No. Email encryption can be one of the technical measures an organization uses to meet requirements under laws and standards such as GDPR, HIPAA or PCI DSS, but no product makes an organization compliant on its own.
Compliance depends on how the service is configured and used, on contracts and data processing arrangements, on internal policies and on the applicable law. CloudPGP does not certify customer installations. See Security & Compliance.
Does the CloudPGP marketing website handle customer email encryption keys?
No. This website provides information about the service. It does not process, store or decrypt email, and it does not hold encryption keys. Those functions belong to the separately operated encryption service.
Please do not send passwords, private keys or sensitive message content through the website’s contact form.
How do I contact support?
Visit the Support page for the North America and Europe support telephone contacts, or email [email protected].
For general questions, sales enquiries or integration discussions, use the contact form.
Still have a question?
Contact the CloudPGP team about your PGP, S/MIME or secure email requirements.