A neutral, source-cited survey of the code-signing and document-signing tools available to Delphi and C++ Builder developers in 2026: sgcSign, Microsoft SignTool, osslsigncode, Azure Trusted Signing, DigiCert Software Trust Manager, jsign, Adobe Acrobat, and the iText / Apryse PDF SDKs. Every feature claim links to the project's own documentation.
A one-paragraph summary of each option, with a link to the official documentation or repository. Detailed comparison is in the matrix below.
eSeGeCe · Commercial
Commercial Delphi / C++ Builder / .NET digital signature suite. Ships in two complementary form factors that share the same signing core. The component library produces XAdES, PAdES, CAdES and ASiC signatures in-process from Delphi 7 through Delphi 13. sgcSign Server adds a self-hosted REST signing daemon that signs Authenticode (PE binaries), ClickOnce manifests, NuGet packages, VSIX bundles and PowerShell scripts on top of the document formats. Ten key providers cover local PFX/PEM, the Windows certificate store, PKCS#11 hardware tokens, AWS KMS, Azure Trusted Signing, Google Cloud KMS, HashiCorp Vault, Certum SimplySign and any CSC v2 remote QTSP. Twenty-one pre-configured country profiles drive European e-invoicing and eIDAS employment-contract signing.
Microsoft · Windows SDK EULA (free for development)
Microsoft's command-line code-signing tool shipped with the Windows 10 / Windows 11 SDK. Signs and time-stamps Windows Portable Executable files (.exe, .dll, .sys, .cab, .cat) plus AppX/MSIX packages, ClickOnce manifests, and Microsoft Office Visual Basic for Applications projects via the SIP (Subject Interface Package) mechanism. Reads certificates from the Windows certificate store, PKCS#12 files, smart cards, and Cloud Signing Service (CSP) providers. PDF, XML and ETSI XAdES / PAdES / CAdES signing are not part of SignTool's remit.
Michał Trojnara & contributors · GPL-3.0-or-later (open source)
Open-source cross-platform Authenticode signing tool built on OpenSSL. Signs Microsoft PE binaries (.exe, .dll, .sys, .cab, .cat), CAB archives, AppX/MSIX packages, NuGet packages and script files. Runs on Linux, BSD and macOS in addition to Windows, which is the historical reason for the project — it lets Linux build farms sign Windows binaries without running SignTool under Wine. RFC 3161 and legacy Authenticode time-stamping; certificate sources include PKCS#12 files and PKCS#11 hardware tokens.
Microsoft · Commercial (Azure subscription, per-month)
Microsoft's fully-managed code-signing service in Azure (formerly Azure Code Signing). Customers do not own the signing certificate — Microsoft issues a short-lived certificate every three days and stores the private key in an Azure HSM. Integrations are provided for SignTool, GitHub Actions, Azure Pipelines, Trusted Signing PowerShell, and a dedicated dlib (Trusted Signing CSP) that exposes the keys to any CSP-aware tool. Signs Windows PE, MSIX, AppX, ClickOnce, VBScript / JScript / PowerShell scripts; PDF / XML signing are not in scope.
DigiCert · Commercial (subscription)
DigiCert's cloud code-signing platform. Private keys live in a FIPS 140-2 / 140-3 HSM hosted by DigiCert. Sign Windows PE, Java JAR, Android APK, Linux RPM / DEB, container images, NuGet, Apple Mach-O binaries and more through a fleet of dedicated tools: the smctl signing client, the DigiCert KSP / CSP plug-in for SignTool, native Jenkins / GitHub Actions / Azure Pipelines integrations, and a REST API. Documents (PDF, XAdES) are signed via the separate DigiCert Document Trust Manager product.
Emmanuel Bourg · Apache 2.0 (open source)
Open-source Java-based Authenticode signing tool. Runs as a standalone command, a Maven / Gradle / Ant plug-in, or a programmatic Java API. Signs Microsoft PE binaries, MSI installers, Microsoft script files (.ps1, .vbs, .js), MSIX / AppX packages, CAB archives, and CAT catalogues. Supports a broad list of cloud HSMs through a single CLI: AWS KMS, Azure Key Vault, Azure Trusted Signing, Google Cloud KMS, DigiCert ONE, HashiCorp Vault, Oracle Cloud KMS, Yubico YubiHSM, AWS CloudHSM (via PKCS#11), and any PKCS#11 device.
Adobe · Commercial (subscription)
Adobe Acrobat Pro and Adobe Acrobat Sign are end-user products for signing PDF documents. Acrobat Pro applies digital signatures and certified signatures with timestamps and validates incoming PDF signatures; Acrobat Sign (formerly EchoSign) is a cloud service for collecting electronic signatures from external parties. Neither is a developer library: there is no Delphi / C++ Builder SDK and no command-line signing tool in the box. PAdES Long-Term Validation is supported on the validation side via the Adobe Approved Trust List (AATL) and the European Union Trusted List (EUTL).
iText Group / Apryse Software (PDFTron) · Commercial (AGPL or commercial license)
Two commercial PDF SDKs widely used for unattended PDF signing in server-side applications. iText Core (formerly iTextSharp) is available for Java and .NET under AGPL-3.0 or a commercial license; the com.itextpdf.signatures namespace covers PAdES-B-B / B-T / B-LT / B-LTA, MDP (modification-detection) certifications, and visible appearances. Apryse PDFTron is a commercial cross-platform SDK (Java, .NET, C++, Node.js, Python, Go, iOS, Android, web) with a PDF.SignatureHandler API and PAdES support. Neither vendor ships a native Delphi binding.
A check () means the project documents native support. A dash (—) means the project does not provide it natively. A tilde (~) means partial / via add-on / not explicitly documented — see the Sources section for what we could verify.
| Feature | sgcSign | Microsoft SignTool | osslsigncode | Azure Trusted Signing | DigiCert Software Trust Manager | jsign | Adobe Acrobat / Adobe Sign | iText / Apryse |
|---|---|---|---|---|---|---|---|---|
| Sign Windows binaries Authenticode for .exe / .dll / .sys / .ocx | — | — | ||||||
| Sign ClickOnce manifests .application / .manifest files | ~ | ~ | — | — | ||||
| Sign NuGet / VSIX packages .nupkg / .vsix containers | ~ | ~ | ~ | ~ | — | — | ||
| Sign mobile packages (APK / IPA) Android APK or iOS IPA bundles | — | — | — | — | — | — | — | |
| Sign PDF documents (PAdES) ETSI EN 319 142, Adobe-compatible | — | — | — | ~ | — | |||
| Sign Office documents Word / Excel / PowerPoint docx / xlsx / pptx | — | ~ | — | — | — | — | — | — |
| Sign XML documents (XAdES) ETSI EN 319 132 | — | — | — | ~ | — | — | ~ | |
| Native Delphi / C++ Builder API First-class VCL / FMX components | — | — | — | — | — | — | — | |
| Cross-platform tooling Runs on Windows, Linux and macOS | ~ | — | ~ | |||||
| Cloud HSM support AWS / Azure / GCP / HashiCorp / CSC v2 | ~ | ~ | ~ | ~ | ||||
| eIDAS / country-profile presets Per-country signing presets (VeriFactu, KSeF, etc.) | — | — | — | ~ | — | ~ | ~ | |
| Standalone CLI Command-line client included | ~ | — | — | |||||
| Library / SDK Programmatic API for an application to call | — | — | ~ | ~ | ~ | — | ||
| Active maintenance Release or tagged activity in last 12–18 months | ||||||||
| Licence model Licence type | Commercial | Windows SDK EULA | GPL-3.0-or-later | Commercial (Azure subscription) | Commercial (subscription) | Apache 2.0 | Commercial (subscription) | AGPL or Commercial (iText) / Commercial (Apryse) |
Every option here has a real audience. The right pick depends on whether you sign code, documents or both, the runtime that hosts the signing logic, your key-custody preference, and your licence preference.
Pick sgcSign when you build the application in Delphi 7–13, C++ Builder or .NET and want one component suite that produces both document signatures (XAdES, PAdES, CAdES, ASiC) and code signatures (Authenticode, ClickOnce, NuGet, VSIX, PowerShell) from the same key-provider abstraction. The 21 pre-configured country profiles cover European e-invoicing and eIDAS employment-contract signing; the server form factor centralises key custody for build farms.
Pick Microsoft SignTool when the artefacts you sign are all Windows binaries (PE / .cab / AppX / MSIX) and the build host is Windows. SignTool is the reference command-line interface that pairs with every cloud signing service that ships a CSP / KSP (DigiCert KeyLocker, Azure Trusted Signing, GlobalSign Atlas, etc.), and the Windows SDK install is free.
Pick osslsigncode when your build host runs Linux, BSD or macOS and the artefacts to sign are Windows binaries — CAB archives, PE files, MSIX packages or NuGet packages. The GPL-3.0 license fits naturally inside CI pipelines that already use OpenSSL and PKCS#11 hardware tokens.
Pick Azure Trusted Signing when you want a fully-managed Windows code-signing service where Microsoft owns the certificate and the HSM, when your team already operates on Azure, and when the artefacts to sign are Windows PE, MSIX, AppX, ClickOnce or PowerShell. The short-lived certificate model removes the renewal and identity-verification burden of owning a Code Signing certificate.
Pick DigiCert Software Trust Manager when you already buy the DigiCert code-signing certificate and want it stored in their FIPS-validated HSM with one central pane for renewals, revocations, and audit. The native smctl client and SignTool KSP plug-in cover Windows binaries, Java JARs, container images and mobile packages from one workflow.
Pick jsign when the build pipeline already runs on a JVM toolchain (Maven, Gradle, Ant or Jenkins on JDK), when you want one CLI that drives every mainstream cloud HSM, and when the artefacts to sign are Windows PE / MSI / MSIX / script files. The Apache 2.0 license fits cleanly into closed-source build flows.
Pick Adobe Acrobat / Adobe Sign when the signing workflow is interactive and human-driven — a person opens a PDF in Acrobat, places a visible signature, and sends the file. Acrobat Sign extends that pattern to multi-party signing flows collected over email. No build-time or server-side automation is required.
Pick iText or Apryse PDFTron when the application is built on Java, .NET, C++ or one of the other supported runtimes and PDF is the dominant document format. Both SDKs have mature PAdES support, strong PDF feature coverage outside signing (forms, redaction, rendering), and well-known enterprise references.
Short notes on the differences if you are switching from one of the options above. Not adversarial — just the practical mapping.
SignTool covers Windows code signing only. If your application already calls SignTool from a build script, sgcSign Server exposes a REST signing endpoint that takes a binary and a provider name and returns the signed artefact — the same workflow, but the Authenticode operation runs centrally and the resulting audit trail, approval workflow and per-project quotas live in one place. Document signing (XAdES / PAdES / CAdES / ASiC) is then available from the same daemon.
If your build pipeline uses osslsigncode to Authenticode-sign Windows binaries from Linux build agents, sgcSign Server gives you the same flow over an HTTPS API and adds first-class drivers for AWS KMS, Azure Trusted Signing, Google Cloud KMS and HashiCorp Vault on top of the PKCS#11 path you may already use. Document formats (PDF / XML / CMS) are then available from the same endpoint.
sgcSign exposes Azure Trusted Signing as one of its ten key providers (TsgcAzureTrustedSigningProvider), so a Delphi or C++ Builder application can drive Azure Trusted Signing directly — the same private key, the same Microsoft-issued public-trust certificate, but the signer runs in-process. If you also need PDF / XAdES / CAdES document signing, the same key provider serves the document signers.
If you sign Windows binaries with smctl today, sgcSign Server can drive the same code-signing certificate via the PKCS#11 provider that DigiCert exposes, and adds first-class XAdES / PAdES / CAdES document signing on top — useful when an application needs both code and document signatures from one daemon.
jsign covers Windows code signing across a wide range of cloud HSMs. sgcSign Server overlaps on the cloud-HSM matrix (AWS KMS, Azure Trusted Signing, Google Cloud KMS, HashiCorp Vault) and adds ETSI document signing (PAdES, XAdES, CAdES, ASiC) plus the 21 country profiles — useful when the same key has to produce both code and document signatures.
Adobe Acrobat is an end-user tool, not a developer library. If you currently ask end users to sign PDFs in Acrobat and now want unattended server-side PAdES signatures, sgcSign provides the PDF signer (TsgcPAdESSigner) plus the timestamp and OCSP clients to produce PAdES-T and PAdES-LT signatures from a build pipeline or a backend service.
iText and Apryse do not provide a native Delphi binding, so Delphi applications typically wrap their .NET or Java SDK behind a thin bridge. sgcSign produces PAdES-B-B / B-T / B-LT signatures from native Delphi and C++ Builder code — the bridge layer disappears, and the same key-provider chain that signs PDFs also signs XML, CMS and Authenticode artefacts.
Each cell in the matrix above traces to one of these official documentation pages, repositories, or release notes. All URLs were HEAD-checked at the time of writing.