Why e-signature in air-gapped networks is a different build
A self-hosted Documenso or DocuSeal instance can run inside an air-gapped enclave, but the platform is the easy part. The signing certificate, the time source, the mail relay and the verification tooling must all be built or sourced inside the boundary, and none of them can quietly call a public service. Both platforms are self-hostable: DocuSeal runs from the docuseal/docuseal Docker image with SQLite by default or PostgreSQL and MySQL through DATABASE_URL, and Documenso supports Docker, Kubernetes and manual installation with a PostgreSQL database. The platform choice is covered in the platforms section of this page.
The hard parts are not the signing screen. Documenso needs a signing certificate before it can digitally sign documents, and its documented options are a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS. The air-gapped build should use the OpenSSL path with a certificate issued by an internal certificate authority, and should avoid any cloud KMS dependency. Ask your team to confirm how DocuSeal's PDF signing is configured in your version, and whether its signature verification works offline. Plan for trust anchors, certificate revocation and renewal to be handled inside your own PKI.
Two further problems decide whether a signature stays provable years later. First, every container image, package and update crossing the boundary is a software intake event, and NERC CIP-013-2 is a useful reference for requiring verification of software integrity and authenticity before anything enters an isolated environment. Second, a signed PDF must be checkable outside the enclave by an auditor or counterparty with no access to your systems, so test verification with a copy of the certificate chain and a standard PDF validator before go-live. Confirm these three things with your architect early: the internal CA chain, the trusted time source for timestamps, and an offline verification procedure.
Which requirements shape an air-gapped signing build
This table maps common regulatory and control requirements to what they mean for an air-gapped signing build, the evidence an assessor typically expects, and where teams usually fall short. The examples cover energy, healthcare, broker-dealer and signing-certificate needs, so confirm with your compliance lead and auditor which ones apply to your environment before scoping the work.
| Requirement | Build meaning | Evidence and common gaps |
|---|---|---|
| NERC CIP-013-2, software integrity and authenticity (energy sector example) | Every package, container image, signing tool update and patch carried across the isolated boundary needs a verified origin and integrity check before import. | Expect hash records, signed artifact manifests and a transfer log. Gap: teams import updates without a documented verification step or procurement terms covering open-source components. |
| NERC CIP-005-7, remote access into the enclave (energy sector example) | Any vendor or administrator access into the air-gapped network must pass through a controlled intermediate system with encryption and multi-factor authentication. | Expect access diagrams, MFA records and a way to detect and disable active vendor sessions. Gap: a temporary remote session opened for troubleshooting that stays open after the work ends. |
| HIPAA 164.312(e)(1), transmission security (healthcare example) | Signer links, internal email notifications and any transfer of signed ePHI between enclave systems need protection against unauthorized interception. | Expect encrypted internal mail transport and TLS settings on the signing service. Gap: internal SMTP relays that send signer invitations in clear text inside the enclave. |
| HIPAA 164.312(b), audit controls (healthcare example) | The signing platform, certificate service and mail relay must record signing activity in logs that can be reviewed and retained. | Expect audit log exports, time-synchronized records and a review routine. Gap: logs kept only on the signing host with no copy outside it. |
| SEC Rule 17a-4(b)(4), communications retention (broker-dealer example) | Approvals and signed records that relate to the business must be kept as originals with associated communications for at least three years. | Expect retention schedules, immutable storage choices and indexed copies of the approval emails. Gap: signed PDFs stored without the internal email chain that led to them. |
| Documenso signing certificate requirement | Documenso needs a signing certificate to digitally sign documents. Documented options include a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS, which may not fit an isolated network. | Expect a documented certificate authority chain, key custody records and a plan for renewal. Gap: a self-signed certificate that outside verifiers do not trust, or a KMS option that requires connectivity the enclave does not have. |
Which self-hosted signing platforms fit an enclave
Documenso and DocuSeal both run on infrastructure you control, but they differ in deployment shape, edition licensing and how much they depend on services you may not have inside the enclave. The cards below cover the decisions that settle the platform choice before any installer is copied across the boundary.
Documenso on Docker and Kubernetes
Documenso is licensed under AGPL-3.0 and supports Docker, Docker Compose, Kubernetes and manual installation, with official images on Docker Hub and GitHub Container Registry. It stores data in PostgreSQL, so the enclave needs a mirrored image registry, a PostgreSQL service and a way to pull or transfer the release (v2.20.0, published October 8, 2026). Confirm which image sources and dependencies must be mirrored into the enclave, and test a full install with no outbound access before committing to this option.
DocuSeal on a single container
DocuSeal ships as the docuseal/docuseal Docker image, uses SQLite by default and can switch to PostgreSQL or MySQL through DATABASE_URL. It includes a PDF form field builder, PDF signature verification and an API with webhooks, which helps when signed files must be checked outside the enclave. Its AGPLv3 license carries Section 7(b) additional terms, so have counsel read them before you modify the code. Version 3.3.2 was published October 12, 2026.
Edition gaps that affect the build
DocuSeal's free on-premises edition has no SSO, bulk send or embedded signing. On-Premises Pro adds those features, plus white-label and unlimited bulk send, at $240 per user per year. Documenso's paid tiers differ in API and embedded signing, so map the workflows you need (enclave-wide SSO, cohort sends, embedded approvals) to a specific edition before you size the project. Ask each vendor to confirm in writing that the edition you buy runs fully offline, since several vendors in this category restrict air-gapped deployment to paid tiers.
Written offline terms from the vendor
Air-gapped support is often a paid-edition feature. Mattermost places air-gapped deployment in Enterprise Advanced, Rocket.Chat excludes it from its free Starter plan, and Metabase limits it to Enterprise. Assume the same pattern may apply to signing platforms until the vendor confirms otherwise. Request written confirmation of offline activation, license checks that work without a phone-home call, update delivery through offline media and support obligations in a disconnected setting.
Internal CA as the decisive dependency
Documenso needs a signing certificate to apply digital signatures, and its documented options include a self-signed .p12 certificate created with OpenSSL or signing through Google Cloud KMS. Google Cloud KMS is unavailable inside a disconnected enclave, so the practical path is an internal certificate authority whose root is trusted on enclave workstations. Settle the CA hierarchy, certificate lifetime, key storage (HSM or sealed file) and revocation publishing before the signing platform is installed, because every later signature depends on them.
Verifying signed PDFs outside the enclave
A signature is only useful if a reader outside the enclave can validate it. Test whether the PDFs produced by your chosen platform validate in standard PDF readers when the root certificate is installed, and whether they still validate after the document leaves the network on removable media. Document the trust anchor distribution process, so counterparties can confirm the chain without contacting the enclave. Run this test on sample documents before the first live approval.
How an air-gapped signing rollout runs
The sequence turns a disconnected network into a place where internal approvals can be signed, timestamped, delivered by internal email and verified later outside the enclave. Each phase closes with a written output the client can check before the next phase starts. Durations are agreed in the written scope and are not given here.
Scope and classify the documents
The client and DeployOpen list the internal approvals and signed documents the platform must handle, group them by type and sensitivity, and record which signature level each group needs. The client's compliance and records owners confirm retention rules and who may see signed files. The output is a signed scope document that names the platform (Documenso or DocuSeal), the editions considered, the network zones involved and the acceptance criteria for later phases.
Intake and transfer software images
Every container image, package and rule set is pulled on a connected staging system, recorded in an inventory with its version and cryptographic hash, and then carried across the boundary on approved media. Inside the enclave, the hashes are recomputed and compared with the inventory before anything is installed. The output is a transfer record that the client's security team signs off, showing which items passed and which were rejected. Supply chain checks of this kind relate to the software integrity and authenticity expectations in NERC CIP-013-2 where that standard applies.
Issue internal CA and signing certificates
DeployOpen configures an internal certificate authority or uses the client's existing one, then issues the signing certificate that the platform uses to digitally sign documents. The team confirms how the platform loads the certificate, who holds the private key and how it is backed up. Public trust is not assumed, so the client must also distribute the internal root to every machine that will verify signatures. The output is a documented certificate chain, a key custody record and a test signature that validates inside the enclave.
Configure the internal time source
The signing service, database host and mail relay are pointed at an internal time source that the client operates or trusts, because signature timestamps are only as credible as the clock behind them. The team confirms how time synchronization is monitored and what happens when a host drifts. The output is a time configuration record and a test signing event whose timestamp matches the reference clock within the tolerance the client sets in the scope.
Set up internal SMTP and test invitations
An internal mail relay, such as a self-hosted mail server operated inside the enclave, delivers signer invitations and completion notices without any external route. DeployOpen configures the sending domain, internal DNS names and TLS between the platform and the relay, then sends test invitations to every mailbox type in scope. The client confirms that links resolve only inside the network. The output is a delivery test log covering invitation, reminder and completion messages for each test account.
Build templates and workflows
The team builds the approved templates, field layouts, signing routes and conditional fields for each document group from the scope, then loads user accounts through the client's directory or single sign-on setup if the edition supports it. Permissions decide who can create, send and view each document. The client's process owners review each template against the signature rules they set. The output is a signed template register that lists version, owner and approval date for every workflow.
Verify signed PDFs outside the enclave
Sample signed PDFs are exported and checked on a separate workstation outside the enclave, using a standard PDF reader and the internal root certificate. The check confirms that signatures validate, that the timestamp and signer identity appear, and that any change after signing is detected. Results are recorded for each document group. The output is a verification report that shows which files validated and what the verifier needed to trust them, which the client can file with its records.
Hand over with runbooks
DeployOpen delivers runbooks for certificate renewal, image updates through the same hash-checked transfer, backup and restore, time source checks, mail relay failures and user onboarding. The client's operators run one supervised cycle of each procedure before handover is accepted. The output is an accepted handover package, a list of open items with owners, and an agreed plan for support after go-live, which is set out in the written scope.
Integration points that must work without the internet
A self-hosted signing service inside an enclave depends on five or six internal services that normally sit behind a public connection. Each card below names one dependency, who owns it, and what to confirm before the design is final.
Internal CA for the signing key
Documenso needs a signing certificate to digitally sign documents, and its documented options include a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS. In an enclave, the KMS option is usually unavailable, so the signing key must come from a CA your organization runs. Your team owns the root and issuing CA, key storage, and renewal. Confirm with the vendor which certificate formats and key stores the release you deploy accepts, and whether a chain from an internal root is displayed as trusted in the signed output.
Trusted timestamps from an internal source
A signature timestamp is only as credible as the clock that produced it. Enclaved networks cannot reach public time servers, so the signing host and any timestamping authority must synchronize to an internal stratum source that your team maintains and monitors. Document the drift tolerance and what happens when the source fails. Confirm with the vendor whether the platform supports an RFC 3161 timestamp authority and how the timestamp is embedded in the PDF.
Internal SMTP for invitations and notices
Signer invitations, reminders and completion notices all leave the platform by email. Inside an air-gapped network, that mail must route to an internal relay, and signers must be able to reach them through the enclave's mail or portal access. Confirm with your mail team how internal recipients resolve, whether TLS is enforced between relay and platform, and how delivery failures surface in the audit log. Email-only delivery is a limit for external signers, so plan an alternate route for them before go-live.
Identity from the internal directory
Senders, approvers and administrators need accounts that trace back to the directory your organization already runs, such as Active Directory or an internal OpenLDAP or Keycloak deployment. DocuSeal's SAML SSO is listed as a Pro feature, while its free on-premises edition has no SSO, so the edition decision affects this card directly. Confirm the edition, the SSO protocol supported, and the group mapping before you define approval roles, because these determine who can sign and who can see completed envelopes.
Document store and audit log export
Signed PDFs, original files and audit records must land in a store that your retention schedule governs, and the audit trail must leave the enclave in a form a reviewer can read. Both DocuSeal and Documenso use PostgreSQL or MySQL-backed deployments, so backup and restore of the database must cover the signed files and events together. Your team owns storage, backup and retention rules. Confirm with the vendor how audit events export, whether in a documented format, and whether the export is complete for the records your regulator expects.
Offline PDF verification with trust anchors
A signed PDF must be verifiable by someone outside the enclave who has no access to the signing system. That reviewer needs the signing certificate chain and the root certificate, carried across the boundary through your transfer process with its integrity checked. DocuSeal includes PDF signature verification, but confirm with the vendor whether verification runs fully offline and which trust anchors it uses. Treat every imported package as software crossing an isolated boundary and verify its hash before it is accepted.
How connectivity level changes the design
In a fully disconnected enclave, nothing reaches the signing platform over a network. Every container image, package, signing certificate and time reference is brought in on approved media and verified before it is loaded, and every signed PDF leaves the same way. The e-signature stack therefore depends on a small set of internal services that the enclave team runs itself: an internal mail relay for signer invitations, an internal certificate authority that issues signing certificates, and an internal time source that stamps signatures.
- Update intake: Build a repeatable process for importing images and packages on removable media, with a hash check and a record of who approved each import. Documenso and DocuSeal both run on Docker-based installs, so the image set and its checksums should be part of the import package.
- Certificate sourcing: Issue the signing certificate from the internal certificate authority rather than generating a self-signed certificate on the platform host. Documenso's documentation describes a self-signed .p12 option generated with OpenSSL and a Google Cloud KMS option, neither of which fits a disconnected enclave, so confirm the internal key storage path with the vendor before committing.
- Verification workflow: Confirm that the internal certificate chain validates inside the enclave and that the signed PDFs also validate on a machine outside the enclave, using the root certificate delivered on the same approved media.
- Time source: Point signature timestamps at an internal time server that is itself synchronized through an approved path, and document how drift is monitored.
- Email delivery: Signer invitations go through an internal mail server only. Confirm the platform can send to internal addresses without any external relay.
Before go-live, confirm with the vendor and your security team how each import is verified and which evidence the audit trail retains for each signature.
A controlled one-way transfer zone sits between an internet-facing staging network and the signing enclave. Updates, packages and certificate material move in one direction through a guarded transfer point, and only approved outputs such as signed PDFs move back. This model lets the team pull new releases faster than media-based intake, but it also adds a boundary that must be defined, monitored and tested.
- Update intake: Staging pulls and scans the release artifacts, such as the
docuseal/docusealimage or the Documenso release, then passes only the approved set through the transfer point. Record which release was accepted and when. - Certificate sourcing: Request signing certificates from the enterprise certificate authority through the staging side, but install the issued certificate and private key inside the enclave so the key never crosses the boundary.
- Verification workflow: Verify package signatures and checksums at the staging side and again inside the enclave after transfer, so a file changed in transit is detected.
- Time source: Use an internal time service inside the enclave. Do not let the enclave query an external time source through the transfer point.
- Transfer controls: Confirm the transfer mechanism is approved for the data classification it carries, and that transfers are logged for review.
Before approving the design, confirm with your network security team exactly which file types the one-way path allows and who signs off each transfer.
On a classified or regulated network, moving a file across a security domain usually requires formal cross-domain review, and the review rules are set by the authority that accredits the system rather than by the platform team. Software, certificates and signed outputs may each need a separate approval. The e-signature design should assume that every import and export is a reviewed event with its own record, and that the accrediting authority will want to see the supply chain of each component.
- Update intake: Treat each platform release as a controlled software item. Obtain the supply chain evidence the accrediting authority requires, including the source of each container image and package, before submitting for cross-domain review.
- Certificate sourcing: Use the certificate authority that the accrediting authority has approved for signing. Confirm whether the signing key must be held in hardware and whether that hardware is supported by the chosen platform configuration.
- Verification workflow: Verify software integrity at each domain boundary and keep verification records with the accreditation package. Verification of signed outputs outside the domain should use only tools and roots approved for that domain.
- Time source: Use the time source the accrediting authority specifies, and document how it is synchronized and monitored.
- Review scope: Confirm whether a signed document may leave the domain, which classifications are excluded, and who approves each release.
The accrediting authority and cross-domain review board set these rules, so confirm them in writing before any design work is scoped.
Evidence an auditor or regulator asks for, and what produces it
This table maps each piece of evidence an assessor typically requests for an air-gapped signing workflow to the component that produces it. Read it as a checklist to confirm with your auditor, since DeployOpen prepares the evidence while independent auditors and certification bodies form the opinions. The main takeaway is that signing, certificate, time and transfer records must be designed in from the start, because they are hard to reconstruct after the enclave is in use.
| Evidence item | Producing component | What the assessor checks |
|---|---|---|
| Signed PDF with embedded signature | Documenso or DocuSeal signing service with the internal signing certificate | Signature validates offline, document is unaltered after signing, signer identity matches the record |
| Audit trail of signer actions | E-signature platform event log (views, field entries, signing, completion) | Each action is attributed, timestamped and retained with the document |
| Certificate chain and issuance records | Internal certificate authority and its issuance log | Signing certificate chains to a trusted internal root, with issuance, renewal and revocation records |
| Time source logs | Internal time server and host time synchronization records | Timestamps are traceable to an approved time source and drift is logged and bounded |
| Software intake and hash records | Transfer procedure with a documented scan, approval and SHA-256 manifest for each package | Every package crossing the isolated boundary is verified for integrity and authenticity before import |
| Retention copies for SEC 17a-4 or HIPAA-scope records | Archive store holding copies of signed documents and audit trails, with retention rules | Records are preserved for the required period, retrievable and unaltered (confirm the exact retention periods with counsel) |
| Access logs for audit controls | Platform, operating system and database logs forwarded to an internal log store | Who viewed or changed signed records, when, and whether logs are protected from edits |
| Internal email delivery records | Internal mail server queue and delivery logs for signer invitations | Invitations reached the intended internal recipients and failures are traceable |
How a signature stays verifiable after the enclave is gone
A signed PDF from an air-gapped network is only as useful as the proof it carries, and that proof has to be checkable by someone who is never inside the enclave. Verification outside the boundary depends on three things being intact: the certificate chain that binds the signing key to an identity, the trusted timestamp that places the signature in time, and the document hash that shows the bytes have not changed. Each one must be checkable with trust anchors (the root and intermediate certificates, plus the time source's trust material) carried across the boundary as part of the evidence package. If any anchor is missing on the outside, the signature may still look valid in the signing system but cannot be proven later in an audit, a dispute or a regulator's review.
The most common failure is time-related. A signing certificate expires, a CA is retired or its certificate revocation information is no longer reachable, and a verifier who checks the signature after that point may be unable to confirm the chain at all. A timestamp covering the signing moment is what lets the signature remain valid after the signing certificate itself has expired, so the timestamp authority's own certificate lifecycle matters as much as the signer's. Confirm with your internal CA owner how long the root and issuing certificates last, where revocation status is published inside the enclave, and who renews the timestamp authority before any of them lapse.
Record the evidence at signing time, not later. For each signature, keep the signed PDF, the hash of the document as presented to the signer, the full certificate chain used, the timestamp token and the revocation status captured when the signature was made, plus the signer's identity, the signing policy version and the software version that produced the signature. Store a copy of the trust anchors with the archive so an outside verifier does not depend on a live connection to your network. Test the bundle once by verifying a sample signature from a machine with no enclave access before you rely on the process.
Questions buyers ask before bringing in a partner
How much effort does an air-gapped e-signature deployment take, and what drives it?
Effort depends mostly on how many moving parts sit inside the enclave and how much of the trust chain you must rebuild locally. The signing platform itself, typically Documenso or DocuSeal with PostgreSQL or MySQL, is the smaller part. The larger items are the internal mail path for signer invitations, an internal certificate authority that issues signing certificates, a local time source for trustworthy timestamps, and a process for verifying signed PDFs outside the enclave. Each added integration, each additional signing policy and each document type with its own level of evidence adds work. Ask any partner to break its estimate into these components in writing, and to state which items are one-time and which recur, such as certificate renewal and package transfers. Any duration should come from the written scope, not from a general rule of thumb.
Can our own team run an air-gapped signing platform without outside help?
Yes, many teams can, if they already operate Docker or Kubernetes, a relational database, and a private certificate authority. The gaps usually appear in three places: issuing and rotating signing certificates for documents that must hold up later, keeping a documented procedure for offline updates, and proving to an assessor how each step was controlled. Documenso documents self-signed .p12 certificates generated with OpenSSL and signing through Google Cloud KMS, but neither option is an internal CA workflow on a disconnected network, so you must design that part yourself. Ask whether your staff has done this before, who signs off on certificate policy, and whether you need a partner for the initial build, a retainer for upgrades, or both.
What does the work need from our team, including CA, network and change control?
The work needs decisions and access from several groups before technical work starts. Security and PKI owners must approve certificate profiles, key storage, lifetimes and revocation handling for the internal CA. Network and infrastructure teams must define the enclave boundary, the path for internal email, and the way approved packages cross into the network. Change management must agree how each release is reviewed before it enters the enclave. Application owners must list the approval workflows, templates and signer groups. Your team should also provide the hardware or cloud accounts inside the boundary, the database hosting, and a named approver for each change. Ask the partner to list these inputs in the written scope so that gaps show up before the schedule is set.
Do Documenso and DocuSeal run fully offline, and which editions cover that?
Both platforms are self-hosted and run from Docker images, so they can operate on a network without internet access once their images and dependencies are transferred in. Documenso supports Docker, Docker Compose, Kubernetes and manual installation with PostgreSQL. DocuSeal runs from the docuseal/docuseal image with SQLite by default, or PostgreSQL or MySQL through DATABASE_URL. The edition question matters more. DocuSeal's free on-premises edition has no SSO, bulk send or embedded signing, and its Pro edition adds SSO with SAML, bulk send, white-labeling and embedded signing. Documenso lists Enterprise licensing for self-hosted setups on its pricing page. Confirm with each vendor, in writing, that the edition you select is permitted to run disconnected and that it does not phone home for licensing or updates.
How do we trust timestamps on signed documents when there is no internet?
A timestamp is only as trustworthy as the clock and the authority that attests to it. On a disconnected network you cannot rely on public time services, so the enclave needs an internal time source that is synchronized to a reference you can document, such as an approved GPS or radio-based clock or a time server fed from a controlled upstream. The platform's audit trail and the signing certificate both depend on that clock. If a document must later be shown to have been signed at a particular time, the design must record how the internal clock was synchronized and how drift is monitored. Discuss with the partner whether the internal CA will issue time-stamping certificates, and confirm what each signed PDF can prove to an outside verifier, since verification outside the enclave depends on the trust roots you distribute.
How do software updates cross the air gap under CIP-013-style supply chain controls?
Updates cross the boundary as reviewed packages, not as live connections. The approach mirrors the expectation in NERC CIP-013-2 that procurement processes address verification of software integrity and authenticity for vendor software and patches. In practice, each container image, package and signed release is downloaded on a staging system, its checksums or signatures are verified against the vendor's published values, it is scanned, and it is then transferred through a controlled path with a record of who approved it. The same control applies to database migrations and templates. Ask the partner how it records each transfer, how it rolls back a failed package, and whether it can apply the same process to other enclave tools. Note that CIP-013-2 applies to a defined set of regulated energy-sector entities, so other sectors should use it as a pattern and confirm their own obligations.
What does support look like after go-live in an isolated environment?
After go-live, support covers patching, certificate renewal, backups, monitoring and incident response, all performed inside the enclave. Plan for a recurring process rather than a one-time handover. Certificates expire and must be renewed on the internal CA's schedule, time sources must be monitored for drift, and each vendor release must go through the transfer and review process described above. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms in the client's own infrastructure, including air-gapped networks. Ongoing support, upgrades and testing are available as retainers, and most engagements are fixed-scope with agreed deliverables. Ask any partner for its response arrangements in writing, including who is on call inside your environment, what access they hold, and how they handle a release that needs urgent review.
What to ask an implementation partner before signing a scope
Start by asking the partner to confirm offline operation of the chosen edition in writing, not in a sales conversation. Ask which Documenso or DocuSeal edition and version will run in the enclave, which features that edition needs to function without outbound calls (for example, font, PDF rendering, email relay and any license or telemetry check), and which features are unavailable offline or on the free edition. Ask for a list of every external endpoint the application, its container images and its database touch during install and normal use, and for the test evidence that the enclave build makes none of those calls. Vendor documentation on air-gapped support is not uniform across products, so the answer should name the exact build and the exact test. Next, ask how the partner will build and document the internal certificate authority and the signing certificate lifecycle. The scope should name who issues the root and intermediate certificates, where the private keys are generated and stored, how the signing certificate is provisioned for the signing service (Documenso documents a self-signed .p12 option generated with OpenSSL, which needs a clear key custody decision), how renewal and revocation are handled, and how a compromised key is replaced without invalidating earlier signatures. Ask for a certificate policy, a key ceremony record template, and a revocation procedure that an auditor can follow. Also ask how trust is distributed to verifiers outside the enclave, because a signature is only as checkable as the chain its verifier can reach. Finally, ask how verification and timestamps will be tested and who owns each. Ask the partner to specify the time source for trustworthy timestamps, who operates it, how drift is monitored, and what happens when the source fails. Ask how signed PDFs and their hashes are carried across the boundary, which checks confirm package integrity on import, and how a recipient outside the enclave validates a signature against the published chain. Ask for documented controls mapped to the framework your auditors use, with a clear statement that the partner prepares evidence and that independent auditors or certification bodies decide compliance.
How DeployOpen scopes and supports air-gapped signing
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own air-gapped network. For e-signature, that means the signing service, its internal mail delivery, the internal certificate authority, the time source and the offline verification path are designed and handed over together under a written scope.
How we scope
- Written scope lists which signing workflows, document types and internal approvers move onto the enclave platform.
- We inventory the internal mail relay, directory, certificate authority and time sources the signing service must rely on.
- We confirm with your team which signature level each document type needs before any build work starts.
How we build
- We deploy Documenso or DocuSeal on your infrastructure with PostgreSQL, using images and packages staged through your approved transfer process.
- We configure signing certificates from your internal certificate authority and document the trust chain for verifiers.
- We test signer invitations over internal email, timestamp behavior and PDF verification outside the enclave before go-live.
How we hand over
- Handover includes runbooks for installation, upgrades through offline media, backup, restore and certificate renewal.
- We deliver configuration records, network and data flow diagrams and the evidence set your auditors or assessors will request.
- Your staff receive training on issuing signing requests, reviewing audit trails and verifying signed PDFs without internet access.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope engagement ends.
- Retainer work can cover reviewing each release and each package carried across the isolated boundary before installation.
- Changes to certificates, time sources or mail relays are re-tested in a scoped change cycle agreed with your team.
