The ZTmail Cryptographic Application Automation Gateway is an enterprise solution that automates cryptographic operations and certificate management for email, chat, and documents.
It provides digital signing, encryption, decryption, signature validation, certificate lifecycle management, trusted identity recognition, and related key‑management services. Depending on the deployment edition and selected components, it can also provide enterprise CA services, timestamping, and centralized cryptographic key management.
ZTmail Gateway adds a cryptographic application layer to an organization's existing IT infrastructure, allowing existing business systems and security products to continue performing their respective functions.
No. ZTmail Gateway complements rather than replaces an existing email security gateway. Traditional email security systems typically handle threat detection, anti‑phishing, malware detection, data loss prevention (DLP), content inspection, and compliance controls. ZTmail Gateway handles the cryptographic operations required to process S/MIME‑protected email, including decryption, signature validation, signing, and encryption. The two systems work together so that encrypted email can be inspected by the organization's existing security controls.
ZTmail Gateway addresses several common enterprise challenges:
ZTmail Gateway automates these cryptographic operations and supports different trust and deployment strategies.
No. ZTmail Gateway is designed to work with existing email gateways, email clients, document readers, email security infrastructure, and business systems. Employees can continue using their existing email clients without manually managing S/MIME certificates. Business applications can connect to the gateway to automate cryptographic operations on documents and other supported data.
Depending on the edition and selected components, capabilities include:
ZTmail Gateway offers two deployment editions based on the same core cryptographic gateway architecture.
Hardware Gateway
Software Gateway
Both editions provide core cryptographic gateway functions, including S/MIME encryption and decryption, digital signing, signature validation, trusted identity recognition, and certificate lifecycle automation.
The appropriate edition depends on mailbox volume, security requirements, infrastructure preferences, and budget.
The Software Gateway for organizations with fewer than approximately 1,000 mailboxes and the Hardware Gateway for larger deployments. Actual selection should be based on the required capacity, concurrent connections, cryptographic performance, and deployment architecture.
The Hardware Gateway's built‑in enterprise CA can issue ZTmail‑trusted organizational S/MIME and document certificates at organizational scale without per‑certificate fees or certificate quantity limits under the stated product model.
The gateway hardware itself is available in different capacity models. These models differ in supported mailbox scale, throughput, concurrent connections, cryptographic performance, and storage.
The Software Gateway supports configurable mailbox capacities, including a model intended for organizations with more than 1,000 mailboxes.
However, ZTmail recommends considering the Hardware Gateway for larger deployments because its built‑in enterprise CA and organizational‑scale certificate issuance can offer different long‑term economics.
Yes. Enterprise hardware deployments are designed around a redundant gateway pair, with high availability, load balancing, and automatic failover.
This architecture is intended to maintain cryptographic service availability if one gateway node fails. The actual continuity and recovery behavior depends on the deployment configuration and operational environment.
The Software Gateway and Hardware Gateway use different CA and infrastructure models. An organization considering future migration should confirm certificate portability, private‑key handling, trust‑domain configuration, integration requirements, and migration procedures with ZTmail before deployment.
ZTmail Gateway supports cryptographic application automation for three main areas:
The specific functions available depend on the gateway components purchased and the connected applications.
The S/MIME Automation Gateway sits between the organization's existing email security infrastructure and external networks.
For outbound email, the existing security gateway first performs its configured inspection and security controls. ZTmail Gateway then applies the required digital signature and encryption before the message is sent.
For inbound encrypted email, ZTmail Gateway decrypts and validates the message before passing it to the existing security gateway for inspection.
This architecture allows employees to continue using their existing email clients while the organization centrally automates S/MIME operations.
Yes. ZTmail Gateway can automatically sign, encrypt, decrypt, and validate S/MIME email according to the configured policies and available certificates and keys.
Encryption requires the appropriate recipient certificates or public keys. The gateway applies cryptographic operations according to the organization's configuration rather than assuming that every message can always be encrypted.
Yes. When integrated with the existing email security gateway, ZTmail Gateway can decrypt and validate inbound S/MIME email before security inspection. Outbound messages can be inspected by the existing security system before ZTmail Gateway signs and encrypts them.
This helps prevent encrypted email from becoming a blind spot for malware detection, phishing analysis, DLP, and compliance controls.
The inspection capabilities themselves remain dependent on the connected security systems and their configured policies.
No. One of its key objectives is to let employees retain their existing email clients while the gateway handles S/MIME certificate management and cryptographic operations centrally. The exact compatibility and integration requirements depend on the organization's email infrastructure and deployment configuration.
Yes. The Document Cryptographic Application Automation Gateway can integrate with business management systems to sign documents in bulk.
It supports automated document signing, encryption, decryption, signature validation, and certificate lifecycle management. A local timestamping system can also be included or connected separately.
Employees can additionally use ZTmail App to sign and encrypt documents manually by connecting to the Document Gateway.
Yes. Enterprise Instant Messaging Encryption Gateway builds encrypted chat capabilities on the organization's email infrastructure. It provides S/MIME certificate issuance, certificate lifecycle automation, and key management. It supports conversations between ZTmail App users and between ZTmail App users and compatible existing email clients. Other email clients may also be provided with cryptographic services, such as signing, encryption, decryption, and signature validation, depending on the integration.
The Hardware Gateway includes enterprise CA and subordinate CA capabilities, with the subordinate CA private key protected by the integrated HSM.
The Software Gateway does not include a built‑in enterprise CA. It obtains certificates through ZTmail Cloud Cryptographic Service.
A dedicated ZTmail Trust Domain allows an organization to establish its own organizational trust environment for supported ZTmail‑trusted certificates.
Within the configured trust domain and supported ecosystem, the organization can use validated identities for email and documents and apply its own identity and security policies.
Trust within the ZTmail ecosystem should not be confused with automatic public trust by every external S/MIME client. External interoperability may require certificates issued by eligible public CAs.
ZTmail Gateway automates the certificate lifecycle:
Request → Validate → Issue → Deploy → Renew → Replace or Revoke
For the Hardware Gateway, the built‑in enterprise CA can issue organizational certificates at scale. For public CA certificates, ZTmail coordinates certificate supply and the applicable CA validation and issuance process.
This reduces the need for administrators and employees to manage individual certificates manually.
Yes. Certificate lifecycle automation includes renewal before expiration, subject to the applicable certificate requirements, CA processes, and service configuration.
The gateway also supports certificate replacement and revocation when necessary.
Yes. Certificate revocation is part of the certificate lifecycle management process.
Organizations can revoke certificates when required, for example, when an employee leaves or a certificate must no longer be trusted. The effects of revocation depend on the certificate status, validation mechanisms, and the applications that check that status.
Yes. ZTmail Gateway supports a mixed certificate strategy. The organization can use ZTmail‑trusted certificates for most internal or ecosystem communications and deploy public CA certificates selectively for mailboxes and document signing scenarios that require global trust. This avoids requiring every mailbox to use a public CA certificate when only a subset of users’ needs that level of external interoperability. This mixed certificate strategy can save a lot on certificate costs and operating expenses.
Yes. ZTmail can coordinate certificate supplies from eligible public CAs through its certificate automation services, subject to the selected trust model, certificate type, CA policies, validation requirements, and service availability. Public CA certificates may be deployed selectively for external communication with organizations, public‑sector entities, international partners, or other environments that require public trust.
ZTmail Gateway supports three certificate trust strategies.
Hybrid Trust is primarily a certificate allocation strategy: it enables an organization to use public CA certificates where needed while avoiding unnecessary public certificate costs across the entire organization.
Organizational trust supports trusted communications within the configured organizational or ZTmail trust environment.
Global Trust uses certificates issued under public CA trust chains that are recognized by compatible external applications.
A certificate trusted in one environment is not automatically trusted by every external application. The required trust model depends on where the email or document will be received and validated.
These labels describe different levels or types of identity validation associated with certificates:
The available certificate types and validation processes depend on the certificate issuer and applicable certificate policies.
Yes. ZTmail Gateway can recognize identity assurance information associated with S/MIME certificates and make it available to configurable security policies.
For example, an organization may configure policies to:
The actual enforcement decisions are determined by the configured policy and the connected security infrastructure.
No. A valid digital signature helps verify that the signed content has not been altered after signing and that the signature is associated with the relevant signing certificate. It does not, by itself, establish that the content is harmless, that the sender is authorized to perform a particular action, or that the message contains no phishing or malware. Signature validation should complement, not replace, other security controls.
The Hardware Gateway integrates a PCIe hardware security module (HSM) to protect the organizational subordinate CA private key.
The HSM provides hardware‑based cryptographic protection for critical CA operations. The overall security of the deployment also depends on access controls, configuration, physical security, operational procedures, and key‑management policies.
Yes. Key management depends on the deployment architecture and configures policy.
The Hardware Gateway supports organizational key generation and management within its gateway environment. The Enterprise Key Management System (EKMS) provides centralized key management for email, chat, and document encryption, including key lifecycle management, backup, recovery, and archival capabilities.
ZTmail App can retrieve user certificate keys from the EKMS when this deployment model is configured.
ZTmail EKMS provides centralized cryptographic key management for medium‑sized and large organizations.
Its functions include:
The EKMS can be deployed on the internal network. A redundant deployment is recommended.
No. Software Gateway's cloud service is used for certificate supply and lifecycle management automation; end users' private keys are securely stored on their local devices.
In deployments using the Hardware Gateway or EKMS, key generation, storage, retrieval, backup, and recovery follow the selected on‑premises architecture and organizational key‑management policy.
Organizations should choose the deployment and retention model according to their security, availability, and recovery requirements.
Yes. The EKMS supports automated key backup and recovery, along with key archival management.
Key backup and recovery are particularly important for encrypted email and documents because previously received encrypted content may remain inaccessible if the corresponding private key is lost. The exact retention and recovery policy should be configured according to the organization's requirements.
ZTmail Timestamping Service System provides on‑premises timestamping for document signing and other applications. It includes a ZTmail‑trusted timestamp signing certificate and automates the certificate's application and renewal. Business management systems and ZTmail App can connect to the service to obtain timestamps locally.
Yes. The ZTmail Timestamping Service System supports on‑premises timestamping in accordance with RFC 3161. It can be used for batch document signing, business data, and other applications requiring timestamp evidence.
A trusted timestamp can provide evidence that a digital signature or related data existed at a particular time. It can support long‑term signature validation and help establish time‑related evidence, subject to the timestamp token's validity, trust chain, and applicable validation procedures. A timestamp does not independently prove that a document's contents are true or that the signer had legal authority to sign it.
Yes. The Document Cryptographic Application Automation Gateway can include an integrated timestamping system as an option. If the document gateway does not include this component, it can connect to the separate ZTmail Timestamping Service System to add local timestamps during bulk document signing.
ZTmail Gateway is positioned as a complementary cryptographic layer.
For inbound encrypted email, the intended workflow is:
Encrypted Email → ZTmail Gateway: Decrypt and Validate → Existing Security Gateway: Inspect and Protect → Recipient
For outbound email, the intended workflow is:
Sender → Existing Security Gateway: Inspect and Protect → ZTmail Gateway: Sign and Encrypt → Recipient
This lets the existing security gateway inspect the message content while ZTmail Gateway performs the required cryptographic operations.
Yes. The gateway is designed to work alongside existing email security systems that provide threat detection, anti‑phishing, malware detection, DLP, content inspection, and compliance controls. The integration allows each system to focus on its core function rather than requiring the organization to replace its existing security investment.
Yes. Business management systems can integrate with the gateway to automate supported cryptographic operations. For example, document‑producing applications can connect to the Document Cryptographic Application Automation Gateway for bulk signing and encryption. Business systems can also connect to the local timestamping service when timestamping is required.
Specific integration methods and supported interfaces should be confirmed for the target application and deployment.
The Hardware Gateway supports dedicated hardware deployment, built‑in enterprise CA capabilities, and on‑premises cryptographic infrastructure. The EKMS and timestamping service also support local deployment. Public CA certificate supply and certain cloud cryptographic services may still require connectivity to external services. The Software Gateway uses cloud‑based certificate supply and lifecycle automation. The exact on‑premises boundary therefore depends on the selected components and trust model.
No. AI security is optional.
Organizations that already have an email security gateway with suitable security and AI capabilities can continue using those systems. ZTmail Gateway can focus on cryptographic operations.
Yes. Where the optional AI integration is deployed, the organization can use its preferred AI provider and its own API key.
Potential applications include phishing analysis, business email compromise (BEC) analysis, suspicious email detection, email content analysis, and document content analysis.
The availability and scope of these capabilities depend on the configured AI integration and the organization's security policies.
No. AI analysis and cryptographic application automation serve different purposes.
AI can help analyze suspicious content or identify potential threats. Cryptographic functions such as signing, encryption, decryption, certificate management, and signature validation provide identity, confidentiality, and integrity mechanisms.
AI is an optional complement to the cryptographic gateway, not a replacement for those functions.
The two editions follow different commercial models.
The final quotation depends on mailbox capacity, required functions, trust‑domain allocation, certificate requirements, and deployment architecture.
Yes. ZTmail Gateway is a configurable, multifunctional solution. Organizations can select the components required for their application scenarios, such as:
The final configuration should reflect the organization's email, chat, document, key‑management, and timestamping requirements.
To recommend appropriate deployment, an organization should provide:
This information helps determine the suitable gateway edition, capacity, components, and certificate strategy.
ZTmail Gateway separates cryptographic application automation from the email security, business, and communication systems already in use. Organizations can centrally automate certificates, keys, signing, encryption, decryption, signature validation, and trusted identity management while retaining their existing applications and security controls.
For larger deployments, the Hardware Gateway's built‑in enterprise CA, HSM protection, organizational‑scale certificate issuance, and high‑availability architecture provide a foundation for managing cryptographic applications across the organization.
Choose according to the recipients and applications that must recognize the certificates.
A mixed strategy can reduce unnecessary public CA certificate costs while preserving global interoperability where it is needed.
ZTmail Gateway makes cryptographic operations part of the organization's existing workflows rather than leaving certificate and key management to individual employees or separate manual processes.
It combines automated certificate lifecycle management, cryptographic operations, trusted identity signals, and configurable deployment options to support email, chat, and document security at organizational scale.
One Gateway. Three Services. Fully Automated.