Frequently Asked Questions

/n software's components cover internet protocols (FTP, HTTP, email, SSH, SFTP), encryption and authentication (AES, RSA, OAuth, SAML, JWT), cloud service integration (S3, Microsoft 365, Google, Twilio), EDI and B2B messaging (AS2, AS4, X12, EDIFACT), PDF and document security, public key infrastructure and code signing, network management (SNMP), IoT protocols (MQTT, CoAP), and AI integration through the Model Context Protocol. They are building blocks used inside custom applications rather than standalone end-user software, with a few exceptions like PKI Agent and PDF Password, which are free standalone tools.

No. Each library wraps the underlying protocol or cryptographic standard behind a component-based, event-driven API, so a developer works with properties, methods, and events rather than implementing a protocol specification directly. For example, sending a file over SFTP or signing a PDF with PAdES only requires calling the relevant component's methods; the library handles the wire protocol, cryptographic operations, and edge cases internally.

/n software products are available as native components for .NET (C#, VB.NET), Java, C++, C++ Builder/Delphi, macOS (Objective-C/Swift), iOS, Android, JavaScript (browser), Node.js, PHP, Python, and Qt, running on Windows, Linux, and macOS as applicable. Enterprise integration platforms are also supported directly, including Microsoft BizTalk Server, SQL Server Integration Services (SSIS), and n8n. Platform and language support varies by individual product, so check each product page for the exact editions available.

/n software's components are commercially developed and supported in-house, with no dependency on open-source or third-party code. That means a consistent API across every supported language and platform, dedicated technical support, defined release and maintenance cycles, and accountability for security issues like the components' FIPS 140-2 compliant cryptography where applicable. Many /n software products, such as IPWorks EDI, also carry third-party certifications (Drummond Group AS2, EMVCo, PCI 3DS SDK) that most open-source alternatives do not pursue.

IPWorks is /n software's core internet communications component library and the foundation most other /n software products are built on. It provides 50+ components covering FTP, HTTP, Amazon S3, SMTP, IMAP, POP3, LDAP, DNS, SMS, WebDAV, WebSockets, JSON, and XML, with built-in SSL/TLS support and X.509 certificate management. IPWorks has been on the market for over three decades and is used by thousands of independent developers as well as Fortune 500 and Global 2000 enterprises.

The 50+ components are grouped by category: web and web services, file transfer, sending and receiving email and news, sockets and streaming, encoding and XML, network monitoring, remote access, instant messaging, file streaming and compression, and security, certificates, and encryption. That's most common internet-communication needs covered in one library.

IPWorks is available for .NET/C#, Java, Python, Delphi, C++Builder, PHP, ActiveX, Swift (macOS/iOS), Android/Kotlin, Linux C++, Qt/C++, and Node.js/JavaScript. It's one of the broadest cross-platform component libraries /n software offers.

No. IPWorks supports SSL/TLS 1.2 and 1.3 as an option on the protocols that support it, but it won't force encryption on a connection that doesn't need it. If a security policy requires that every connection be encrypted, IPWorks SSL is a drop-in replacement that enforces TLS on every component instead.

Yes. IPWorks is the core networking framework a lot of the /n software product line is built on, so many other products reuse the same underlying components and architecture rather than reimplementing internet connectivity from scratch.

IPWorks SSL is a drop-in replacement for IPWorks that enforces TLS/SSL on every protocol component it implements. Every component requires a secure connection and won't silently fall back to plaintext.

FTP, HTTP, SMTP, IMAP, LDAP, OAuth, WebSockets, and more. It's the same broad protocol coverage as IPWorks, just with SSL/TLS required on every one of them instead of optional.

The component set and APIs are the same as IPWorks, but IPWorks SSL mandates SSL/TLS on every connection while standard IPWorks treats it as optional. Reach for IPWorks SSL when a security policy or compliance requirement means a component should never be able to communicate without encryption.

TLS 1.3, 1.2, 1.1, and 1.0, along with X.509 certificate management and FIPS 140-2 compliant cryptography, across the full set of internet protocol components it implements.

Use it when your application has to guarantee that no connection is ever made without encryption, for example in a regulated industry where a misconfigured plaintext connection would be a compliance failure. If plaintext is acceptable for some connections, standard IPWorks covers the same protocol set with more flexibility.

IPWorks SFTP is a lightweight, dedicated SFTP client and server component library for applications that only need SFTP file transfer and don't need the broader SSH toolset or the rest of the IPWorks protocol suite.

SFTP versions 3, 4, 5, and 6, with AES GCM and ChaCha20-Poly1305 encryption, PPK and all major key formats, and multi-factor, password, and key-based authentication.

IPWorks includes SFTP as one protocol among 50+ in a broad internet communications library. IPWorks SSH covers the full SSH 2.0 family: SFTP, SCP, secure remote command execution, and SSH tunneling. IPWorks SFTP is narrower and lighter than both. Just SFTP client and server functionality, for applications that don't need anything else from the SSH or IPWorks toolsets.

Yes. It provides components for building SFTP clients that connect to and transfer files with an existing server, as well as SFTP servers for hosting your own endpoint.

Yes, it supports queuing and simultaneous upload of multiple files rather than handling transfers strictly one at a time.

IPWorks SSH is a component library focused on SSH 2.0 functionality: SFTP file transfer, SCP, secure remote command execution, and SSH tunneling and port forwarding. It's for applications that need SSH-family protocols without the rest of the broader IPWorks library.

Strong encryption including AES GCM and ChaCha20-Poly1305, with FIPS 140-2 compliant cryptography, key-based authentication, and multi-factor authentication.

IPWorks SFTP is narrower: just SFTP client and server functionality. IPWorks SSH covers the full SSH protocol family, adding SCP, remote command execution, and SSH tunneling on top of SFTP. Go with IPWorks SSH if your application needs any of that beyond file transfer.

Password authentication, public-key authentication, and multi-factor authentication, in line with the SSH 2.0 protocol specification.

Yes. It includes components for SSH port forwarding and tunneling, letting an application route traffic through a secure SSH connection in addition to file transfer and remote command execution.

IPWorks VoIP is a component library for building Voice over IP applications on the standard SIP protocol. It supports individual and conference calls, IVR menus, text-to-speech, call recording, and blind or attended call transfer.

Yes. Because it implements the standard SIP protocol rather than a proprietary API, it works with both on-premises SIP servers and hosted SIP providers.

IPWorks VoIP supports SIPS, meaning SIP over TLS, for secure call signaling, alongside standard unencrypted SIP where that's acceptable for the deployment.

Yes. It includes IVR menu support along with text-to-speech, so an application can present automated voice menus and route or record calls without a separate telephony platform.

The same broad cross-platform coverage as the rest of the IPWorks family, including .NET, Java, and C++. Check the product's Editions listing for the exact set on the current release.

IPWorks MQ is a general-purpose messaging component library supporting MQTT, AMQP, STOMP, Azure Relay, and XMPP. It's built for application-to-application and cloud messaging scenarios.

MQTT, AMQP, STOMP, Azure Relay, and XMPP, all in one component library instead of separate SDKs for each protocol.

Both support MQTT, AMQP, and STOMP. IPWorks MQ adds Azure Relay and XMPP and targets general application and cloud messaging. IPWorks IoT instead adds MQTT-SN and CoAP with optional DTLS, tuned for constrained and embedded devices where resource use matters more.

Yes. Its AMQP and MQTT components work with any standard-compliant broker or cloud messaging service, and its Azure Relay support specifically targets Microsoft's cloud relay service for hybrid connectivity.

The same broad cross-platform coverage as the rest of the IPWorks family, including .NET, Java, and C++. Check the product's Editions listing for the exact set on the current release.

IPWorks IPC provides interprocess communication over Named Pipes, with client, server, and remote command execution components, for communication between related or unrelated processes on the same machine.

Coordinating a background service with a UI process, or having one application invoke and exchange data with another running locally. Anywhere two processes on the same machine need a simple, reliable channel.

Yes. Alongside its named-pipe client and server components, it includes a component for remote command execution between processes over the same IPC mechanism.

No, it's built on Named Pipes, which is a same-machine communication mechanism. For processes on different machines, a networked protocol from IPWorks or another /n software product is the right tool.

The same broad cross-platform coverage as the rest of the IPWorks family. See the product's Editions listing for the exact languages and platforms on the current release.

IPWorks NFS implements NFS versions 4.0, 4.1, and 4.2 for both client and server roles on Windows, Linux, and macOS, with Kerberos (RPCSEC_GSS) authentication for enterprise environments.

It favors control over convenience on purpose. Instead of exposing an out-of-the-box filesystem, it fires events for each client-server interaction and lets the application decide what counts as a file, where the data actually lives, and how access is governed.

Yes. Since file representation is handled through application-level events rather than a fixed backing store, it can expose non-file data sources through NFS, or spread a single NFS-visible dataset across multiple backing stores.

Yes, it includes Kerberos (RPCSEC_GSS) authentication, which most NFS deployments in Active Directory or Kerberos-secured environments require.

Yes. It supports both roles, so it can consume an existing NFS share or host a new NFS-visible endpoint of its own.

IPWorks Encrypt is a general-purpose cryptography component library covering AES, RSA, ECC, ElGamal, ChaCha, 3DES, Blowfish, and Twofish, plus X.509 certificate management, SHA-1/2/3 and MD5 hashing, HMAC, JSON Web Signatures and Encryption (JWS/JWE), XML Digital Signatures, and PBKDF2/Argon2 key derivation. It's FIPS 140-2 compliant.

Yes. The 2026 release adds ML-KEM and ML-DSA components implementing NIST's post-quantum key encapsulation and digital signature standards, on top of the existing classical algorithms.

SHA-1, SHA-2, and SHA-3, plus MD5 and HMAC for hashing, and PBKDF2 and Argon2 for password-based key derivation.

IPWorks Encrypt is the general-purpose toolkit for encrypting and signing arbitrary data. IPWorks S/MIME and IPWorks OpenPGP are each built around one specific secure-email standard rather than general cryptography. Reach for IPWorks Encrypt when the job is encryption, hashing, or digital signatures broadly, not a specific email security standard.

Yes, which matters for applications in government, healthcare, financial services, or other regulated environments that require FIPS-validated cryptographic modules.

IPWorks S/MIME implements the S/MIME v2/v3 standard for secure email using X.509 certificates and PKCS, with S/MIME-enabled SMTP, POP3, and IMAP components built in.

Yes. In line with the S/MIME standard, it can encrypt messages for confidentiality and digitally sign them so the recipient can verify the sender's identity and check message integrity.

Both secure email, but on different standards. IPWorks S/MIME uses X.509 certificates and the S/MIME standard; IPWorks OpenPGP implements OpenPGP with its own keyring management. Which one you need usually comes down to what a trading partner or mail system requires.

Yes, it includes S/MIME-enabled SMTP, POP3, and IMAP components, so sending and receiving encrypted or signed email doesn't mean wiring S/MIME processing into a separate mail library.

X.509 certificates, along with PKCS-based message formats, consistent with the S/MIME v2/v3 standard.

IPWorks OpenPGP implements the OpenPGP standard for encrypting, decrypting, and signing data and email, with its own keyring management for OpenPGP keys.

IPWorks OpenPGP implements the OpenPGP standard and manages OpenPGP keyrings. IPWorks S/MIME implements the S/MIME standard using X.509 certificates instead. Use IPWorks OpenPGP when a trading partner or workflow specifically calls for OpenPGP-format encryption or signatures.

Yes, keyring management is built in, so an application can generate, import, and manage OpenPGP keys without a separate GnuPG or PGP installation.

Yes. Since it implements the standard OpenPGP key format, it can import and use compliant keys generated by other OpenPGP tools, not just keys it created itself.

The same broad cross-platform coverage as the rest of the IPWorks family. See the product's Editions listing for the exact languages and platforms on the current release.

IPWorks Auth is an authentication and identity component library covering OAuth 2.0, OpenID Connect, Kerberos 5.0, LDAP(S), RADIUS, NTLM, and Active Directory integration, plus JWT creation, signing, encryption, verification, and TOTP/HOTP one-time passwords.

Yes, the 2026 release adds WebAuthn support alongside the existing OAuth 2.0, OpenID Connect, and other authentication protocols.

Yes. It includes components for creating, signing, encrypting, and verifying JSON Web Tokens, on top of its OAuth, OIDC, Kerberos, LDAP, RADIUS, and NTLM support.

Yes, it includes Active Directory integration alongside LDAP(S), Kerberos, NTLM, and RADIUS support, covering the common enterprise authentication scenarios.

Yes. It includes TOTP and HOTP components for generating and validating time-based and counter-based one-time passwords, commonly used for two-factor authentication.

IPWorks Zip adds programmatic compression and decompression to an application across Zip, Jar, Gzip, 7-Zip, Bzip2, ZCompress, and Tar formats, with 256-bit AES encryption, Zip64 support for archives over 4GB, and self-extracting archive creation.

Zip, Jar, Gzip, 7-Zip, Bzip2, ZCompress, and Tar. That covers most of the compressed-archive formats an application is likely to run into, in one library.

It gives an application a consistent, programmatic API across every supported language and platform, plus capabilities most OS-level zip utilities don't expose to application code: streaming, listing, or modifying archive contents without fully decompressing first, AES-256 encryption, Zip64 support past 4GB, and self-extracting archive creation.

Yes, it supports 256-bit AES encryption for Zip archives on top of standard, unencrypted compression.

Yes. Alongside standard archive creation and extraction, it can build self-extracting archives so the recipient doesn't need separate unzip software installed.

IPWorks SNMP is used to build SNMP-based agent and manager applications for network device monitoring and management, supporting SNMPv1, SNMPv2c, and SNMPv3 with full authentication, authorization, and access control.

SNMPv1, SNMPv2c, and SNMPv3, with SNMPv3's authentication and encryption features fully supported for secure network management.

Yes, it can read and compile ASN.1 MIB files, so an application can work with vendor- or device-specific MIB definitions instead of only generic SNMP OIDs.

Yes. It includes components for sending and receiving SNMP traps in addition to standard request and response operations.

The same broad cross-platform coverage as the rest of the IPWorks family. See the product's Editions listing for the exact languages and platforms on the current release.

AMQP (1.0 and 0.9.1), MQTT (3.1.1 and 5.0), MQTT-SN, STOMP, and CoAP with optional DTLS, all through one unified API built to keep resource use low on constrained devices.

IPWorks MQ targets general application-to-application and cloud messaging and adds Azure Relay and XMPP. IPWorks IoT is tuned for constrained, embedded, and device-to-device scenarios instead, adding MQTT-SN and CoAP with DTLS while keeping resource use to a minimum.

Yes. Because it implements standard MQTT 3.1.1 and 5.0, it works with any compliant broker, including Eclipse Mosquitto, Azure Event Grid, AWS IoT, and other IoT-as-a-Service platforms. It also includes an MQTT Broker component for building the server side of a device network directly.

Yes, that's specifically what it's optimized for. Its MQTT-SN and CoAP support target sensor-network and embedded scenarios where a full MQTT/AMQP stack would be too heavy.

Yes. Its CoAP component supports optional DTLS and its MQTT/AMQP components support TLS, consistent with the security options found throughout the IPWorks family.

IPWorks BLE provides a Bluetooth Low Energy GATT client for device scanning, service discovery, and characteristic read, write, and subscribe operations on Windows, macOS, Linux, iOS, and Android.

They cover different short-range wireless technologies. IPWorks BLE handles Bluetooth Low Energy device scanning and GATT communication across desktop and mobile. IPWorks NFC is mobile-only and focused on reading and writing NFC tag data instead.

Device scanning, GATT service discovery, and reading, writing, and subscribing to characteristics: the core operations for talking to BLE peripherals like sensors, wearables, and beacons.

Yes. Along with Windows, macOS, and Linux, it supports iOS and Android, so the same BLE code can target desktop and mobile.

It provides GATT client functionality for scanning and connecting to BLE peripherals, not peripheral or advertising-mode functionality for acting as the device being connected to.

IPWorks NFC is a mobile-only component library, for iOS and Android, for reading and writing NDEF data on NFC Forum tag types such as NTAG and MIFARE Ultralight.

NFC Forum-compliant tag types including NTAG and MIFARE Ultralight, using the standard NDEF (NFC Data Exchange Format) for reading and writing tag data.

No, it's mobile-only, covering iOS and Android. For desktop short-range wireless work, IPWorks BLE covers Bluetooth Low Energy on Windows, macOS, and Linux as well as mobile.

Yes, it supports both reading and writing NDEF data to supported tag types.

No. It uses the NFC hardware already built into supported iOS and Android devices, so no separate reader or peripheral is needed.

IPWorks EDI is a library of components for secure Electronic Data Interchange over the internet, implementing leading EDI-INT protocols including AS1, AS2, AS3, AS4, OFTP, SFTP, MLLP, RosettaNet, and NAESB/GISB. It's built to let internet-based EDI replace costly traditional VANs.

Yes. It's eBusinessReady™ and Drummond Group AS2-certified, and its AS4 components are listed as conformant for European Commission eDelivery, EMSWe, and ENTSOG. Certification means the components have already been tested for interoperability against every other product in the same program.

IPWorks EDI handles the secure transmission side of EDI, getting a document to a trading partner over AS2, AS4, and similar protocols. EDI SDK handles the document side, generating strongly-typed EDI Objects from X12 and EDIFACT schema files. A lot of implementations use both together.

Yes. Its AS4 components support conformance profiles including European Commission eDelivery, EMSWe, and ENTSOG, on top of AS1, AS2, AS3, OFTP, SFTP, MLLP, and RosettaNet.

MLLP (Minimal Lowest Layer Protocol) shows up most often in HL7 healthcare messaging. The MLLP components in IPWorks EDI let an application send and receive HL7 or similar length-prefixed messages over TCP.

EDI SDK generates strongly-typed, transaction-specific “EDI Objects” from X12 and EDIFACT schema files. That gives an object-oriented way to create, parse, translate, and validate EDI documents instead of manually indexing segments and elements.

Yes. It generates EDI Objects from both X12 and EDIFACT schema files using the same command-line generation tools, and supports every official EDIFACT and X12 release.

EDI SDK handles the document side of EDI, generating and validating the documents themselves as strongly-typed objects. IPWorks EDI handles the transmission side, sending those documents to trading partners over AS2, AS4, and similar protocols. A common pattern is EDI SDK to build the document and IPWorks EDI to send it.

No. The generated objects expose named properties and methods for each document type, so reading or writing something like an EDIFACT INVOIC or an X12 ORDERS transaction is ordinary object-oriented code instead of manually walking segments and elements.

Yes. Validation is part of what the generated EDI Objects provide, along with creating, parsing, and translating EDI documents, so malformed documents can get caught before they're sent or right after they're received.

Cloud Mail is a component library for sending, receiving, and managing email and contacts through cloud mail services like Microsoft 365, Gmail, and Amazon SES, using one API regardless of which provider is configured.

Microsoft 365, Gmail, and Amazon SES, with OAuth 2.0 handling authentication where a provider requires it.

Cloud Mail sends, receives, and manages email and contacts through cloud mail services. Cloud SSO authenticates users into your application through an identity provider and doesn't send email at all. A lot of applications use both together: SSO for sign-in, Cloud Mail for transactional email.

No, that's the whole point of the Cloud product line. Cloud Mail exposes one component API that behaves the same regardless of which supported provider is configured.

Yes, contact management is included alongside sending and receiving email, across the same supported cloud mail services.

Cloud SSO is a component library for authenticating users into your application through any identity provider that supports SAML 2.0 or OpenID Connect, including Microsoft Entra ID, Google, Apple, GitHub, GitLab, Okta, and dozens of others.

It handles token verification, assertion validation, and Single Logout, and leaves the actual sign-in user experience up to the application. It fits into an existing login flow rather than replacing it.

Any identity provider that supports SAML 2.0 or OpenID Connect. It isn't limited to a fixed provider list since it implements the underlying standards rather than provider-specific APIs. Microsoft Entra ID, Google, Apple, GitHub, GitLab, and Okta are common examples.

Yes, Single Logout (SLO) is one of the core operations it handles, alongside token verification and assertion validation.

No. It validates and processes tokens and assertions issued by the configured identity provider rather than replacing the identity provider or minting its own tokens.

Cloud Keys integrates cloud-based key and secret management into an application, with components for working securely with popular cloud key management providers: Amazon KMS, Amazon AWS Secrets, Azure Key Vault, Google Cloud KMS, and Google Secret Manager.

Amazon KMS, Amazon AWS Secrets, Azure Key Vault, Google Cloud KMS, and Google Secret Manager, all through one component API.

One consistent API across multiple cloud key and secret providers means an application can switch providers, or support more than one, without rewriting integration code for each provider's own SDK.

Applications that need to retrieve, store, or manage encryption keys and application secrets, things like API keys, credentials, and connection strings, from a cloud key management or secrets service rather than storing them locally.

The same broad cross-platform coverage as the rest of the /n software product line. See the product's Editions listing for the exact languages and platforms on the current release.

Cloud SMS is a component library for sending and receiving SMS messages through multiple providers, Twilio, Vonage, Clickatell, SMSGlobal, SMS.to, and Sinch, through one unified API.

Twilio, Vonage, Clickatell, SMSGlobal, SMS.to, and Sinch.

Yes. Since Cloud SMS exposes the same API regardless of provider, an application can fail over to a different provider for uptime, or switch for cost, without touching the messaging code.

Yes, it covers sending and receiving SMS through its supported providers, so it's two-way messaging rather than send-only.

The same broad cross-platform coverage as the rest of the /n software product line. See the product's Editions listing for the exact languages and platforms on the current release.

Cloud Storage is a component library that integrates with Amazon S3, Google Drive, Microsoft OneDrive, Azure Files, ShareFile, Dropbox, Box.com, Wasabi, Backblaze B2, HDFS, and Seagate Lyve Cloud through one component API, with optional client-side encryption.

Amazon S3, Google Drive, Microsoft OneDrive, Azure Files, ShareFile, Dropbox, Box.com, Wasabi, Backblaze B2, HDFS, and Seagate Lyve Cloud.

Yes, as an option. Data can be encrypted before it's uploaded to the provider, independent of whatever server-side encryption the provider itself offers.

Yes. Since every supported provider goes through the same component API, an application can integrate with multiple providers, or switch between them, without keeping separate provider-specific integration code.

The core file operations you'd expect from a storage integration: uploading, downloading, listing, and deleting files, implemented consistently across every supported provider.

Cloud Sheets is a component library for integrating cloud-based spreadsheet management into custom applications, supporting Microsoft 365 (via the Graph API) and Google spreadsheet services.

Creating new worksheets, managing data, and handling advanced features like functions, so an application can control cloud spreadsheets programmatically instead of relying on someone editing them by hand.

Microsoft 365, through the Microsoft Graph API, and Google, covering the two most widely used cloud spreadsheet platforms through one component API.

Yes. Along with creating new worksheets, it can manage and modify data in existing spreadsheets across its supported providers.

Yes, that's a big part of the point. It lets developers build spreadsheet-management features that work consistently across the platforms /n software components support, instead of writing separate integration code per spreadsheet provider.

Cloud Calendars is a component library for integrating cloud-based calendar and task management into custom applications, supporting Microsoft 365 (via the Graph API) and Google.

Creating and listing calendars, managing events, and handling recurring events, attendee coordination, attachments, and calendar color customization.

Yes, task management is included alongside calendar management: creating, editing, and deleting tasks, adding tasks to lists, and updating task status.

Microsoft 365, through the Microsoft Graph API, and Google, through one consistent component API.

Yes, it can create and list multiple calendars per account rather than only managing events on a single default calendar.

Secure PDF is a development library for signing, verifying, encrypting, and decrypting PDF documents. It supports PAdES signature levels B-B, B-T, B-LT, B-LTA, and PAdES-EPES, password- and certificate-based encryption, fillable form creation, CRL/OCSP validation, EU Trusted Lists, ZUGFeRD/Factur-X e-invoicing, PDF merging and splitting, and PDF/A compliance.

Its security technology comes from SecureBlackbox, which has been market-tested for over two decades, but it's exposed through a simpler, more streamlined API focused specifically on PDF signing, verification, and encryption rather than SecureBlackbox's much broader suite of formats and protocols.

Yes. It can create fully compliant ZUGFeRD/Factur-X invoices (versions 1.0, 2.0, and 2.1) by embedding structured, machine-readable XML data directly into the PDF, so one file works both as a human-readable invoice and as input to automated processing systems.

Secure PDF is /n software's flagship PDF security library. PDF SDK is about PDF creation and editing, without the signing and encryption emphasis. PDF Password is a free, standalone command-line tool that just password-protects PDFs locally, running on the same underlying cryptography as Secure PDF.

Yes. It includes CRL/OCSP validation and support for EU Trusted Lists, so a PDF signature's certificate can be checked for revocation and trust status as part of verification.

PDF SDK is a development library focused on PDF creation and editing: generating documents from scratch, modifying text and form fields, and merging or splitting PDF files.

PDF SDK is about creating and editing PDF content. Secure PDF is /n software's PDF security library, for signing, verifying, encrypting, and decrypting PDFs. Applications that need both document generation and cryptographic security sometimes use both together.

Yes, merging and splitting PDF documents is one of its core capabilities, alongside generating new documents and modifying text and form fields.

Yes, it can modify existing form fields in a PDF as well as create new PDF content and edit text.

Yes. Generating new PDF documents, including multi-page ones, is one of its core capabilities rather than being limited to editing existing files.

PDF Password is a free, standalone command-line tool for password-protecting PDF files, running on the same underlying cryptography as Secure PDF, available for Windows, Linux, and macOS.

Yes to both. It's free to download and use, including its batch mode for multiple files. Unlike online PDF-encryption tools, it runs entirely on the local machine as a command-line utility, so your PDF data is never uploaded anywhere.

Yes, its batch mode password-protects multiple PDF files in one operation instead of requiring each file to be processed on its own.

No, it's a standalone command-line tool, not a development library. You run it directly to password-protect PDFs; no application development required.

No, it only adds or manages password protection on the file. It doesn't touch the PDF's underlying content, layout, or structure.

PKI Agent is a local, browser-facing tool that bridges the browser sandbox to certificates on a user's own local system or a hardware token, letting a web application get a cryptographic signature from a user-selected certificate without relying on a third-party signing authority.

It runs as a local application hosting a REST API on localhost. The browser sends signing requests to that local API; PKI Agent prompts the user to pick a certificate, creates the signature, and hands the signature data back to the browser for the web application to use.

Yes, for personal and commercial use. The free license isn't distributable as part of a product you ship to others; a distribution license covers that scenario.

Yes, PDF signing is a core use case for it. A web application can get a signature (PKCS#1 or PAdES) from a user-selected certificate right in the browser. Secure PDF and PKI Agent are built to work together here.

PKI Agent runs locally on an end user's own machine for in-browser, per-user signing. PKI Proxy is a server-side signing service where keys live on a controlled machine and signing requests come in remotely over the network. One solves per-user browser signing, the other solves centralized signing infrastructure.

PKI Proxy is a secure key server for remote code and document signing using centrally stored, bring-your-own-key (BYOK) keys. Private keys stay on a machine you control; PKI Proxy secures all communications with TLS and exposes a Web API so signing operations can be requested from elsewhere in your infrastructure.

The private signing key never leaves infrastructure you control, unlike third-party cloud signing services that hold the key on your behalf and typically charge per signature. PKI Proxy supports PKCS#11, hardware security modules, PFX files, Windows Certificate Stores, and USB hardware tokens like YubiKey as key sources.

PKI Proxy is a server-side signing service with keys on a controlled machine and signing requests coming in remotely. PKI Agent is a local, browser-facing tool that lets a web application get a signature from an end user's own local certificates inside their browser session.

Through allowlist-based access control plus HTTP Basic, NTLM, or Kerberos authentication governing which callers can request a signing operation.

Hardware security modules, file-based certificates (PFX), Windows Certificate Stores, and USB hardware tokens including YubiKey and DigiCert, all accessed through a cross-platform, PKCS#11-compliant driver and client-server API.

3-D Secure is an EMVCo-certified development toolkit for integrating EMV® 3-D Secure (3DS) authentication into shopping carts, websites, and merchant systems, supporting protocol versions 2.1, 2.2, and 2.3.1.

Visa Secure, MasterCard Identity Check, American Express SafeKey, Discover ProtectBuy, and J/Secure (JCB), covering the major EMV 3-D Secure program implementations from each card network.

Certified. The 3DS Server and mobile SDKs are on the official EMVCo Approved Products list, and the iOS and Android SDKs are also PCI 3DS SDK Certified. /n software is one of only three vendors whose products have that certification, after independent lab testing.

It implements the merchant and acquirer side of the 3-D Secure Server role defined by EMVCo, handling the authentication request and response flow with card issuers. The accompanying mobile SDKs cover the equivalent functionality inside iOS and Android apps.

No, it's licensed as a development toolkit, not a metered service, so there are no per-transaction fees. It's available for .NET, Java, C++, macOS, JavaScript, Node.js, PHP, Python, Android, and iOS.

SecureBlackbox is /n software's comprehensive data protection suite, trusted in mission-critical applications for over 25 years. It covers document signing (CAdES, XAdES, PAdES, ASiC, JAdES), certificate management, secure file transfer (FTP, SFTP, HTTP, WebDAV with TLS 1.3, EdDSA, and ECC), SAML identity provider and service provider functionality, KMIP, OCSP server, TSP server, and distributed cryptography.

SecureBlackbox is the deepest and broadest of the three, and it's where /n software's PDF and document-security technology originated. Secure PDF's PAdES capabilities are built on SecureBlackbox's cryptography, exposed through a simpler, more focused API. IPWorks Encrypt is a general cryptography toolkit rather than a document or transfer security suite.

CAdES, XAdES, PAdES, ASiC, and JAdES, covering signature creation and validation for documents and arbitrary data across the major international digital signature standards.

Yes. Alongside the full suite, several focused sub-products are available on their own: Advanced Signatures (CAdES/XAdES/PAdES/ASiC), Certificate Validation (X.509 path building with CRL/OCSP/EU Trusted Lists), File Encryption, and XML Signing (XMLDSig and XML Encryption).

Yes, it includes FTP, SFTP, HTTP, and WebDAV components with TLS 1.3, EdDSA, and ECC support, alongside its document-signing and PKI and certificate-management functionality.

The BizTalk Adapters are fully-managed .NET adapters and pipeline components that add internet connectivity, secure messaging, and file transfer to Microsoft BizTalk Server: 60+ adapters covering SFTP, AS2/AS4, FTP, email, MQTT, AMQP, encryption, compression, cloud storage, SharePoint Online, and Office 365.

BizTalk Server 2006 through 2020, with continual updates for new releases while keeping older versions already in production working.

No. The toolkit includes ready-to-deploy pipeline collections that work directly with the included pipeline components out of the box. Visual Studio and custom pipeline development only come into play for scenarios beyond what the pre-built pipelines cover.

SFTP, AS2/AS4, FTP, email, MQTT, AMQP, encryption, compression, cloud storage, SharePoint Online, and Office 365, across more than 60 individual adapters.

They're fully-managed .NET adapters and pipeline components, so there's no additional native or unmanaged dependency to install or deploy alongside BizTalk Server.

The SSIS Components are a suite of control-flow tasks for SQL Server Integration Services, versions 2012 through 2022, that add internet connectivity, secure messaging, compression, and secure file transfer, SFTP, FTP, SSH, OFTP, HTTP, email, and cloud storage (S3, Azure, Box, Dropbox, Google Drive, OneDrive), directly into SSIS packages.

SSIS versions 2012 through 2022, built from the same core codebase as the BizTalk Adapters and implemented in pure C#.

SFTP, FTP, SSH, OFTP, HTTP, email, and cloud storage connectivity, covering Amazon S3, Azure, Box, Dropbox, Google Drive, and OneDrive, plus encryption and compression tasks.

Yes, they're pure C#, in line with the SSIS control-flow task model, rather than wrapping an external process or unmanaged library.

They're control-flow tasks, used to perform actions like secure file transfer or messaging as steps in an SSIS package's control flow, not row-by-row data-flow transformations.

The n8n Node Library extends the n8n workflow automation platform with enterprise security and cryptography nodes it doesn't have natively: AS2 and AS4 B2B messaging, OpenPGP file encryption, S/MIME email signing and encryption, symmetric and asymmetric cryptography, and archive compression (7-Zip, BZip2).

It installs via npm and loads directly as native n8n nodes, with no external services or gateways required.

Workflows that need security operations n8n doesn't provide out of the box: sending an AS2/AS4 B2B message, encrypting a file with OpenPGP or S/MIME before the next workflow step, or compressing and decompressing archives as part of an automation.

No, the nodes run natively inside n8n once installed via npm, with no external service or gateway needed for the cryptography or messaging operations.

7-Zip and BZip2, alongside its cryptography and B2B messaging nodes.

MCP SDK is a development library implementing the Model Context Protocol (MCP), the open standard for connecting large language models to external systems. It provides an event-driven API for building MCP servers and clients that expose custom Tools (executable code), Resources (data), and Prompts (reusable prompt templates) an LLM can call.

MCP standardizes how large language models discover and call into external tools, data sources, and predefined instructions, so an LLM-based application can act on an organization's own systems instead of only its training data. Implementing the protocol's message formats, transports, and lifecycle directly is doable but repetitive. MCP SDK handles that layer so a developer can focus on the actual Tools, Resources, and Prompts being exposed.

Both transports defined by the MCP specification: standard input/output (stdio) for MCP servers launched and managed locally by an MCP host, and HTTP for servers reachable over the network.

.NET, Java, C++, Python, JavaScript/Node.js, Delphi/C++Builder, PHP, Swift/iOS, Android, Qt, and other platforms, 20+ in total, matching the broad platform coverage of the rest of the /n software product line.

Yes, it covers both roles defined by the protocol: building an MCP server that exposes Tools, Resources, and Prompts, and building an MCP client that connects to and calls into one.

The Red Carpet Subscription is /n software's MSDN-style developer bundle: one subscription includes every /n software product, every platform edition, and free upgrades to all releases during the subscription period, rather than buying and tracking individual product licenses.

As published on nsoftware.com: $1,999/year for a single developer covering all products and all platforms, or $2,499/year with Premium Support included. A Team License for 4 developers is $5,999/year, or $7,999/year with Premium Support. Enterprise/site licensing with volume discounts is available on request. Individual products can also be licensed separately. IPWorks, for example, starts at $799 per developer for a single-platform, royalty-free, perpetual license with one year of upgrades included.

An individual license (like IPWorks at $799/developer) is perpetual for the version purchased, royalty-free for distribution, and scoped to that one product. The Red Carpet Subscription is time-based (annual) rather than perpetual, but covers every product and platform at once, is licensed per developer so it can be used on any of that developer's machines, and includes free upgrades to new releases for as long as the subscription is active.

Yes. Every /n software product offers a full-featured trial download with free email support included for the trial period, so evaluation happens against the real product rather than a limited demo.

Most licenses are activated with a product key or serial number tied to a NodeId, which is a one-way hash of the machine name, so /n software never actually learns the real computer name. Some editions instead require a Runtime License (RTK) that gets emailed and assigned directly in code, or install via a downloaded registry key file on Windows. Licenses keep working through OS reinstalls or hardware changes as long as the machine name doesn't change. Moving a license to a different system requires submitting a license transfer form.

Applications already built and deployed keep running. A lapsed subscription or license doesn't disable software already in production. What stops is access to new releases and upgrades beyond the version covered when the subscription or maintenance period ended. Renewing at any time restores access to current versions.

There are two tiers. Standard & Trial Support is free for all customers and trial users and includes email support plus access to the online Knowledge Base, documentation, and sample projects. Premium Support is a paid add-on for Red Carpet Subscription customers with priority phone and email handling.

Priority phone and email support covering licensing, installation, debugging, protocol issues, programming issues, environmental issues, and general product use. It also includes access to additional unpublished samples on request and limited source code analysis related to the components. Premium Support contracts run for one full year from the purchase date, for a single company contact.

Premium Support responses are guaranteed within one business day. Standard & Trial Support is handled free of charge on a first-come, first-served basis without a guaranteed response window.

Through the online support form at nsoftware.com/support/submit, which assigns an issue number so requests can be tracked. Premium Support customers can alternatively call or email a priority support contact directly. General questions and pricing questions can also go to the sales team by email.