Sertainty Technology Knowledge Base

The fastest path from zero to a working program:

1. Read What is the UXP Technology, and how is it different from conventional encryption? for the elevator pitch.
2. Read What are the three core objects in Sertainty UXP Technology? Identity, Vault, SmartMessage. Everything else is built on these three.
3. Pick your language (UXL, C, or C++, or other languages via GitHub) and follow the matching starter pair below.
4. Skim What are the basic steps to protect my first file? for the end-to-end workflow.
5. Open the Vault back up and extract its contents: How can an existing Vault be opened and authenticate to read its contents? (C++ API; the same pattern translates to UXL and C).

Language-specific starter pairs in Sample Code:

• UXL: How do I create a simple Identity using UXL? → How do I create a basic Vault using UXL?
• C: How do I create a simple Identity using C? → How do I create a basic Vault using C?
• C++: How do I create a simple Identity using C++? → How do I create a basic Vault using C++?

That's the on-ramp. Everything else in this Knowledge Base is reference material for when you have a specific question.

Prefer a no-code start? Sertainty Tech Hub covers the same "create an Identity → create a Vault → open it back up" flow through a GUI, no programming required. See What is Sertainty Tech Hub? for what it includes.

Sertainty UXP Technology lets a file enforce its own access rules. Instead of locking a file behind your application or your fileserver, you protect the file inside a Vault. Its protection travels with the file, whether it sits on your laptop, a USB stick, a cloud bucket, or a recipient's machine.

The protection mechanism is active intelligence: a UXP Engine embedded into the protected object itself. The behavior it produces is active authorization, not static encryption: the Vault challenges whoever tries to open it, evaluates the response against rules baked into the file at creation time (who you are, where you are, what time it is, what device, etc.), and grants or denies access on every open.

If your problem is "the data leaves my environment and I lose control of it," that's the problem UXP is designed to solve.

Three objects: Identity (.iic) is who can open things, Vault (.uxp) is what is protected, and SmartMessage is a UXP-style protected payload for peer-to-peer delivery. See What are the three core objects in Sertainty UXP Technology? for the full breakdown.

A complete round-trip:

• Create an Identity
• Create a Vault holding files
• Open it back up
• Extract the files

• Verify they match

• Install and license. Install the Application Development Kit and place your sertainty.lic file in the standard location. (Obtain the license through your Sertainty contact or account portal.)

• Create an Identity. ~10 minutes. Pick your language and follow the matching "How do I create a simple Identity using ..." topic in the Sample Code section.
• Create a Vault holding two test files. ~10 minutes. Follow the matching "How do I create a basic Vault using ..." topic in the Sample Code section.
• Open it back up and extract. ~15 minutes. How can an existing Vault be opened and authenticate to read its contents? walks the authentication loop. How do I export/extract files from a protected Vault? covers writing the contents back to disk.

Once that runs, the rest of the Development Kit is incremental:

• SmartMessages for peer-to-peer payloads
• UXP SQL for structured data inside a Vault
• Workflow for automated protection pipelines

Five things developers often assume that are not true:

• "It's just AES encryption with different packaging."
   AES is one component (FIPS 140-3 validated). The differentiator is active authorization, a behavior produced by the UXP Engine's active intelligence embedded inside the file. The Vault file evaluates rules and challenges identity on every open, not just at creation. A correctly keyed AES file decrypts unconditionally; a Vault can refuse based on time, location, device, prior failures, and so on. See How does a Vault authorize users beyond just authenticating them?.
• "You need a Sertainty server to use it."
   The Core UXP framework is fully standalone. Servers are only needed when you opt into the Services layer. See What are Sertainty Services, and when do I need a Services server?.
• "The Identity (.iic) and the Vault (.uxp) are interchangeable."
   They're not; they play different roles. The .iic is the authenticating Identity (itself a special purpose Vault), embedded into every Vault at creation. The .uxp is the protected payload that holds your data. Both are safe to share through ordinary channels because both are themselves protected. What you must never share is the underlying ID Definition XML, the source from which the .iic is compiled, since anyone with it can reproduce a working Identity. See What's the difference between an Identity (.iic) and a Vault file (.uxp)? and What is an ID Definition (ID Def)?.
• "It only protects data at rest."
   An application or process can work with data inside a Vault while the data stays protected, so coverage spans data at rest, in flight, and in process. See Does Vault protection still apply if a file leaves my secure environment?.
• "It needs a network connection to authenticate."
   Standard authentication is fully offline. Network-aware features (geo fencing, server reporting) are opt-in. See Can a Vault authenticate users without any network connectivity?.

Branch by what you care about next:

• Going deeper on access control
   The Authentication and Access Policies sections cover challenge mechanics, response masking, geo fencing, time windows, and what happens when authentication fails.
• Working with existing Vaults
   The Working with Vaults section shows how to open, read, query, extract, copy, and stream from existing Vaults at the API level, across the C, C++, and UXL APIs.
• Setting up Workflow
   The Getting Started with Workflow section walks through setting up a Workflow deployment end to end.
• Workflow deployment patterns
   The Workflow Scenarios section covers Source/Destination Node deployments, auto-protect and auto-unprotect pipelines, email-attachment proxies, multi-recipient distribution, long-term archive, and integration with existing file sharing systems.
• Server-side features
   The Services and Server setup section covers when you need a server, how to set one up, what each Service does (Core, Data, Delegate, Utility, Workflow), and how to query Services data.
• Scripting
   The UXL Scripting section covers when to use UXL versus a host language, the Script Utility, error handling, and dynamic file specs.
• Quick term reference
   The Glossary at the bottom defines challenge pair, response masking, trust score, Sertainty Secure String, and other terms that appear throughout.

If you're evaluating UXP Technology for regulatory, procurement, or legal purposes rather than coding against it, start with these sections:

• Cryptography and compliance
   The FIPS Compliance section covers what is FIPS validated on the UXP technology side, the cryptographic boundary, and when an application or Application Development Kit needs its own CMVP review.
• DoD and federal compliance
   The DoD and Federal Compliance section covers CUI / NIST 800-171, continuous monitoring, cross-domain data spillage, NIST 800-88 sanitization, and multi-level security deployments.
• Export classification
   The Technology Export Restrictions section covers the ECCN classification, BIS filing requirements, the Canada exemption, and what business partners must do before exporting bundled products.
• Security mechanics
   The How data stays protected section covers what encryption is used, how keys are managed, and how UXP resists quantum, AI, and "harvest now, decrypt later" attacks.
• Threat model in plain language
   What attacker is UXP Technology designed to defeat? lays out the orientation map, what UXP is built to stop, and equally important, what is explicitly out of scope.
• License expiration behavior
   What happens to Vault files if my license expires? covers what an expired license actually disables (every UXP Engine operation) and how to restore access.

UXP is a security framework for protecting data at rest, data in flight, and data in process. Unlike conventional encryption, which wraps a file in a static key, UXP embeds active intelligence inside the protected object so that access control travels with the data no matter where it resides.

Each Vault carries its own dynamic protection scheme, pairing FIPS 140-3 validated AES-256 at the cryptographic core (provided by wolfCrypt) with Sertainty's non-cryptographic layer that adds key scattering, access control, and a dynamic protection envelope designed to resist both quantum attacks and AI-driven data mining. See What encryption does UXP Technology use? for the full crypto architecture.

See the Introduction for the high-level overview.

Three core objects together define the Sertainty UXP Technology: who can access protected data, what data is protected, and how it can be shared. Learning all three upfront makes the rest of the Knowledge Base easier to follow.

• Identity (.iic file)
  A portable identity that authenticates a human, machine, process, or other digital entity. The Identity is itself a special purpose Vault, holding the username, challenge pairs, and rules of engagement and access. Generated from an XML definition, it is required to create or open a Vault. An Identity can be embedded directly within the Vault, or referenced through a Delegate Identity, a proxy managed by the Delegate Service.
• Vault (.uxp file)
  The digital data vault. Holds files, folders, images, audio, video, structured SQL data, or any unstructured data. Each Vault is created with an Identity that defines who can open it: one or many authorized users (human, machine, process, or other digital entity), or users associated through a Delegate. Access is granted only when all conditions in the Identity are met.
• SmartMessage
  A protected digital courier for peer to peer delivery. Similar to a Vault but without the file system container, and without an embedded Identity. Useful for short data exchanges over messaging or transport channels where a folder structure isn't needed. Because the Identity isn't embedded, the recipient process or application must have access to the matching Identity to authenticate and open the message.

A typical first program creates an Identity, uses it to create a Vault, adds files, closes the Object, and later opens it using the same Identity to authenticate. SmartMessage is used when protected data needs to be sent peer to peer.

The end-to-end workflow, at a conceptual level:

1. Initialize the Sertainty UXP Technology library once at application startup (uxp::sys::initializeLibrary in C++, uxpsys_initLibrary in C).
2. Create a new Identity:
   • Design the ID properties
   • Create a private or test Identity from them
3. Create a new Vault from that private or test Identity.
4. Add data to the Vault by importing files or adding content manually, then close it.
5. To access later:
   • Open the Vault
   • Authenticate against the user's credentials
   • Read or export data
   • Close the Vault
6. At application shutdown, release the Sertainty UXP Technology library (uxp::sys::releaseLibrary / uxpsys_releaseLibrary).

For working code that implements this sequence in UXL, C, and C++, see the Sample Code section.

Not ready to write code yet? Sertainty Tech Hub is a desktop application that performs these same steps without writing any code. It's useful for training, demonstrations, and building general understanding of the technology before committing to a custom application. See the Sertainty Tech Hub section.

A .uxp file can only be opened by an application built with the UXP technology. Currently, there is no generic viewer or "double-click to open" experience; the technology has to be present to run the authentication conversation with the file. Three common paths:

• Sertainty Tech Hub. The Tech Hub provides an Open Vault action for interactive open and authenticate. Its Asset Browser module is a separate, focused directory view that lists Sertainty artifacts (.uxp, .iic) without wading through other file types. Good for demos, evaluation, and one-off inspection. See What is Sertainty Tech Hub?.
• A custom application built with the Application Development Kit. Any application (desktop, service, script) built with the UXP technology can open a Vault. See How can an existing Vault be opened and authenticate to read its contents? for the open and authenticate loop.
• Auto-Unprotect (Workflow Service). For automated pipelines, a Workflow task can unprotect Vaults as they land in a watched folder. See What is the Workflow Service and when would I use it?.

A Vault is directly tied to an Identity (a specific individual, machine, or process), unlike conventional encryption tools that use a "key" or "password" any holder can present. Opening a Vault requires the authenticated Identity, not just possession of a shared secret.

A Vault that a recipient can't open isn't a bug — it means either the recipient's application isn't built with the UXP technology, or they don't have an Identity matching the User Definitions embedded in the file.

Both frameworks come with the Sertainty libraries. They serve different deployment scenarios:

You pick either Core or Server when linking, not both; the server library already embeds the entire core library.

Beginning with V5.0, an expired license disables all access to applications and processes that depend on the Sertainty UXP Technology. This includes:

• Opening existing Vaults.
• Creating new Vaults.
• Authenticating against existing Identities.
• Any UXL script, C / C++ program (or any other supported languages), or service that loads the Sertainty libraries.

In short: every operation that runs through the UXP Engine stops working until a valid license is in place.

Remedy: replace sertainty.lic with a new or updated license key file.

Where it lives. In the Application Development Kit's home/ folder. On a typical install:

• ~/Sertainty/Developer/home/sertainty.lic

For the runtime's full search order (current library directory, current working directory, adjacent directory), see the Home Directory section of the Core Framework chapter of the Sertainty Technology Guide.

How to install the new license. The file Sertainty delivers is named for your organization (e.g., developer.lic, acmecorp.lic), but the UXP Engine specifically looks for sertainty.lic. Install the new file under that exact name. Three options:

• Manual. Copy the delivered .lic file into the Development Kit's home/ folder and rename it to sertainty.lic.
• Scripted. Write a small script that copies and renames the file, useful for fleet deployment or repeatable upgrades.
• Sertainty Tech Hub. Use the Update License function in the Tech Hub application, which handles the copy and rename for you.

What happens after the swap. On the next process startup:

• Existing Vaults open again.
• Creation of new Vaults resumes.
• No migration, re-protection, or rebuild is required.

Existing Vaults are not damaged by the expiration. They are gated behind the license check until you renew, then immediately accessible again.

V5.0 deprecation note. The previously shipped free.lic file is no longer supported as of V5.0. Environments that relied on it pre-v5 need a current commercial license installed under the standard sertainty.lic name to continue functioning.

If uxpsys_initLibrary() or uxp::sys::initializeLibrary() is failing because the license has expired, see What should I check if library initialization fails? for diagnostic steps.

No. UXP is offline by default: a Vault is fully self-protecting and can be created, shared, and opened entirely offline, if the Vault's policy grants offline access. Data sharing does not require a server. The Server framework is only needed for centralized auditing, multi-user management, Workflow Service automation, or web service APIs.

Because the protection mechanism is local, UXP is also airgap ready: it runs identically in connected environments and in airgapped or denied connectivity environments such as SCIFs, ships, aircraft, or field deployments. For airgap use, the Identity is typically embedded directly in the Vault at creation. A Delegate Identity needs to reach the Delegate Service at open time, which is incompatible with airgap unless the Delegate Service itself runs inside the controlled area. This is part of the design discussions, with particular focus on airgap environment requirements. See What is an airgap, and does Sertainty UXP Technology work in airgapped environments? and How does Sertainty UXP Technology support SCIFs and other off grid or denied connectivity government environments?.

Authentication is a local conversation between the Vault and whoever is trying to open it, with no Sertainty service, server, or network infrastructure involved. See Can a Vault authenticate users without any network connectivity? for the full autonomy detail.

A Vault can optionally communicate with a Sertainty server to report access events, but that is opt-in behavior configured through rules.

UXP is transport agnostic. The technology operates at the application layer, above the network and transport layers, so it works over any underlying transport that can move bytes from one place to another. Examples include:

• TCP/IP, HTTPS, and other internet protocols
• Mobile networks (LTE, 5G, satellite)
• Email, FTP, cloud storage, and file shares
• Bluetooth, Wi-Fi, and other local transports
• Air-gapped transfer via removable media

The protection travels inside the Vault rather than depending on a secure channel. The channel itself does not need to be secure for UXP to be useful. See Does Vault protection still apply if a file leaves my secure environment? for the in-flight protection guarantee, and Can a Vault authenticate users without any network connectivity? for the offline behavior.

An airgap is a security measure that physically or logically isolates a system from unsecured networks. Airgapped systems have no live network connection to the public internet or other untrusted networks; data crosses the boundary only via removable media (USB drives, tapes, optical disks) carried by hand. The pattern is common in classified government and military networks, industrial control systems, nuclear facilities, financial settlement networks, isolated backup environments, and other regulated infrastructure.

Airgap is a perimeter control. It blocks network based attackers but does not address insider exfiltration via removable media, malicious media introduced from outside (the Stuxnet pattern), loss or theft of media after crossing the boundary, or authorized cross boundary transfer to less trusted environments.

Sertainty UXP Technology is well suited to airgapped environments. Authentication happens locally against the embedded Identity, so no Sertainty service or server needs to be reachable at open time (see Can a Vault authenticate users without any network connectivity?). Protection travels with the file, so a Vault carried across the boundary on removable media stays protected; loss or theft of the media does not expose the data (see Does Vault protection still apply if a file leaves my secure environment?). Per file access rules travel too: being inside the boundary does not automatically grant access to every Vault.

Sertainty is not a replacement for the airgap. The airgap continues to limit network attack surface; UXP adds a file level layer that addresses the cases the airgap doesn't.

For deeper detail on SCIFs, tactical operations centers, naval and submarine operations, DDIL conditions, and other government or military scenarios (including ATO and accreditation context), see How does Sertainty UXP Technology support SCIFs and other off grid or denied connectivity government environments?.

An Identity is a special-purpose Vault that carries a secure, portable identity, saved with the .iic extension (for example, acme_admin.iic). With an Identity you can create Vaults without hand-writing any UXL modules, build SmartMessages for peer-to-peer exchange, or establish a single-sign-on session. Average size is around 20 KB depending on how many security options are enabled.

A useful mental model: the .iic is the key + access policy; the .uxp is the vault. See What's the difference between an Identity (.iic) and a Vault file (.uxp)? for the full contrast.

What an Identity holds. An Identity has two layers of content. There is a small public layer (owner name, unique identifier, optional contact info) that is intentionally readable and used only for display, never for authentication. The rest is protected by the surrounding UXP wrapper and is what actually gates access:

• One or more User Definitions. Each User has its own username, optional email, privilege flags (Files, Messages, SSO, Imports), and a set of challenge pairs. A single Identity can describe one person, several people, machines, processes, or any mix; that's how workgroup Identities are built. See What is a workgroup Identity?.
• Challenge pairs. Prompt/response entries that gate access. The engine selects a randomized subset at authentication time based on trust score; for machine Identities, most challenges are marked Required so there is no randomized selection. See What is a machine ID?.
• Privilege flags per User. Files (open Vaults), Messages (receive SmartMessages), SSO (participate in single-sign-on), Imports (create new Vaults from this Identity).
• Environment and rule configuration. Host fingerprints, geo fences, expiration dates, failure thresholds, response masking, alert configuration, recovery policy, and event/audit setup. Everything that determines where the Identity authenticates lives here.

To create one:

1. Write an ID Definition XML. The ~/Sertainty/Developer/examples/shared/hello_id.xml template is a good starting point.
2. Pass that XML to id::newIdFromDocument(xmlBytes, options) in UXL or uxp::idManager::publishToFile() in C++. The second UXL argument is an options string (pass "" for defaults).
3. The script writes out a .iic file. That's your Identity, ready to use.

The ID Definition XML in step 1 is source; protect it like application source. See What is an ID Definition (ID Def)? for the full security posture.

How an Identity can be shared. Because the .iic is itself a Vault, its protected contents stay protected during distribution; copying the file does not expose the User Definitions inside. Identities travel through these typical routes:

• Internal directory. An individual's Identity is registered in the organization's Identity directory so the org can protect files on behalf of that person.
• Component of a workgroup Identity. Individual Identities contribute private attributes to a combined workgroup .iic that's accessible to all members.
• Delegate Server registration. Individual Identities are registered on a Sertainty Services server as Delegate users; the Delegate Identity is embedded in Vaults and the server validates users at access time. See What is the Delegate Service, and when should I use it?.
• SmartMessage exchange. A receiver provides their .iic so a sender can encode a SmartMessage for them; the receiver's Identity must be present at decode time. See What is a SmartMessage, and when should I use one instead of a Vault?.
• Colleague-to-colleague file exchange. A recipient hands their Identity to a sender, who then protects files intended only for that recipient. The creator never sees the recipient's credentials and (unless they include their own Identity in the Vault) cannot open the file they just created.
• Process automation pipelines. A machine Identity is shared with Workflow Tasks, scheduled jobs, or data-pipeline processes that need to operate on protected data without a human in the loop.

For a complete worked example, see How do I create a simple Identity using UXL? under Sample Code. The UXP ID section of the Sertainty Technology Guide's Core Framework chapter covers the complete schema for every element and attribute the XML can contain.

An ID Definition (often abbreviated as ID Def) is the XML document that describes an Identity before it is compiled into the binary .iic file. It is the human-readable source from which an Identity is generated. The XML specifies:

• Owner information (all fields optional): name and address. Owner phone and photo fields are no longer supported as of v5.
• Identity-level privileges: Files, Messages, SSO, Imports
• One or more <User> definitions, each with a username (case-insensitive), email, per-user privileges, and challenge pairs
• Per-user privileges (granted to a User Definition within the Identity): AltRealities, Delete, Owner, Read, ReadEvents, ReadSignatures, Sign, SQL, Write. Phone and Photo, previously valid privilege fields, are no longer supported as of v5
• A <Rules> block covering general setup, restrictions, alerts, events, and schedules

The Application Development Kit ships an annotated reference XML at ~/Sertainty/Developer/examples/shared/hello_id.xml and a few variants alongside it. At creation time, the script utility's id::newIdFromDocument() (UXL) or uxp::idManager::publishToFile() (C++) reads an ID Definition and produces the binary .iic Identity.

For the full specification of every element and attribute an ID Definition can contain, see the UXP ID section under the Core Framework chapter of the Sertainty Technology Guide. The RulesPreset section in the same chapter covers the detailed description of every rule tag (GeneralSetup, RestrictionsSetup, AlertSetup, EventSetup) and the values each accepts.

A User Definition is the block inside an Identity that describes a single participant, a user, machine, or process. It carries that participant's username, optional contact info, privileges (Files, Messages, SSO, Imports), and challenge pairs (prompt + response). A single Identity can hold one User Definition or many; each authenticates independently against its own challenges.

For where a User Definition sits alongside the ID Definition XML and the .iic runtime file, see What's the difference between a User Definition, an ID Definition, and the .iic Identity file?.

Is a User Definition shareable or portable? Yes, but not as a standalone artifact. There is no .user-style export format and no API to detach a User Definition from its Identity and send it on its own. User Definitions travel through the Identities and Vaults that carry them:

• As part of a .iic Identity file. The Identity is what you share; every User Definition inside it rides along, protected by the .iic's UXP wrapper. Cross-platform binary-portable across macOS, Windows, and Linux (iOS and Android are on the roadmap).
• As part of a workgroup Identity. User Definitions from multiple members' Identities are imported into a combined .iic (the canonical "import without exposing" path). See What is a workgroup Identity?.
• As part of a .uxp Vault. At creation, the protected ID Definition (including all its User Definitions) is copied into the Vault itself. The Vault can be opened by anyone whose Identity matches one of those embedded Users, and the original .iic doesn't need to be present. See What is an Identity? for the full list of sharing pathways.

What "without exposing private data" means concretely. When a User Definition is imported from one Identity into another, the private credential material (challenge responses, Secure Strings, recovery policy values) is transferred only in its protected form. At no point during the import does any of that credential material exist as cleartext outside a Vault. Once embedded in the destination Identity, those credentials remain accessible only inside the protected runtime context of the resulting .iic, or of any Vault that Identity goes on to create. The same FIPS 140-3 validated AES protection and Secure-String handling that governed them in the source Identity continue to govern them in the destination. See What encryption does UXP Technology use? and What are Sertainty Secure Strings?.

These three terms describe related artifacts at different layers: the block that belongs to a single owner (User Definition), the source form (ID Definition XML), and the runtime form (.iic Identity). They are often used interchangeably in casual conversation, but they are not the same thing.

How they build on each other. An owner authors a User Definition (private to that owner). One or more User Definitions get assembled into an ID Definition XML, together with the Identity-level rules and metadata. The XML is then compiled into a .iic Identity file, the runtime artifact.

The ID Definition XML (including any <User> blocks) is source; see What is an ID Definition (ID Def)? for the security posture.

A useful summary:

• User Definition — one owner's private credentials block.
• ID Definition — the source recipe that assembles one or more User Definitions with rules.
• .iic — the compiled Identity that runs in production.
• Source-code-sensitive — the XML form of either the ID Definition or a User Definition.

An Identity Library is the store where Tech Hub keeps one or more Identities so Identity Studio can open, author, and edit them in one place. On disk it is a single .idb file (default name idlibrary.idb) that is itself a Vault, protected by the Identity that created it. Think of it as the "folder" of Identities, except that the folder is itself a self-protecting Vault: distributing the .idb to another authorized party gives them a complete, protected set of Identities to work with.

A library is always created by an Identity, and that Identity (and anyone else granted access through it) is who can open it later. The initial library is produced during Tech Hub setup and seeded with the login Identity for the new account; additional libraries can be created or opened at any time from the Identity Studio toolbar.

Why keep more than one library. One library can hold many Identities, so a single library is enough for most individual users. Multiple libraries become useful for:

• Separation of concerns — dev vs. production Identities, project A vs. project B, personal vs. team Identities kept in different stores.
• Controlled sharing — a library (and only the Identities inside it) can be handed to a colleague, team, or server operator; nothing else from your workspace travels with it.
• Different protecting Identities — a library protected by a workgroup or project Identity gives access to that group without exposing your personal login Identity's library.

Related settings. Preferences → User names your Preferred Library (the one Identity Studio opens by default) and controls whether the Open Identity Library dialog is skipped or whether the current Tech Hub session is used to unlock the library automatically. See What is Identity Studio?, What is an Identity?, and the Identity Library glossary term. For step-by-step detail, see Sertainty Tech Hub Guide, Opening an Identity Library and Sertainty Tech Hub Guide, Creating a new library.

A workgroup Identity is a use case for an Identity, not a different kind of Identity. Structurally and cryptographically it is identical to a single-user Identity; the only difference is how the <Users> block is populated. It is useful when a Vault needs to be accessible to multiple humans, machines, or processes at once: the resulting .iic authenticates any of the assembled members into the same shared Vault.

A workgroup Identity is typically assembled from members who already have their own individual Identities, contributing specific private attributes into the workgroup. That contribution is a protected import, not a copy of cleartext credentials: challenge responses and Secure Strings transfer only in their protected form and never exist as cleartext outside a Vault. Once embedded in the workgroup Identity, those credentials remain accessible only inside the protected runtime context of the workgroup .iic (and any Vault it creates). See What is a User Definition? for the full mechanics.

Members can be all human, all machine, all process, or any combination. Mixing humans with machines or processes is typically a backup-access pattern: a human User Definition is added as a fallback path into a Vault that is otherwise accessed by automation. The authentication flow is the same either way.

A machine Identity is an Identity created for servers, laptops, desktops, and automated processes, anywhere authentication must happen without a person typing at a prompt. Machine Identities operate the same way as human Identities (one or more User Definitions, challenge pairs, embedded rules), with the difference being in the authentication process:

• All challenges are answered accurately, with no judgment call decisions at runtime.
• Responses complete in sub-second time.
• Most challenges are marked Required rather than optional, so the engine does not pick from a randomized subset.

In setup, challenge pairs are typically auto-generated (randomized prompts and responses), since no human needs to remember them. The credential strings the application uses to authenticate are stored as Sertainty Secure Strings, which protects the values on disk and in memory so external tools cannot extract them.

Machine Identities are strong candidates for automated processes and workflows:

• Workflow Service task executors
• Embedded devices in IIoT deployments
• Scheduled batch jobs
• Any automation that creates or opens Vaults without a human in the loop

A Vault is the self-protecting digital data vault. It is a portable, self-contained protected container that can hold one or many folders and files, images, audio, video, structured SQL data, or any other unstructured data. The file extension is .uxp. The Vault holds the protected data; the Identity (.iic) is the key and access policy that opens it. See What's the difference between an Identity (.iic) and a Vault file (.uxp)? for the full contrast.

What sets a Vault apart from an encrypted file is that the protection is embedded in the object itself rather than dependent on an external key store. There is no separate file to decrypt, no password to share, and no infrastructure that has to be reachable to open it. Authentication is a local conversation between the Vault and whoever is trying to open it.

Components inside a Vault. Every Vault carries three things that travel together as one binary file:

• A header. Identifies the file as a Vault. If the Vault has been destroyed by rule, only this small header remains on disk as a tombstone. See Can a Vault really self-destruct, and under what conditions?.
• The embedded Identity details. When a Vault is created, the necessary components from the Identity (including User Definitions with their challenges, and rules) are embedded into the Vault; unnecessary items are left behind. This is why the original .iic doesn't need to be present at open time. What is an Identity? covers what an Identity contributes.
• The protected payload. One or more virtual files (any byte stream: office docs, multimedia, engineering files, source code, archives, VM images) and, optionally, a UXP SQL database (SQLite-compatible relational data, with the same authentication and rules gating queries and writes). See What is UXP SQL? and What kinds of data can a Vault protect?.

Encryption is FIPS 140-3 validated AES provided by wolfCrypt, with Sertainty's non-cryptographic key management, identity binding, and policy layer around it. Keys are randomly generated (by wolfCrypt) and scattered among the user data. See What encryption does UXP Technology use? for the full crypto architecture.

See also:

• What can a Vault do?
• How is a Vault shared?

A Vault has a set of runtime capabilities beyond simply storing bytes:

• Hold any file type. The engine treats every input as a byte stream, so it can protect office documents, multimedia, engineering files, archives, or arbitrary binary content. No MIME-type registry to update, no per-format plugin.
• Random-access read and write while protected. Only the bytes being requested are unprotected in memory; everything else stays encrypted. Seek and retrieve any amount at any offset.
• Add, remove, or modify virtual files without re-protecting. Individual virtual files can be updated without rewriting the whole Vault.
• Enforce its own access rules at every open. Host locks, location locks, time and schedule restrictions, expiration dates, read-only modes, recovery rules; all configurable in the Identity that created the Vault.
• Binary-portable across platforms. A Vault created on macOS opens on Windows or Linux given the matching Identity; iOS and Android are on the roadmap. See Can I create a Vault on one operating system and open it on another?.
• Arbitrary size, tunable for performance. The same engine handles a 4 KB config file or a 100 GB VM image. The Vault is internally divided into pages, which is what enables the random-access reads and writes described above. The default page size is 8 MB (configurable up to a maximum of 16 MB); smaller page sizes increase per-operation overhead and reduce performance, so page size is a knob to tune based on workload. Cache: 0 to 20 buffers per virtual file held in memory at once. (The system-wide buffers user preference caps the pool the engine may draw from, up to 50; it does not increase the per-file cache itself.)
• Optional Domain. A Vault can be created within a named Domain, which adds a layer of obfuscation: a Vault from one Domain cannot be opened by a process that doesn't know that Domain. Domains are not a security gate (knowledge of the Domain by itself doesn't grant access; the Identity still has to authenticate). They're a soft segregation mechanism for keeping unrelated Vaults from accidentally crossing streams in shared environments.
• Communicate with a Sertainty server when configured to. Reporting access events to a central server is opt-in via rule configuration, not a default behavior. NIST time-server alignment is available for time-sensitive compliance scenarios.

The complete capability list with every supported option lives in the Vault specifications section under the Introduction chapter of the Sertainty Technology Guide.

Vaults are designed to be shared. Because the protection travels with the file, the transport channel doesn't need to be the security boundary, and copying or intercepting a .uxp in transit doesn't expose its contents. Typical distribution patterns:

• Ordinary file sharing channels. Cloud storage (Box, Dropbox, OneDrive), FTP, internal file servers, email attachments. The channel can be untrusted because the protection travels with the data, so only the intended recipient can access the file. See Can Sertainty Workflow integrate with my existing file sharing system?.
• Email-proxy delivery for attachments. A proxy address receives email, extracts the attachment, drops it into a per-customer folder where Auto-Protect wraps it with that customer's Identity, then transports the Vault to the recipient where Auto-Unprotect makes it available. See Can I use Sertainty Workflow for protected email attachments?.
• One folder per Destination for multi-recipient distribution. When the same source data must go to several recipients with different protection, the pattern is one Source folder per Destination, each with an Auto-Protect task using that recipient's Identity. Dropping a file into all three folders produces three separate Vaults, each accessible only to its intended recipient. See How do I send protected files to multiple recipients, each getting different protection?.
• Workflow Service automation. Source-Destination pipelines automate the protect-transport-unprotect cycle end to end (Auto-Protect on the way out, Auto-Unprotect on the way in). See What is the Workflow Service and when would I use it?.
• Long term archive. Archive is just another Destination. Auto-Protect protects files with an archive-only Identity; the Vault lands in storage (cloud bucket, NAS, cold tier) and can be accessed later only by that archive Destination. See Can I use Sertainty Workflow for long term archive, not just in-flight transfers?.
• Round-trip edit and return. Recipients can open a Vault, edit a virtual file inside it, and send it back without the round-trip exposing contents on either leg. See Can a recipient edit a Vault and send the updates back?.

For Vaults too big for a size-limited transport (email attachment caps, ticket-system uploads, certain partner FTP gateways), Sertainty Workflow ships a paired Split / Join UXL script set. Split breaks the Vault into pieces sized to the transport's limit; Join reassembles them byte-for-byte at the other end. The pieces remain UXP-encoded throughout, so interception of fragments yields fragments of an encrypted file, not plaintext.

UXP SQL is a feature of Vaults that lets structured (relational) data live inside the same protected container alongside unstructured files. Instead of treating a Vault as a simple file archive, you can also treat it as a small SQLite-compatible database (run queries, insert and update rows, maintain tables) with all the storage protected by the surrounding UXP encryption.

Why use it:

• Co-located data and files. A document management system can store both the documents and the metadata catalog about them in the same Vault: one artifact to share, back up, or expire.
• Query-friendly access. Pulling records by criteria is faster and simpler than parsing XML or JSON manually inside the Vault.
• Inherits UXP protection. The SQL engine runs behind the UXP Engine's authentication, so queries and writes are governed by the same user, challenge, and rule system that governs file access.

UXP SQL follows standard SQLite syntax with Sertainty-specific extensions for access control. The Services Reference Guide's Data Service chapter covers how server-side Data Services use UXP SQL as their own backing store, and ~/Sertainty/Developer/examples/cpp/ shows practical usage patterns.

Restrictions. A few SQLite capabilities are intentionally not exposed inside a Vault, to keep the protection boundary intact:

• The underlying SQL engine's metadata tables cannot be queried directly.
• UXP Technology's own private internal tables (used for keys, audit records, and access state) are not accessible from a UXP SQL query.
• The UXP SQL database is not accessible as a plain SQLite file by external applications; the only access path is through the UXP Engine, which gates every query on the embedded authentication and rule policy.

Both are opaque binary files produced by the Application Development Kit, but they serve very different roles.

A useful mental model: the .iic is the key + access policy, the .uxp is the vault. A user (or machine, or workgroup) can hold one or many Identities, each with its own purpose, challenges, and rules; each Identity can then be used to create as many Vaults as you need.

Yes. A Vault requires at least one User Definition but can have many. Each user has their own username and private set of challenge pairs, and rules can be scoped globally or per user. When rules conflict, the UXP engine chooses the more restrictive setting.

User definitions can also be imported from another Identity, which lets you build a shared Identity containing multiple users without exposing their private data. The import transfers credential material (challenge responses, Secure Strings) only in its protected form; at no point during the import does it exist as cleartext outside a Vault, and in the destination Identity it remains accessible only inside that Identity's (or any derived Vault's) protected runtime context. See What is a User Definition? for the full mechanics, and the Multi-User Access section of the Sertainty Technology Guide's Core Framework chapter for the Application Development Kit reference.

Yes. The .uxp and .iic file formats are binary-portable across every Vault-supported platform. A Vault created on macOS can be opened on Windows or Linux without any conversion or repackaging. The same applies to Identity files. Mobile wrappers (iOS/Swift, Android/Java) are on the roadmap and will extend the same binary-portable behavior to mobile once available.

What gates access is the user's ability to correctly respond to the challenges defined when the Vault was created, not the operating system. Anyone (person, machine, or process) who can accurately answer those challenges can open the Vault regardless of where it was created or where they are; see Can a Vault authenticate users without any network connectivity? for the local-authentication mechanism. Two practical notes:

• A user who knows their challenge responses can open the Vault on any supported device. The same Vault, opened on a laptop, a desktop, or a phone, presents the same challenges; correct responses authenticate regardless of device. The Identity identifies the user, not the device.
• Host-locked or location-locked Vaults are the intentional exception. If the Vault was created with a hardware fingerprint or a geo fence rule, the policy will refuse access on a different machine even when the responses are correct. That lock is a feature, not a portability bug. See How does a Vault authorize users beyond just authenticating them? under Access Policies for the full list of rules that can constrain where a Vault can be opened.

For the technical properties that make this work, see What is a Vault?. For the round-trip edit case (open it, modify it, send it back), see Can a recipient edit a Vault and send the updates back? under Working with Vaults.

A SmartMessage is a protected data entity that does not reside inside a Vault. It can be an in-memory buffer or a persistent on-disk file. SmartMessages are designed for communications between secure peers, for example utilities infrastructure, device-to-device links, or person-to-person messaging.

Use a Vault when you're storing or sharing files and folders. Use a SmartMessage when you're sending a protected payload over a channel and don't need the full container semantics.

To build one programmatically:

1. Assemble the payload as a bytearray.
2. Call the SmartMessage API to wrap it. Use the sm:: namespace for identity-based exchange or the smex:: namespace for anonymous Exchange flows.
3. Hand the resulting buffer to your transport.
4. On the other end, the receiver authenticates with their Identity and the API returns the original payload.

Working examples live in ~/Sertainty/Developer/examples/cpp/, and the SmartMessage section of the Sertainty Technology Guide's Core Framework chapter has the full API surface.

One important difference from Vaults. A Vault carries its protected definition (challenges, rules, user definitions) inside itself, so the original .iic does not need to be present at open time. SmartMessages are different: the receiver's .iic Identity must be present at the time the SmartMessage is decrypted. The Identity is what unlocks the payload. SMEX (the anonymous variant) substitutes a one-time shared token for the Identity, but the same principle applies: the credential travels separately from the message and must be present at the receive end.

SMEX (SmartMessage Exchange) is a SmartMessage pattern designed for one-off, anonymous peer-to-peer delivery where neither side has a pre-existing Identity relationship with the other.

In a normal SmartMessage, sender and receiver each have known Identities, and authentication follows the usual challenge-response flow. SMEX lifts that requirement: the sender encrypts a message using a one-time symmetric derivation, and the receiver decrypts it with a shared token that's delivered out-of-band, like a phone call, a QR code, or printed on paper.

Typical use cases:

• Sending sensitive data to someone you've never exchanged identities with (a first-contact secure handoff).
• Hand-off protocols between utilities, IoT devices, or third parties where provisioning a full Identity for every participant is impractical.
• Short-lived one-shot deliveries that don't warrant a persistent identity.

SMEX is an extension of the SmartMessage functionality, not a replacement. Use a regular SmartMessage when identities exist, SMEX when they don't.

Single-Sign-On (SSO) is a special session established from an Identity that can proxy the current user's credentials into subsequent Vault authentications. The user responds to their challenges once at the start of a session, and any Vaults opened during that session authenticate against the SSO session without prompting again.

Under the hood: you log into an Identity as usual. With SSO enabled, the ID engine holds the authenticated state. When a Vault is opened, it can ask the SSO session to authenticate on the user's behalf. If the SSO session is a valid member of the Vault (matching username and credentials), access is granted silently. If not, the user falls back to the normal challenge prompts.

SSO sessions are local to the current application; they don't leak across processes or machines. They're most useful when a single user opens many Vaults in the same working session, for example browsing a folder of protected files.

Vaults use industry-standard, FIPS 140-3 validated AES encryption at the cryptographic core (wolfCrypt v5.2.1, commercial FIPS build from wolfSSL Inc., CMVP certificate #4718, operating in FIPS mode; used unmodified, within its validated boundary). Encryption keys are randomly generated and scattered among the user data rather than stored in a single location.

All cryptographic operations — encryption, hashing, random number generation, and key derivation — are performed by wolfCrypt. Sertainty does not implement any cryptographic primitives. What Sertainty adds is the non-cryptographic layer around wolfCrypt: identity binding, dynamic key management within the Vault, access policy evaluation, and the dynamic protection envelope's orchestration. This is why the FIPS validation of wolfCrypt covers every cryptographic operation in the technology — there is no Sertainty-written crypto outside that boundary.

All keys are maintained and managed inside each Vault. They are never shared, never visible in clear form, and no external key store is used. This means protection travels with the object itself: there is no separate system to compromise and no key-management infrastructure to operate.

Key access is itself gated by the Vault's policies, so an attacker who somehow extracted a key fragment without satisfying the policy still couldn't use it. Different pages within a single Vault can also carry their own unique keys, which enables selective access: granting a user the ability to read part of an object without exposing the rest. See How does UXP Technology support selective or partial decryption? for the broader access-granularity model.

Web-service messages to and from the Server framework are encoded with AES-256 GCM using a 32-character private access code as the key. Each request uses a fresh 12-byte random initialization vector and carries a 16-byte authentication tag. See the Encoding and decoding service messages section of the Sertainty Services Reference Guide.

UXP supports access at multiple granularities, so a Vault does not need to be unprotected as a single all-or-nothing block. Three related properties cover different angles of this:

• Selective access. Who can read what. Different pages within a single Vault can carry their own unique keys. Combined with per-User privileges in the embedded Identity, this enables granting a user the ability to read part of an object without exposing the rest. See What encryption does UXP Technology use?.
• Partial unprotection. How much is unprotected at runtime. For compatible data types, only the portion the application currently needs is unprotected, while the rest stays protected inside the object. When the in-use portion is no longer needed, it is released. See Does a Vault protect data while it's in use, or only at rest and in flight?.
• Just-in-time decryption. For how long plaintext exists. Sensitive values are decrypted only when actually needed for a specific operation, then zeroed out when no longer required. See What are Sertainty Secure Strings?.

The three combine to minimize what plaintext is exposed, when, and to whom. A Vault holding a multi-page report can grant page 3 only to a particular user; the application can unprotect page 3 at the moment it is rendered without exposing the surrounding pages; and any sensitive credential used internally during that operation is decrypted only for the call that uses it.

Yes. All cryptographic operations are performed by wolfCrypt v5.2.1 (commercial FIPS build from wolfSSL Inc.), CMVP certificate #4718, operating in FIPS mode. This is the specific formulation to use in security questionnaires, reviewer-facing materials, and platform overviews.

Any project that plans to be or is required to be FIPS 140-3 validated has the correct cryptographic starting point when building on the Sertainty UXP Technology. See What encryption does UXP Technology use? for where those algorithms are applied within a Vault and across the Server framework.

No. The application itself needs to be independently FIPS 140-3 validated through its own CMVP (Cryptographic Module Validation Program) review. However, there's an important distinction:

• If the app calls the UXP APIs to perform cryptographic operations, it is using a validated cryptographic module. The app can generally claim it uses FIPS validated cryptography without its own certification, as long as the cryptographic boundary is properly maintained.
• If the app itself implements or wraps cryptographic operations in a way that sits between the caller and the validated module, that could break the cryptographic boundary and require its own validation.

Specific government or regulated-industry contracts can impose stricter interpretations, so it's worth verifying requirements with the contracting agency or a compliance attorney for your specific context.

See Does Sertainty use FIPS-validated cryptography? for what's covered on the Sertainty side.

A plain language threat model. Security and procurement reviewers can use this as the orientation map; the rest of the section drills into each defense.

What UXP is designed to defeat:

• Network interception (data in flight). Channel-level encryption is supplemented by UXP's own protection envelope, so a wire-tap on TLS-stripped traffic still yields encrypted bytes. See What encryption does UXP Technology use?.
• The lost device, or a file that leaves your environment. A Vault carries its own rules. On a thumb drive in a parking lot, it still refuses to open without satisfying the original Identity's challenges. See Does Vault protection still apply if a file leaves my secure environment?.
• Brute force on credentials. Challenge subsets randomize at authentication time; unacceptable responses stay secret; trust score and failure handling rules govern lock-out behavior. See How is Vault authentication different from username and password? and What rules govern challenge responses?.
• Coerced authentication ("wrench attack"). A user under duress can authenticate into a decoy workspace with innocuous content while the real data stays hidden. See What is "Alternate Reality" mode?.
• Credential exfiltration during entry. Response masking transforms what the user types into the expected response without exposing the underlying secret to a key logger or shoulder surfer. See What is response masking?.
• Quantum cryptanalysis (Quantum Resistant). UXP doesn't rely on a public key infrastructure, so Shor's algorithm has no factoring target. See How resistant is UXP Technology to quantum attacks (including "harvest now, decrypt later")?.
• AI agents and AI-driven attacks. An AI agent cannot read the content of a Vault unless it has been specifically granted access through an Identity. AI-driven inference and pattern mining also fail: the protection scheme is dynamic rather than static, so attack patterns that work against conventional ciphertext do not transfer. See Can an AI agent access the content of a Vault?.
• "Harvest now, decrypt later." Long-term confidentiality is preserved against future cryptanalytic advances. See How resistant is UXP Technology to quantum attacks (including "harvest now, decrypt later")?.
• Unauthorized location or device. Geo-fences, host fingerprinting, and network policies refuse to authenticate even when credentials are correct. See Access Policies.
• Stale credentials after sharing (Delegate managed). A revoked user loses access on next server check-in. See What is the Delegate Service, and when should I use it?.

What UXP does not defend against (out of scope):

• A fully compromised OS or kernel rootkit. Once the OS is hostile to the running process, in-memory protections become reachable. UXP raises the cost of in-memory attacks and includes tamper resistance in the engine itself, but a kernel-level adversary is outside the design goals. See Does a Vault protect data while it's in use, or only at rest and in flight?.
• Malware running as the authenticated user. Once a legitimate user has opened a Vault, anything in their session has the same access they do. UXP cannot distinguish "user typing" from "malware impersonating user."
• A legitimate insider abusing their own access. A Vault authenticates that a user is who they claim to be; it does not measure whether they are trustworthy. Audit logging, alerts, and access events feed your detective controls; the cryptographic boundary is not the right tool here.
• Side-channel attacks (timing, power, electromagnetic). Not part of UXP's design goals.
• Whatever sits outside the cryptographic boundary in your application. If your application caches plaintext, logs decrypted bytes, or implements its own crypto on top of UXP-extracted data, protection ends where the boundary ends. See What is the "cryptographic boundary"?.

The Sertainty Development Kit libraries are designed to be highly tamper resistant. Beyond the encryption used to protect Vaults (industry-standard, FIPS 140-3 validated AES 256, see What encryption does UXP Technology use?), the libraries themselves include multi-layer tamper resistance:

• Protection against binary modification
• Protection against debugger attachment
• Protection against external runtime inspection

Tampered or instrumented libraries are detected and refused.

The specific defensive mechanisms are not publicly documented, to limit an attacker's information advantage. For the explicit boundary of what Sertainty does and does not defend against, see What attacker is UXP Technology designed to defeat?.

The UXP protection scheme is designed to be highly resistant to both quantum and AI-based attacks. Resistance comes from two complementary sources:

• The cryptographic core. All cryptographic operations are performed by wolfCrypt's FIPS 140-3 validated AES-256, which NIST considers quantum-resistant at 256-bit key length (symmetric ciphers are not the target of Shor's algorithm; a doubled key length addresses Grover's).
• The non-cryptographic layer around it. Sertainty developed algorithms — which do not perform any cryptography — add dynamic key management, key scattering across pages, and a dynamic protection envelope, so attack patterns that work against conventional static-key ciphertext do not transfer cleanly.

In-memory protections resist external inspection, and the engine includes built-in attack mitigation. For how Vaults keep AI agents out, see Can an AI agent access the content of a Vault?.

The specific risk to most encrypted data is Shor's algorithm running on a sufficiently large quantum computer: it can factor large integers fast enough to derive a private key from a published public key, breaking RSA, ECC, and any TLS session that depends on them. UXP doesn't use a public/private key infrastructure for its protection: there are no key pairs to factor, and no public key is ever published, so the scheme is not in the threat model Shor targets.

Harvest now, decrypt later. A harvesting attack is when an adversary intercepts encrypted traffic or files today, stores them cheaply, and waits for future cryptanalysis (typically a viable quantum computer) to crack them retroactively. Anything protected by conventional public key encryption is potentially vulnerable to this even if it's safe in today's terms, and cheap storage plus the proliferation of valuable data online increase both the feasibility and the incentive for this kind of long-term collection. Because UXP doesn't rely on a public/private key pair to gate access, a harvested Vault remains protected regardless of how compute capability evolves; there's no future key-derivation event that would unlock the stockpile.

No, not unless it has been specifically granted access through an Identity. A Vault opens only for a person, machine, process or other digital entity that satisfies the challenges of an Identity defined when the Vault was created. An AI agent is no exception.

This means AI assistants, search and indexing tools, and autonomous agents that come across a Vault file see only protected data, wherever the file sits: a shared drive, an email attachment or cloud storage. There is nothing in the Vault for them to read, summarize, index or learn from.

When an organization does want an AI agent to work with protected data, it gives the agent its own Identity, typically a machine Identity (see What is a machine ID?). That Identity carries the same controls as any other:

• Least privilege. Grant only the privileges the agent needs, for example Files without Imports.
• Access rules. Host fingerprints, geo fences, expiration dates and failure thresholds limit where and for how long the agent can authenticate.
• Audit. Every open, extraction and failed attempt can be recorded to the Vault, the Sertainty Data Registry or a SIEM, so the agent's access is attributable.
• Revocation. Remove the agent's access when it is no longer needed. With Delegate-managed users, access ends on the next server check-in without rebuilding Vaults.

Separately, the protection scheme itself resists AI-driven cryptanalysis and pattern mining. See How resistant is UXP Technology to quantum attacks (including "harvest now, decrypt later")?.

Yes. A Vault carries its access controls, policies, and mitigation logic inside the file, so protection doesn't depend on the network, firewalls, access control lists (ACLs), or any other enterprise control surface. A Vault file emailed to the wrong recipient, copied to a USB stick, or uploaded to an unsecured share is just as protected as one sitting on a hardened server.

UXP can work alongside an existing perimeter, but it doesn't require one. This is what makes ordinary file sharing channels (cloud storage, FTP, email) usable as transport without becoming the security boundary: the protection travels with the data.

It stays protected. A Vault carries its own access controls, keys and policies inside the file, so an attacker who breaks into the server where Vaults are stored does not gain the ability to open them. A Vault file copied off a compromised server is unreadable data: opening it still requires Sertainty software and correct responses to the challenges of an authorized Identity. See Does Vault protection still apply if a file leaves my secure environment?.

This matters most when a server can't be patched quickly, or was breached before anyone noticed:

• No keys to steal on the server. Keys are maintained inside each Vault, and no external key store is used, so there is nothing on the server that unlocks the Vaults it holds.
• Independent of network defenses. Firewalls, web application firewalls and intrusion prevention systems can be bypassed. Vault protection does not depend on them.
• Harvested Vaults stay protected. Because UXP does not rely on a public/private key pair, a Vault taken today has no future key-derivation event that would unlock it. See How resistant is UXP Technology to quantum attacks (including "harvest now, decrypt later")?.
• Access can be revoked centrally. With Delegate-managed users, a revoked user loses access on the next server check-in, without rebuilding Vaults. See What is the Delegate Service, and when should I use it?.
• Attempts are recorded. When someone tries to open a Vault with Sertainty software, the attempt is recorded, successful or not. See How does the Data Registry track Vault events?. A Vault that is copied but never opened with Sertainty software is inert data, so no event is generated. The same applies to attempts to break into a copied Vault without Sertainty software, such as brute-force attacks: nothing in the Vault is running to record them. Brute-force attacks against Vaults have proven unsuccessful.

What a compromised server can still expose:

• Processes that legitimately hold an Identity. An attacker running code inside an application that opens Vaults automatically, for example with a machine Identity, gets the same access as that application. Least privilege, access rules and partial unprotection limit how much is exposed. See How does UXP Technology support selective or partial decryption?.
• Data outside Vaults. Plaintext the application has extracted, cached or logged is not protected by the Vault it came from.
• A fully compromised operating system. A kernel-level adversary is outside UXP's design goals. See What attacker is UXP Technology designed to defeat?.

Patching, network controls and incident response remain essential. Vault protection limits what an intruder can take; it does not remove the intruder.

Yes. Vaults are autonomous: authentication and authorization functions are embedded in the data object itself, not delegated to an external server or directory. There's no callout to Active Directory (AD), no OpenID Connect (OIDC) round-trip, no central authentication/authorization (A/A) server requirement, and a Vault itself does not need to be reachable for authentication to succeed. No UXP Technology service, server, or network infrastructure is involved in the authentication flow.

What is required is that the person, machine, or process trying to open the Vault can correctly respond to the challenges defined at creation time. When the Vault is created, the Identity's User Definitions (with their challenges) and rules are embedded into the Vault, so they travel inside the file itself. The original .iic file does not need to be present at open time. The specific person, machine, or process defined in the Identity authenticates locally when they provide the correct responses and the Vault's other rules (time windows, host locks, geo fences, expiration) are satisfied. Authentication is a local conversation between the Vault and whoever is trying to open it.

This makes UXP usable in environments where reaching a server isn't possible: battlefields, ships, aircraft, air-gapped facilities, or remote field deployments. The same Vault behaves identically online and offline. The engine prompts for the user's challenge responses and validates them locally against the User Definitions embedded in the Vault.

Delegate-based Vaults are the one exception. They need either online resolution or a valid local cache. See How does offline access work with Delegate caching? for that path.

UXP is data-type agnostic: the engine treats every input as a collection of bytes. In practice that means:

• Office documents (Word, Excel, PowerPoint, PDF)
• Multimedia files (audio, video, images)
• Engineering files (CAD/CAM drawings, simulation outputs)
• Financial and healthcare records
• Source code, build artifacts, configuration
• Structured data inside SQLite tables (via UXP SQL)

Any file or folder of files can be wrapped. There's no MIME-type registry to update, no per-format plugin to install, and no size class above which UXP stops working: the same protection mechanism applies to a 4 KB config file and a 100 GB VM image.

All three. Most encryption schemes only cover at-rest and in-flight states: when an application actually uses the data it has to be decrypted in full, which exposes the entire payload in memory for the duration of the read. UXP supports partial unprotection: for compatible data types, only the portion the application currently needs is unprotected, while the rest stays protected inside the object. When the in-use portion is no longer needed, it's released. See How does UXP Technology support selective or partial decryption? for how partial unprotection fits with selective access and just-in-time decryption.

This narrows the window an attacker has to scrape sensitive data out of memory, and means a process crash mid-read doesn't leak the whole file.

A Sertainty Secure String is a string value stored with cryptographic protection both on disk and in memory. Instead of sitting as plain text that external tools could extract, a Secure String is encrypted at rest, decrypted just-in-time for use, and zeroed out when no longer needed. See How does UXP Technology support selective or partial decryption? for the broader just-in-time and selective-access pattern.

Typical uses:

• Embedding machine-ID credentials in an application binary: the response values for a machine's challenges live as Secure Strings so a disassembler can't pattern-match them against known formats.
• Holding sensitive configuration values (access codes, database passwords, server URLs) inside a running process.
• Protecting private keys or tokens that need to live in memory temporarily.

Secure Strings are not a replacement for a Vault; they're a finer-grained tool for protecting individual values within code or configuration. The UXP Engine uses them internally for its own credential handling; the public API exposes them for application use too.

Yes. Through the RestrictionsSetup rules, a Vault can be configured to take protective actions in response to a variety of environmental conditions:

• Unrecognized hardware, network location, or file location
• Access outside the permitted schedule
• Untrusted operating system (for example, an unknown virtual machine)
• Untrusted system time
• Too many failed authentication attempts (see MaximumTotalFailures)

When triggered, the Vault can take a range of mitigation actions: deny access, require approval, force an alternate workspace, add extra challenges, or one of the two destructive options:

• Shred a virtual file on delete. An individual virtual file inside the Vault is securely overwritten as part of its deletion. Triggered through the ModifierShred flag on the delete operation. The other virtual files in the Vault and the Vault itself remain intact.
• Shred and destroy the Vault. A rule-triggered action that securely overwrites the contents of the entire Vault and removes the Vault itself, leaving only a small header on disk indicating that the Vault has been destroyed.

Both options are configured at Vault creation through the policy rules and fire automatically when their trigger conditions are met. Neither is recoverable.

A caveat for solid-state storage. Electronic shred provides no security benefit on SSD or NVMe storage due to wear-leveling and block remapping; the overwrite cannot reliably reach the physical locations that previously held the data. The destructive actions still complete at the logical level but cannot guarantee physical-level erasure on solid-state media.

Additionally, the library itself contains tamper-detection. Manual modifications to a Sertainty library render it inoperable, and attempts to debug the library may trigger routines that destroy the current Sertainty system and the host application.

Alternate Reality is a workspace isolation feature that lets a Vault serve different content depending on whether the access attempt is considered trusted. It is Sertainty's implementation of what's broadly known in cyber-deception terminology as a decoy (or, in older literature, an embedded honeypot), but unlike a separate decoy system, it lives inside the Vault itself and is triggered by the same rule engine that governs other policy mitigations.

The default workspace is named "Public." A Vault can be configured so that when the engine detects an unrecognized hardware, network, location, schedule, or time signature, it doesn't deny access outright: it silently switches to an alternate workspace. The user sees content from that alternate workspace instead of the real files, and from their perspective nothing looks wrong.

Alternate Reality is also one of the configurable mitigation actions for any policy violation: instead of (or in addition to) denying access, the engine routes the attacker into the alternate workspace. The decoy content is embedded in the Vault at creation time, so it ships with the object and doesn't need a network callback to deliver.

The practical use case is plausible deniability: under coercion, a user can authenticate into an alternate workspace that contains innocuous decoy content, while the real data stays hidden in the Public workspace. The rules that trigger alternate reality (ConfigurationAltReality, HardwareAltReality, NetworkAltReality, ScheduleAltReality, and others) are set up in the ID definition and require a special license to enable.

Yes. Sertainty UXP Technology aligns directly with the "never trust, always verify" principle at the core of NIST's Zero Trust Architecture (SP 800-207).

Sertainty applies Zero Trust at the data layer, which complements (rather than replaces) network-layer and identity-layer Zero Trust implementations:

• Never trust the channel. Vaults do not assume the network is secure. Channel-level encryption is supplemented by UXP's own protection envelope, so transport-layer compromise alone does not yield plaintext.
• Never trust the device. Every access attempt is authenticated against the policies embedded in the Vault. Host, network, and geo rules are evaluated at every open. See Access Policies.
• Never trust prior authentication. Re-authentication is required on each access. Trust scores can reduce the number of challenges presented to a high-trust session, but they do not bypass the verification step. See How is Vault authentication different from username and password?.
• Verify based on policy, not just identity. Even valid credentials are rejected if the access attempt fails any configured rule (wrong network, wrong time window, wrong host).

What Sertainty does not claim is to implement the network-layer and identity-layer components of Zero Trust. Those (micro-segmentation, identity-aware proxies, continuous network monitoring) are typically provided by other vendors and integrate with UXP at the application layer.

DRM and UXP solve different problems with different architectures, though they are often grouped together because both restrict access to digital content.

What DRM is built for. Digital Rights Management is designed to enforce licensing terms: limit playback to authorized devices, prevent copying, enforce time-based licenses. DRM systems typically rely on a central license server and an encrypted content stream with keys shared between the issuing authority and authorized players.

Where DRM is vulnerable. Most DRM is defeated by attacks on the key exchange, the licensing server, or the player itself, a pattern documented in widely available tools for stripping DRM from videos, audio, games, and protected documents.

How UXP is different:

• Keys are never shared or exposed. Vaults use AES 256 encryption keys that are randomly generated, scattered among the protected data, and managed inside the object itself, never published, never transmitted, never sitting in a key vault. See What encryption does UXP Technology use?.
• No central license server in the access path. The UXP Engine authenticates locally against the embedded Identity. No round-trip to a licensing authority is required.
• Policy is configurable per object. A Vault's protection (time restrictions, location restrictions, user privileges, mitigating actions on policy violation) is set at creation and travels inside the file. There is no centralized policy engine to compromise.
• The threat model differs. UXP is designed to protect data confidentiality even on hostile channels and recipients. DRM's threat model assumes most users are honest and tries to catch the few who are not. See What attacker is UXP Technology designed to defeat? for the explicit threat boundary.

Blockchain and Sertainty operate in different security domains and solve different problems.

Blockchain is a distributed-ledger technology focused on transaction integrity and immutability. The data inside a blockchain (Bitcoin transactions, Ethereum state, NFT records) is public by design, anyone with a node can read every transaction. What blockchain protects is the history: once a block is appended and accepted by the network, altering it requires altering every subsequent block on a majority of nodes, which is computationally infeasible in production networks. Blockchain is not a data confidentiality mechanism.

Sertainty UXP Technology is a data confidentiality and access-control technology. The content of a Vault is not readable without satisfying the Identity's authentication and policy rules. UXP is not a transaction ledger, it does not track sequences of immutable operations across distributed parties.

The two technologies are complementary, not competitive. Each answers a different question:

Both technologies maintain an audit record of what happened, and neither record can be changed after the fact. There are two differences: scope and visibility. Blockchain is a distributed public ledger — the record is held across the network, and anyone with a node can read every entry. Sertainty's Vault event records are protected (never clear text in flight or at rest). Where they are recorded is configured through the Identity's EventSetup rule, with the Server-side Data Registry as the suggested model — events flow to the Sertainty Server and are read through Tech Hub's Server Manager under Vault Events, with access controlled by the Server. Events can optionally be stored inside the Vault itself; in that case they are encrypted along with the Vault contents, and reading them requires a valid Sertainty license, an application or process built to read events (not every Vault-opening app includes this), and a User with the ReadEvents privilege. Other destinations (a file, a remote URL, an email address, an FTP endpoint) have their own access controls and are only as protected as you make them (for example, by writing them into another Vault that the receiving system can open). Use blockchain when the audit needs to be visible to the whole network. Use Sertainty when the audit needs to flow to a controlled destination with authorized readers.

Which means:

• You need a public, tamper-evident sequence of operations → blockchain.
• You need confidential data that authenticates its recipient before opening → UXP.
• You need both → combine them. They solve different problems and work fine side by side, with no overlap or conflict. A protected transaction log might use blockchain for a public multi-party record of what happened across all parties, Sertainty for confidentiality of each entry's payload, and Sertainty's own Vault event records for the per-record access audit that travels with the file.

UXP Technology protects the entire Vault as a unit, not selected fields within it.

Data Loss Prevention (DLP) and tokenization tools typically scan content for specific patterns (Social Security numbers, credit card numbers, named-entity strings) and tokenize or mask just those fields. The rest of the document stays in cleartext. This approach has two structural risks:

• Detection accuracy. The heuristics that identify "sensitive" fields are not perfect. False negatives leave real sensitive data exposed; false positives over-tokenize and break downstream consumers.
• The non-tokenized remainder is still accessible. Anything the detector missed (context, surrounding metadata, document structure, attachments) sits in cleartext alongside the tokenized fields.

UXP takes the all-or-nothing approach: the entire content of the Vault is encrypted, every byte. There are no "low-risk" sections to leak, no heuristics to tune, and no false negatives possible. Once a Vault is created, no part of its content is accessible without satisfying the Identity's authentication and policy rules. See What encryption does UXP Technology use? for how the protection scheme works at the byte level.

If you need both, Vault protection for the file as a whole plus field-level tokenization inside the protected payload, they can coexist: tokenize first, then wrap the tokenized output in a Vault.

Every user definition contains a set of challenge pairs: prompt/response entries private to that user. At authentication time the engine presents a randomized subset of those challenges, with the number of prompts determined by the user's current trust score.

Trust is influenced by device, network, location, and time signals. A fully trusted access might require very few prompts; an untrustworthy access might face three, four, or more. Unacceptable responses are kept secret, which inhibits guessing.

The exchange happens entirely between the Vault and whoever is trying to open it, validating locally against what's stored inside the file; see Can a Vault authenticate users without any network connectivity? for how this works without an external server or the original .iic present. Anyone (person, machine, or process) who can answer the challenges accurately gains access, provided the Vault's other rules (time, location, host, expiration) are also satisfied.

Sertainty encourages using life-history-based challenges rather than random passwords, because they are harder to socially reverse-engineer. For machine users, challenges can be auto-generated and stored as Sertainty Secure Strings so they resist binary data scanners. Usernames are matched case-insensitively, so Alice, alice, and ALICE all resolve to the same User Definition. See the Authentication chapter of the Sertainty Technology Guide.

The trust score is the UXP Engine's runtime estimate of how trustworthy the current authentication attempt is. The engine combines signals about the attempt into a single value, then uses that value to scale how rigorous the challenge sequence will be. A high score (the attempt looks trustworthy) reduces the number of challenge prompts the user has to answer; a low score (the attempt looks suspicious) raises it.

How the score is used. Every User Definition in an Identity contains a pool of challenge pairs (prompt/response entries). At authentication time the engine doesn't present all of them; it draws a randomized subset, and the size of that subset is governed by the current trust score. Higher trust → fewer prompts drawn; lower trust → more prompts drawn. See How is Vault authentication different from username and password? for the surrounding mechanics.

Pool-size recommendation. Sertainty recommends a pool of ten or more challenge pairs per User Definition for meaningful randomization across high-trust and low-trust scenarios. For Identities that enable recovery, the recommended minimum is higher; see What happens if I forget my credentials?. For machine Identities, most challenges are typically marked Required and subset selection is bypassed; see What is a machine ID?.

Where trust score fits in industry terms. Trust scoring is Sertainty's implementation of a pattern that goes by several names across the identity industry:

• Risk-based authentication (RBA). NIST SP 800-63B
• Adaptive authentication. The term most IAM vendors use
• Step-up authentication. The inverse, where increasing risk triggers more factors
• Continuous Adaptive Risk and Trust Assessment (CARTA). Gartner framework
• Trust algorithm inputs. NIST SP 800-207 Zero Trust Architecture

All of these point at the same idea: combine contextual signals about an access attempt into a runtime score, then use that score to scale the authentication challenge. Sertainty's implementation is consistent with this pattern. What's distinctive is the mechanism the score drives: scaling the subset size drawn from the User's pre-defined challenge-pair pool, rather than stacking additional authentication factors. See Does Sertainty implement Zero Trust principles? for the broader NIST 800-207 alignment.

Relationship to other authentication-time mechanics. Trust score governs how many challenges are drawn; other mechanics govern what happens with the responses:

• Failure thresholds and lock-out rules are independent of the score. They live in the Identity's <Rules> block; see What rules govern challenge responses?.
• Response masking is independent. It transforms a static response into a dynamic one without affecting how many prompts are drawn; see What is response masking?.
• Required vs. randomized challenges intersect with the score. A challenge marked Required is always presented; trust-score-driven selection applies only to the non-Required pool.

The authentication API returns one of a small set of status values that you check after each call:

The typical authentication loop runs while the status is StatusChallenged: read the next prompt, get the user's response, submit it, check status again. Exit the loop when you see StatusAuthorized (success), StatusNotAuthorized (denied), or StatusCanceled (user gave up). Don't loop on StatusNotAuthorized thinking you'll get another chance; once you're denied, you're done for that session.

Two MFA mechanisms are built in today: email-based challenge codes and the Duo authenticator. For email, a response code is delivered to one or more target addresses; if multiple factors are configured, the user must collect all of them. Alternatively, the same code can be sent to multiple recipients so the user only needs one. Duo challenges are approved via the user's own Duo mobile application.

Beyond MFA, the ID system also supports approvals: third-party sign-offs required before an authentication can complete. See the Multi-factor Authentication section of the Sertainty Technology Guide's Core Framework chapter.

Response masking turns a static challenge response into a dynamic one. Instead of entering exactly what was stored, the user enters the stored value combined with time-based elements, for example last year's four-digit year, today's day of the month, or next month's number.

For example, a stored response prefixed with the current four-digit year rotates automatically each January. The stored Vault never changes, but the valid response rotates with the calendar. See Which masking codes are available? for the full code list and worked examples, plus the Response Data Masking section of the Sertainty Technology Guide's Core Framework chapter.

Masking codes are the tokens you use in a user's Masking field to define dynamic response requirements. The full built-in set:

Combine codes with commas. Example: the mask MaskLastYear,MaskUserData,MaskNextMonth with stored response XXXXXX requires the user to enter 2025XXXXXX1 in December 2026 (last year, stored value, next month as a number). Once masking is enabled on a user, every challenge response for that user (except the username itself) must be entered with the applied masking pattern.

When a user defines their challenge pairs, the UXP Engine enforces rules on response values to prevent weak or trivially guessable answers:

• Minimum length. Default is 3 characters, adjustable via the system preference minChallengeLength.
• Cannot contain the prompt. The response can't include the prompt text (case-insensitive). This stops "favorite color: color" style entries.
• No excessive repetition. A single response value can appear as the answer to no more than 20% of the total challenges. If you have 10 challenges, you can't use the same response for more than 2 of them.
• Optional complexity rules. When the preference useComplexChallengeRules is enabled, every response must contain at least one uppercase letter, one lowercase letter, one digit, and one special character.

These rules apply when the ID is being defined or edited; they prevent bad entries from being stored in the first place. At authentication time the engine simply compares the submitted response to the stored value.

The engine's response rules (see What rules govern challenge responses?) only stop mechanically weak answers. A pair also has to be a good fit for the human (or process) who will have to authenticate against it. Pool depth matters too: a thin pool shrinks the randomized subset toward predictability and leaves recovery with too little working depth. Sertainty recommends a minimum of 15 pairs per User for a human Identity before enabling recovery; see What happens if I forget my credentials?.

What makes a strong pair for a human user:

• Answered the same way every time, without having to work out which version of the response was used. If recall is uncertain, the pair is unreliable.
• Stable over time. Avoid anything that drifts, favorite song, film, food, or color. Today's favorite may not be next year's, yet the stored response does not change.
• Private, not public. Avoid anything an outsider can look up or guess: birthday, address, school, pet's name, mother's maiden name, anything on social media. Single-point facts like these are weak as a sole challenge.
• Meaningful only to the user. A shared memory can still work if the response is the user's own private take on it rather than the shared fact.
• Varied across categories. Mix life-history, fact-based, and episodic prompts so an attacker cannot profile the User by guessing one category.

Hardening options. Response masking turns a static response into a dynamic one (last year's four-digit year, today's day of month, etc.), so a captured response is only valid for a brief window; see What is response masking? and Which masking codes are available?. For machine Identities the above does not apply, challenges are typically AutoGen-ed long alphanumeric strings stored as Sertainty Secure Strings; see What is a machine ID?.

Managing the pool so you do not get locked out. Build it gradually, a solid core first, adding reliable prompts over time rather than forcing all 15 at once. Keep responses consistent in form (capitalization, spacing, punctuation). Never write them down: responses are not stored in readable form and cannot be recovered or shown back, so a good pair is one the prompt itself brings to mind.

Recovery tab (fallback for a forgotten response). On a Member's Recovery tab, set the Minimum number of correct responses as a trust threshold and the Maximum number of incorrect responses tolerated at authentication time. If the maximum is zero, the user can never miss a challenge and still authenticate; the maximum is not considered until the minimum is set. See What happens if I forget my credentials?. For step-by-step detail, see Sertainty Tech Hub Guide, What makes a good challenge pair, Sertainty Tech Hub Guide, Managing them so you never forget, and Sertainty Tech Hub Guide, Member Credential settings (Recovery tab).

There is exactly one recovery path, and it has to be set up in advance. During user definition you can declare a recovery policy such as "at least five correct responses and no more than one incorrect response." If authentication fails but those thresholds are still met, the engine will allow access to the Vault's contents.

Scope: this applies to human Identities. Recovery does not practically apply to machine or process Identities; see What is a machine ID? for why (all-Required challenges leave no partial-credit path). The remainder of this entry assumes a human Identity.

Updating credentials or rules after a successful recovery. User Definitions and rules cannot be edited directly inside a Vault. The owner updates the source Identity and then applies it to the Vault so the embedded Identity details are refreshed.

The functional-reference path uses the underlying Application Development Kit API directly:

1. Update the source ID Definition XML that produced the Identity.
2. Recompile the updated ID Definition into a new .iic (via id::newIdFromDocument() in UXL or uxp::idManager::publishToFile() in C++).
3. Apply the updated Identity to the existing Vault so the embedded Identity details reflect the new configuration.

This is not the only way. Sertainty applications (Sertainty Tech Hub, for example) provide a managed interface that lets the owner create, edit, and re-apply Identities without writing or recompiling the XML directly. Same underlying mechanics, surfaced through a GUI.

The canonical source of authentication and policy is always the Identity. The Vault carries the embedded Identity details as a snapshot from its creation; to change what the snapshot says, update the source Identity and re-apply.

Recovery does not recover a password. There is no reset link or back channel. If the policy is not met, the Vault cannot be opened. See the UXP Access Recovery section of the Sertainty Technology Guide's Core Framework chapter. For the Tech Hub-specific recovery flow (Member Credential settings → Recovery tab), see the Sertainty Tech Hub Guide, Member Credential settings.

Authentication ("you are who you claim to be") is only one gate. Once a user authenticates, the Vault can additionally evaluate policies that gate authorization based on context independent of identity. Policy categories shipped with the engine:

• Activity Count policies. How many successes or failures have occurred
• Network policies. What network the request came from
• Geo-fencing policies. What physical location the request came from

Policies can be combined, for example "this user, on the corporate network, from the approved office location, up to five failed attempts before lockout." If any policy fails, the engine triggers the configured mitigation (deny, MFA escalation, Alternate Reality, shred, self-destruct).

Yes. A Network policy is initialized with an IP address and netmask. The UXP Engine evaluates the connection's source network at authentication time and denies access if it falls outside the allowed range. Files can travel anywhere (a Vault on a laptop that walked off the corporate LAN is still a Vault) but they only open when the request originates from an authorized network. Combine with geo fencing for layered restrictions.

A geo fence policy is initialized with a center point (a street address or a latitude/longitude pair) plus a radius. At authentication time, the engine compares the requesting host's resolved location to the fence and denies access outside it.

The most common use is preventing protected data from being opened in jurisdictions where it shouldn't go (sanctioned countries, hostile networks) even if an authorized user's credentials are compromised. Because the policy is evaluated by the data object itself, the same enforcement applies whether the request comes from a corporate workstation, a personal phone, or an attacker's lab.

Compliance is a group of Vault-lifetime controls. The initial values are Identity-controlled: they are set on the ID Definition's <Compliance> block (under GeneralSetup) and embedded in the Vault at creation. After creation, any User in the embedded Identity who holds the Owner privilege can update the Compliance settings — until they are permanently locked. Three properties:

• Vault Expiration. A date at which the Vault self-destructs its contents on the next open. The Vault is inert until opened — it does not watch the calendar on its own. On any open attempt, the compliance check runs first: if the current date is past the Vault Expiration date, the Vault shreds its internal data, leaving only an empty shell on disk. If the date has not passed, the Vault opens normally. When disabled, the Vault never expires.
• Read-Only Vault. Permanently sets the Vault to read-only. Authenticated users can still open and read the contents, but the Vault contents cannot be modified.
• Compliance Locked. When enabled, the Compliance properties themselves become permanent. Before this lock is set, an Owner can adjust the other Compliance settings; once locked, the current values apply forever.

How to update Compliance settings (Tech Hub → Vault Explorer). First, authenticate and open the Vault as a User who holds the Owner privilege within the embedded Identity. Then choose Data → Compliance from the top menu. The Compliance Properties dialog opens with all three controls above.

How Compliance differs from other date-based mechanisms:

• Identity expiration stops the Identity from authenticating. In principle, a different still-valid Identity could still open the Vault. Vault Expiration triggers the Vault itself to shred its contents, regardless of which Identity is presented.
• Self-destruct rules fire on runtime events (failed authentication, unauthorized location, activity count thresholds). Vault Expiration is date-triggered, but the check runs at open time — the Vault is inert until an application opens it, at which point the compliance check runs first.

Firing the Compliance date on schedule. Because the check only runs when the Vault is opened, a Vault that is never touched will sit past its expiration date indefinitely with its contents intact on disk. To ensure the Compliance date fires on schedule regardless of whether a user opens the file, an application can be written to periodically soft-touch the Vault — activating it just long enough for the compliance check to run. If the date has passed, the touch itself triggers the shred.

When to use:

• Regulatory data retention limits. Data must become permanently inaccessible after N years (records-retention schedules, disposition timelines).
• Contract-bound access. A partner's access to shared material terminates on a specific date.
• Regulated read-only records. Some compliance regimes require preservation without modification. Read-Only Vault plus Compliance Locked freezes the record permanently.

Important:

• Compliance settings are updatable by an Owner — until Compliance Locked is checked, at which point they become permanent.
• Once the Vault is opened after Vault Expiration has passed, the compliance check shreds the internal data. The file's shell remains on disk but is empty of accessible content. Plan accordingly.
• Compliance is a separate mechanism from Identity expiration and from calendar-window / time-based access policies.

Activity Count policies key off counters that the UXP Engine maintains per Vault, most commonly number of successful authentications and number of failed authentications. You can express rules like "lock after N failed attempts," "require MFA after the third successful access," or "self-destruct after the tenth failure." The counters are part of the protected object, so they survive copies and can't be reset by an attacker who doesn't satisfy the existing policy.

A Vault's protection strength depends heavily on how the Identity is configured at creation. Defaults work, but a hardened configuration multiplies the effort an attacker would need to bypass authentication and increases the diagnostic signal available when something goes wrong. The settings below are the minimum recommended baseline for production Identities; relax them only when an explicit operational reason exists.

Challenge pair pool. Use a generous pool per User. A thin pool shrinks the randomized challenge subset toward predictability and (for human Identities) leaves recovery with too little working depth. For the recommended minimum count and rationale, see What happens if I forget my credentials?. Use a mix of question types (life history, fact-based, episodic) so an attacker cannot profile the User by guessing one category.

Required challenges. Mark a subset of challenges as Required so they are always presented regardless of trust score. This prevents a high-trust environment alone from waving authentication through. For human Identities, at least one Required challenge ensures a baseline credential check on every open. For machine Identities the pattern differs; see What is a machine ID?. See also What rules govern challenge responses?.

Response masking. Apply time-based masking codes (current year, day of month, etc.) to one or more challenges so that a captured response from a key-logger or shoulder-surfer is only valid for a brief window. See What is response masking? and Which masking codes are available?.

Failure thresholds. Set a maximum-failures rule so a configurable number of consecutive failures triggers lock-out. Pair this with the recovery policy below so a legitimate locked-out user has a defined path back in.

Recovery policy: defined in advance (human Identities). Declare recovery rules in the User Definition ("at least N correct responses, no more than M incorrect"). Without a recovery policy a forgotten credential means the Vault cannot be opened. See What happens if I forget my credentials?.

Environment restrictions. Use the rule engine to bind authentication to the expected operational context:

• Host fingerprints for machine Identities, so a stolen Vault cannot be opened on a different device.
• Geo fences for human Identities operating from known locations. See How does geo fencing work, and what enforces the location?.
• Network range restrictions for Identities used inside specific corporate or program networks. See Can I restrict Vault access to a specific network?.

For the full rule taxonomy and how the engine evaluates each, see How does a Vault authorize users beyond just authenticating them?.

Expiration dates. Set explicit expiration on Identities that protect time-limited material (project deliverables, contracts, classified material with declassification timelines). Expired Identities refuse authentication; Vaults they created cannot be opened by them after expiration.

Privilege flags: least privilege. Each User Definition carries Files, Messages, SSO, and Imports privileges. Enable only the privileges the User actually needs. A read-only consumer should not have Imports; a SmartMessage receiver should not have Files.

Audit and event configuration. Enable access logging (successful opens, failed authentications, mitigation triggers) and route events to the Sertainty Data Registry, an external SIEM, or both. Without audit configuration, post-incident analysis is sharply limited. See How does the Data Registry track Vault events? and Can Vaults feed access events into a SIEM?.

Strong response values. For human Users, prefer life-history responses over random passwords (harder to socially reverse-engineer). For machine Users, store responses as Sertainty Secure Strings so the values resist binary data scanners. See What are Sertainty Secure Strings?.

Source-code protection of the ID Definition XML. The XML that compiles into the .iic carries the challenge prompts and the responses in clear form. Treat the XML as application source code: keep it in restricted source control, never ship it alongside the data it gates. See What's the difference between a User Definition, an ID Definition, and the .iic Identity file?.

The combined effect of these settings is that protection survives attacks that pierce any single layer: stolen Vault, stolen device, network compromise, social engineering, brute force, lost credentials, and offline cracking each fail against a different one of the configured rules.

UXP sits at the data layer of a defense-in-depth architecture, complementing (not replacing) the controls at adjacent layers:

• Perimeter / network controls (firewalls, IPS, segmentation, ZTNA) gate access to the environment. UXP works inside or outside that perimeter; if a file crosses the boundary in either direction, Vault protection travels with it.
• Identity and access management (IAM, AD, OIDC, MFA platforms) authenticate users at the application layer. Each Vault authenticates against its own embedded Identity at the file layer, providing a second factor of access enforcement specific to each protected file.
• Endpoint protection (EDR, EPP) defends the host machine. UXP protects the data on that host regardless of the host's posture; even if EDR misses an intrusion, the Vault file remains inaccessible without a valid Identity.
• Data Loss Prevention (DLP) detects data leaving the perimeter. UXP makes the leaving event less damaging because the data is already protected at file level. See Does UXP Technology tokenize critical fields, or protect the whole file?.
• SIEM and continuous monitoring observe activity. Vaults feed into the SIEM via the Data Registry, supplying per-file access events.

Do I have to replace existing infrastructure? No. UXP protection is additive: it travels inside the data, with no external dependencies needed for authentication or access control. Existing controls (TLS, identity providers, firewalls, endpoint protection, key management systems, SIEMs) keep doing what they do. UXP does not require a network connection, a key server, an identity provider, or any central administration to authenticate access. Optional integrations (centralized auditing, SIEM feeds, workflow automation) are available through the Server framework as opt-in additions. See Can a Vault authenticate users without any network connectivity? and What are Sertainty Services, and when do I need a Services server?.

How UXP compares to adjacent security categories.

• Encryption at rest (full-disk encryption, transparent-database encryption, cloud-storage encryption) protects data while it sits in a specific storage location. UXP adds a second layer that protects each file individually and travels with the file. If a UXP-protected file leaves the encrypted-at-rest storage, it remains protected; if a non-Vault file in the same storage leaves, only the at-rest layer was protecting it.
• DLP detects sensitive content trying to leave the environment by pattern-matching content as it crosses an egress channel. UXP makes the "left the environment" event materially less harmful: even if DLP misses an exfiltration, the data the attacker grabbed is a protected Vault, not a readable file.
• IRM (Information Rights Management) is the closest adjacent category. IRM systems also enforce per-file access control. The key technical differences: IRM typically depends on a cloud rights-management service for ongoing access decisions, so offline or air-gapped environments are degraded; a Vault authenticates locally without callbacks. IRM systems generally use per-tenant key infrastructure managed by the IRM vendor; UXP has no key escrow with Sertainty. See What happens to my UXP-protected data if Sertainty becomes unavailable as a vendor?.

When to add UXP. The typical pattern for an organization with several of these tools:

1. Keep the perimeter, identity, and endpoint controls in place.
2. Add UXP for specific high-sensitivity file categories (regulated data, IP, CUI, contracts, customer PII) where the marginal cost of one more layer is justified.
3. Use UXP's per-file audit feed alongside the existing SIEM rather than replacing it.

UXP is not a replacement for any of the layers above; it adds file-level access control that travels with the data, which is the layer most defense-in-depth architectures cannot enforce once a file leaves its origin environment.

UXP is designed to operate without any dependency on Sertainty as an ongoing service provider:

• No callbacks to Sertainty. Vaults authenticate locally against their embedded Identity. No connection to a Sertainty server is required for opening a Vault. See Can a Vault authenticate users without any network connectivity?.
• No key escrow with Sertainty. Encryption keys live inside each Vault's own metadata. Sertainty does not hold a copy of any customer's keys.
• No license-server dependency for normal operation. The license file is validated locally by the Application Development Kit at process startup; there is no online license-check round-trip.

The practical implications if Sertainty is unavailable as a vendor:

• Existing Vaults remain accessible with the matching Identity and an installed Development Kit library, as long as the license file is valid.
• License renewal becomes a procurement risk. See What happens to Vault files if my license expires? for the consequences of expired licenses (the Development Kit refuses operations).
• New protected data creation requires a current Development Kit and license, same as any vendor Development Kit dependency.

For organizations with long-term data-retention requirements, the practical mitigation is to maintain a valid license file and Development Kit release alongside your retention environment, so that historical Vault archives remain accessible years after creation.

UXP addresses the data-protection technical control layer of these regulatory frameworks. Whether your overall posture meets each framework's full requirements depends on the surrounding administrative, physical, and process controls, but UXP's mechanisms map directly to the key technical requirements:

• GDPR (EU regulation). Article 32's "appropriate technical measures" for personal data are addressed by per-file encryption (FIPS 140-3 validated AES 256), per-file access control, audit trail, and rule-triggered destructive actions (Shred and Destroy) that support Right-to-be-Forgotten obligations. See Can a Vault really self-destruct, and under what conditions?.
• HIPAA (US healthcare). The HIPAA Security Rule's Technical Safeguards (Access Control, Audit Controls, Integrity, Person/Entity Authentication, Transmission Security) all map to UXP's per-file access, embedded audit, and FIPS validated cryptography. Patient health information wrapped in a Vault retains its access controls regardless of where the file resides.
• PCI-DSS (payment card industry). Requirements 3 (protect stored cardholder data) and 4 (encrypt transmission) are addressed by FIPS validated encryption at rest and in flight. Requirement 7 (least-privilege access) is addressed by per-User Definition privileges within the Identity.

Three caveats:

• UXP does not provide policy-management or workflow automation specific to any single regulation. Privacy impact assessments, breach-notification workflows, consent management, and similar process tooling are outside UXP's scope.
• Regulatory frameworks evaluate the entire program. UXP addresses the data-protection technical layer; administrative controls, physical security, personnel training, and so on remain organizational responsibilities.
• Verify with privacy or compliance counsel. The specific mapping of UXP capabilities to each framework's enumerated requirements is best confirmed with counsel for the framework and jurisdiction in question.

UXP is cloud-agnostic by design:

• No cloud-vendor lock-in for the protection itself. A Vault created on one cloud is accessible on any other cloud, on-prem, or on a personal device, as long as the Identity is available and an Application Development Kit library is present. See Can I create a Vault on one operating system and open it on another?.
• No managed-service dependency. UXP does not depend on a specific cloud's IAM, KMS, key-vault, secrets-manager, or HSM. Encryption keys live inside the Vault; Identities live on the file system or in your own Identity directory.
• Hybrid and multi-cloud transfer. A Vault can be moved between environments (AWS to Azure, on-prem to public cloud, cloud to air-gapped enclave) without re-protection. Protection survives the transfer because it travels with the file.
• Cloud storage as transport. S3, Azure Blob, Google Cloud Storage, and similar services serve as transport for Vault files. The cloud storage backend sees only encrypted bytes; whoever holds the storage credentials cannot read the Vault contents without also holding the right Identity. See Does Vault protection still apply if a file leaves my secure environment?.
• Server framework in cloud. The optional Sertainty Services Server runs on any platform that supports the Development Kit (Linux, Windows, macOS), so it can be hosted on cloud VMs, container platforms, or on-prem servers based on the customer's operational preference.

UXP is not a cloud-native service itself. Sertainty does not offer a SaaS endpoint that customers call; the Development Kit is deployed by the customer into their own environment. This is intentional, keeping cloud-vendor dependency out of the protection path.

The integration scope depends on what you are protecting and what your application already does, but the typical first-protected-flow estimates are short:

• Hello-world flow (create Identity, protect a file, open it back): 1–2 days for a developer with the Application Development Kit installed. The sample programs in the Development Kit's examples/c/, examples/cpp/, and examples/uxl/ folders give the exact patterns. See What sample code ships with the Development Kit?.
• First production-quality integration of a single use case: ~1–2 weeks typically. This includes designing the ID Definition XML (challenges, privileges, rules), wiring up your authentication flow, and integrating audit-event handling.
• Full operational integration with Workflow Service, Delegate Service, SIEM, and full ATO posture: 2–6 months depending on scope and the surrounding compliance environment. Most of this work is not on the UXP integration itself; it is on the operational, training, and process layers around it.

What the Development Kit does not require:

• No application rewrite. UXP wraps existing file I/O; you do not need to redesign your data model.
• No external infrastructure. The Core UXP framework is self-contained and does not require a server.
• No PKI or key-management buildout. Keys live inside each Vault.

What you do need to plan for:

• The ID Definition XML is source code for your access policy. It needs source-control treatment, code review, and change management. See What is an ID Definition (ID Def)?.
• License management. A valid sertainty.lic is required at runtime; renewal cycles need procurement coordination. See What happens to Vault files if my license expires?.
• Operational testing. Authentication flow under failure conditions (lost device, wrong location, expired schedule) is worth exercising before going to production.

Install location. On a standard install the Developer Kit lives at:

• macOS / Linux: ~/Sertainty/Developer/
• Windows: C:\Users\<username>\Sertainty\Developer\

The Developer Kit is coder-only: C and C++ APIs, headers, libraries, sample code, and the SertaintyScript UXL command-line utility (which also ships with the Server kit). Server-side tooling (HTTP server, Workflow Service, and the Services runtime) ships in the separate Server kit; the desktop GUI ships in the separate Tech Hub kit. See What installation kits are available?.

Folders inside the install root.

Executables in bin/.

Sertainty ships as three separate installation kits, each on its own version schedule and targeted at a specific audience:

The three kits are installed independently based on what the deployment needs. For the Tech Hub kit specifically, see the Sertainty Tech Hub section.

Desktop and server platforms: Linux, macOS, and Windows, all 64-bit. Mobile platforms (Android and iOS) are planned, as are Industrial IoT environments.

Architectures by platform (as of V5.0.0):

C and C++ APIs ship with the Application Development Kit. A C# wrapper is supported but distributed separately via the Sertainty GitHub location, not included in Development Kit builds. Node.js wrappers are on the roadmap and will be available in the Sertainty GitHub location. Both the C and C++ APIs hide Qt entirely as an implementation detail: you don't need Qt installed at build time or runtime, since the Qt dependencies ship with the library.

On macOS and Linux, libraries use cdecl calling conventions. On Windows, they use stdcall. Callers must use the correct convention or undefined behavior may result.

A consolidated summary of what's required on the build host, by language:

• All builds need:

  • A 64-bit OS: Linux, Windows, or macOS on Apple Silicon. See Which platforms and programming languages are supported? for the architecture matrix.
  • A valid sertainty.lic placed in the Application Development Kit's home/ folder.
  • The Development Kit's lib/ folder on the runtime loader path:
    • Linux: LD_LIBRARY_PATH
    • macOS: DYLD_LIBRARY_PATH
    • Windows: PATH
    • Or an equivalent RPATH / @rpath / co-located DLL arrangement.

• C builds:

  • A C compiler.
  • The Development Kit's include/ and lib/ folders.
  • No Qt installation at build time or runtime. The C API hides Qt as an implementation detail; the Qt dependencies ship inside the Development Kit library.

• C++ builds:

  • A C++ compiler.
  • The Development Kit's include/ and lib/ folders.
  • No Qt installation at build time or runtime. Like the C API, the C++ API hides Qt as an implementation detail.

• UXL:

  • Ships with the Developer Kit.
  • No host-level compiler needed.
  • UXL scripts run through bin/SertaintyScript.
  • To protect a UXL script for distribution, the script utility wraps it in a Vault. See How do I protect a UXL script for distribution?.

Calling conventions: macOS/Linux use cdecl; Windows uses stdcall. Calling-convention mismatches between an application and the Development Kit libraries produce undefined behavior.

The fastest end-to-end check is the bundled examples runner. From the Application Development Kit's examples/ folder:

• macOS / Linux: ./run_all.sh
• Windows: run_all.bat

This builds and executes the full ID + Vault roundtrip and the SmartMessage roundtrip in every shipped language (c/, cpp/, uxl/). Each flow reports PASS, FAIL, or SKIPPED. A clean install with a valid license produces PASS across the supported languages on the host. SKIPPED typically means the toolchain for that language isn't installed on the build host.

If run_all fails immediately on every flow, the failure is almost always one of three things: license file missing or expired, shared library not on the loader path, or app-identifier mismatch against the license. See What should I check if library initialization fails? for the diagnostic walkthrough.

If you want a smaller smoke test, the single fastest path is the UXL Flow A sample:

Shell

cd ~/Sertainty/Developer/examples/uxl
SertaintyScript -b @flow_a_id_uxp.uxl

A successful run prints the create-and-reopen sequence and reports PASS at the end.

The UXP Engine can write a diagnostic log that records what the runtime did during execution. Two things to distinguish first:

• Engine logs are diagnostic output from the UXP runtime itself: initialization sequence, library loading, script utility execution, Services server operations. Covered in this entry.
• Audit events are access records for individual Vaults (who opened what, when, from where). Configured per Identity through the <Events> rule block and reported to the Data Registry. See How does the Data Registry track Vault events?.

Log file location. When logging is enabled, the UXP Engine writes to:

{Sertainty-install-folder}/log/

A new log file (named with a unique time code) is created at the start of each engine invocation. If the logging level is zero, no log file is created for that application.

How to enable logging. Logging is controlled by system preferences set through the Sertainty API. Two preferences cover the most common cases (both integer, default 0):

• scriptLogging — logging level for SertaintyScript utility operations
• servicesLogging — logging level for the Sertainty Services server

Both use the same six-level scale:

• 0 — disabled (no log file created)
• 1 — fatal errors only
• 2 — severe errors
• 3 — all errors and warnings
• 4 — everything
• 5 — debugging information

Practical guidance. Set to 3 for typical production monitoring; go to 5 only when reproducing a specific bug (levels above 3 can produce large log volumes quickly). Preferences live in INI files under the Sertainty installation folder's init/ directory (sf_<platform>.ini for system preferences, sf_<platform>_<os_user>.ini for user preferences). See the Preferences and Logging sections of the Sertainty Technology Guide's Core Framework chapter.

Where to look when troubleshooting. For any UXP operation that has failed, the message text returned by the API call is the primary signal. The persistent log at the location above gives the fuller sequence of events. Together they let you match "the API said X" against "here's what happened just before that." See Something isn't working — where do I start? for the common failure walkthroughs.

Sertainty designed v5 for seamless upgrade from previous releases. The update is a simple Application Development Kit swap and a license refresh; no application code changes are required.

What stays the same:

• API surface. v5 function calls exactly match previous versions' function calls by design. This was intentional, to prevent major upgrade issues for customers already using the UXP Technology. Applications built against pre-v5 releases continue to compile and run against v5 without code changes.
• File compatibility. Vaults created under previous releases open cleanly under v5 with the matching Identity. No re-protection, no data migration.

What has to change:

• License. v5 introduces a new license format that is not backward compatible with earlier Development Kit versions, and pre-v5 licenses do not work with v5. This is intentional; Sertainty is sunsetting previous Development Kit versions. Obtain a v5 license through your Sertainty contact and place it in ~/Sertainty/Developer/home/ as sertainty.lic. See My license won't load or has expired, how do I fix it?.

For the full list of specific API renames, signature adjustments, and sunsetted capabilities (relevant only to applications using those specific features), see What C and C++ API changes were made in v5? and What changed in v5 that affects existing deployments?.

Changes below are from the V5.0.0 Developer Kit release notes. For the detailed C and C++ API changes (renames, signature changes, removals), see What C and C++ API changes were made in v5?.

• Added FIPS compliant code signing of binaries and installer.
• Enforcing minimum challenge / response counts and lengths.
• License updates; new license required with 5.0.
• macOS only: ARM64 support only; no longer supporting x86_64 (Intel-based Apple devices).
• Removed global Single Sign-On support.
• Removed support for SMS messaging via email.
• Security hardening improvements.
• Sertainty Agent has been removed.
• Upgrade to AES-256 FIPS 140-3 validated crypto algorithm set.
• Upgrade to location and network precision.

Existing Vaults created under V4 remain accessible under v5 with the matching Identity, an installed v5 Application Development Kit, and a valid v5-format license file. No re-protection or migration is required for the data itself; the upgrade work is at the host (license, OS architecture, build environment, application code), not in the protected files.

From the V5.0.0 release notes for the Sertainty Application Development Kit.

C API function renames.

• uxpfile_Truncate was renamed to uxpfile_truncate.
• uxpfile_TruncateVirtualFile was renamed to uxpfile_truncateVirtualFile.
• uxpmsgid_* was renamed to uxpsmartmessage_*.

C API signature changes.

• uxpcf_getCurrentConfig
• uxpfile_authenticate
• uxpid_publishToBuffer
• uxpsys_initLibrary
• uxpsys_releaseLibrary
• uxpsys_sendTestEmail

C API functions removed.

• uxpfile_alterAuthenticationBuffer
• uxpfile_openNewFile2
• uxpid_createIDFromKcl
• uxpid_publishToBuffer2
• uxpsys_compileUXLToBuffer
• uxpsys_decodeAESGCM
• uxpsys_decodeBuffer
• uxpsys_encodeAESGCM
• uxpsys_encodeBuffer
• uxpsys_setLogFile

C API functions added (bug fix).

• uxpmsgid_freeHandle

C++ API class renames.

• uxp::msgId was renamed to uxp::smartMessage.
• uxp::msgIdFile was renamed to uxp::smartMessageFile.

C++ API signature changes.

• uxp::sys::initializeLibrary

Header file consolidation.

• uxlcommon.h has been merged into uxpcommon.h.

Per-kit changelog of what shipped in each release. Each kit ships on its own version schedule.

November 2026 — Three kits launch as separately-packaged products:

The Application Development Kit ships a small, focused set of self-contained examples covering the two core flows in four languages.

On a typical install, the examples live at:

• ~/Sertainty/Developer/examples/

On Windows, the equivalent path is C:\Users\<username>\Sertainty\Developer\examples\. The ~/Sertainty/[Kit]/ user-folder convention is the standard install root on all platforms.

Inside the examples/ folder:

• c/, plain C samples
• cpp/. C++ samples
• uxl/: UXL scripts
• shared/, the shared identity (hello_id.xml) and payload (hello_data.txt) used by every example
• CMakeLists.txt, build.sh / build.bat, run_all.sh / run_all.bat, one-shot build and run scripts that compile and execute all examples

The sample hello_id.xml is fine to experiment with because it gates nothing real; your production XML is source and must be protected accordingly. See What is an ID Definition (ID Def)?.

Inside each language folder there are exactly two files, one per flow:

• flow_a_id_uxp.<ext>. The full ID + Vault roundtrip: create identity from XML, display public ID contents, create a Vault from the new ID, add data, close, reopen, authenticate, extract data, compare to the original.
• flow_b_smartmessage.<ext>. The full SmartMessage roundtrip: create identity, encode a message, close, reopen, decode, verify.

Each example uses hardcoded credentials matching the shared identity, so the flows complete end-to-end without user interaction. Run ./run_all.sh (or run_all.bat on Windows) from the examples/ folder to build and execute all eight flows; each reports PASS, FAIL, or SKIPPED.

For the quickest tour of the full create-and-reopen cycle, start with one of these flows:

• ~/Sertainty/Developer/examples/uxl/flow_a_id_uxp.uxl, the shortest path (UXL script)
• ~/Sertainty/Developer/examples/cpp/flow_a_id_uxp.cpp, the C++ equivalent

An Identity is the file that Vaults authenticate against; it packages a user, their challenge pairs, and the applicable rules into a portable .iic file. In UXL, the simplest path is to describe the ID in an ID Definition XML document and let the script engine materialize the binary form.

What the XML defines

An <ID> element at the top with:

• A name and description of the ID
• Personal information (name, address) for display. (Phone and Photo fields are no longer supported as of v5.)
• A Privileges list (Files, Messages, SSO, Imports)
• One or more <User> elements, each with a username, email, privileges, and a <Challenges> block of prompt/response pairs
• A <Rules> block covering GeneralSetup (failure thresholds, idle timeout), RestrictionsSetup (hardware and location policies), AlertSetup, and EventSetup

Where to find the sample XML

The Development Kit ships a complete, annotated starting point at:

~/Sertainty/Developer/examples/shared/hello_id.xml

A second fixture, hello_data.txt, lives alongside it as the payload that Flow A wraps into a Vault. The full schema for every element you can put in the ID XML (users, challenges, privileges, rules, restrictions) is documented in the UXP ID section of the Core Framework chapter of the Sertainty Technology Guide. The ID Definition XML is source; see What is an ID Definition (ID Def)? for the security posture.

The UXL script

Reading the XML, converting it to an ID, and saving the result takes only a handful of lines. This is essentially the body of the flow_a_id_uxp.uxl sample:

replace procedure makeId()
{
  bytearray xmlBytes, idBytes;
  string xmlSpec = "hello_id.xml";   // Source ID Definition XML
  string idSpec  = "myid.iic";       // Destination .iic file
  // Read the XML definition
  xmlBytes = file::readAll(xmlSpec);
  if (errorstring)
  {
    printf("Error reading ID XML: %1\n", errorstring);
    return;
  }
  // Build the ID
  idBytes = id::newIdFromDocument(xmlBytes, "");
  // Save the .iic file
  file::writeAll(idSpec, idBytes, "replace");
  if (errorstring)
  {
    printf("Error creating Sertainty ID: %1\n", errorstring);
    return;
  }
  printf("ID created successfully.\n");
}
makeId();

Run as SertaintyScript -b @makeId.uxl. The full create-and-reopen roundtrip in UXL (which extends this snippet to authenticate, extract, and verify) is in ~/Sertainty/Developer/examples/uxl/flow_a_id_uxp.uxl.

Same path as the UXL version, using the C API to materialize the binary form. The XML is identical regardless of language; see How do I create a simple Identity using UXL? for what the XML defines and the security posture of the ID Definition XML.

The C program

This is essentially the body of the flow_a_id_uxp.c sample:

#include "uxlbytearray_c.h"
#include "uxpid_c.h"
#include "uxpsys_c.h"

int main(int argc, char *argv[])
{
    uxlByteArray *buffer = uxpba_newHandle();
    uxpCallStatusHandle callstatus = uxpsys_newCallStatusHandle();
    const char *xmlSpec = "$(SAMPLE)/SampleData/hello_id.xml";
    const char *idSpec  = "$(SAMPLE)/temp/sampleid.iic";

    /* 1. Initialize the library (required before any other API call). */
    uxpsys_initLibrary(buffer, argc, argv, "sertainty.lic", "Sertainty", "SampleC", "Sample 2.0.0");
    if (uxpba_getSize(buffer)) return 1;

    /* 2. Read the XML and publish the .iic. */
    uxpsys_fileReadAll(callstatus, xmlSpec, buffer);
    uxpid_publishToFile(callstatus, idSpec, uxpba_getData(buffer), ModifierReplace);

    uxpba_freeHandle(buffer);
    uxpsys_freeCallStatusHandle(callstatus);
    return 0;
}

Two things differ from the UXL version:

• Error handling is explicit. Each active call takes a uxpCallStatusHandle that you check with uxpsys_hasError(), rather than UXL's automatic errorstring.
• Library initialization is required. Call uxpsys_initLibrary() before any other API call; UXL handles this for you.

The full sample (with per-call error reporting and license-init checks) is ~/Sertainty/Developer/examples/c/flow_a_id_uxp.c. If uxpsys_initLibrary() itself fails, see What should I check if library initialization fails? for the common causes and how to diagnose them.

Same path as the UXL version, using the C++ API to materialize the binary form. The XML is identical regardless of language; see How do I create a simple Identity using UXL? for what the XML defines and the security posture of the ID Definition XML.

The C++ program

This is essentially the body of the flow_a_id_uxp.cpp sample:

#include "uxlbytearray.h"
#include "uxpsys.h"
#include "uxpid.h"
#include "uxpidmanager.h"
#include <iostream>

int main(int argc, char *argv[])
{
    uxl::bytearray buffer;
    try
    {
        /* 1. Initialize the library (required before any other API call). */
        uxp::sys::initializeLibrary(argc, argv, "sertainty.lic", "Sertainty");
        uxp::sys::setLogging(uxpLogInfo);

        /* 2. Read the XML and publish the .iic. */
        uxp::sys::fileReadAll("$(SAMPLE)/SampleData/hello_id.xml", buffer);
        uxp::idManager::publishToFile("$(SAMPLE)/temp/sampleid.iic", buffer, ModifierReplace);
    }
    catch (uxl::exception &e)
    {
        std::cout << "Error: " << e.getErrorText() << std::endl;
        return 1;
    }
    return 0;
}

Two things differ from the C version:

• Errors come back as exceptions. A uxl::exception is thrown on any failure (library init, missing license, malformed XML, write error), so a single try/catch covers the whole flow instead of per-call status checks.
• Cleaner namespaces. Calls like uxp::sys::initializeLibrary() and uxp::idManager::publishToFile() replace the C-style uxpsys_* and uxpid_* prefixes.

The full sample (with separate license-failure handling and logging configuration) is ~/Sertainty/Developer/examples/cpp/flow_a_id_uxp.cpp. If your initializeLibrary() call fails before this sample runs, see What should I check if library initialization fails? for the common causes and how to diagnose them.

Library initialization is the first call any C or C++ program makes against the Application Development Kit, and it's where setup problems first surface. Both APIs report failure via a human-readable error message rather than a fixed catalog of numeric codes, so the runtime message text is the authoritative diagnostic.

How init failure is reported:

• C. uxpsys_initLibrary() returns an int: non-zero on success, zero on failure. On failure, the library writes a human-readable message into the uxlByteArray * buffer you passed in. Read it with uxpba_getData():

C

/* 1. Allocate an error buffer the library writes into on failure. */
uxlByteArray *buffer = uxpba_newHandle();

/* 2. Initialize the library. */
uxpsys_initLibrary(buffer, argc, argv,
                   "sertainty.lic",    /* license file path           */
                   "Sertainty",        /* vendor                      */
                   "SampleC",          /* your application name       */
                   "Sample 2.0.0");    /* your application version    */

/* 3. Non-empty error buffer == init failed. */
if (uxpba_getSize(buffer)) {
    fprintf(stderr, "FAIL: initLibrary - %s\n", uxpba_getData(buffer));
    return 1;
}

• C++. uxp::sys::initializeLibrary() throws a uxl::exception on failure. Catch it and call getErrorText() for the message. Wrapping just the init call in its own try / catch lets you distinguish setup errors from operational ones and present a cleaner "check your install and license" message before the rest of the program runs:

C++

try
{
    uxp::sys::initializeLibrary(argc, argv,
                                "sertainty.lic",   // license file path
                                "Sertainty");      // vendor
}
catch (uxl::exception &e)
{
    std::cerr << "FAIL: initializeLibrary - "
              << e.getErrorText() << std::endl;
    return 1;
}

Most common causes:

• License file not found.
  The library looks for sertainty.lic at the path you passed, or in the Development Kit's home/ folder for relative paths.
  Check: the file exists, is readable by the running process, and matches the Development Kit version. V5.0.0 requires a v5-format license; pre-v5 licenses no longer work.
• License file invalid or expired.
  A corrupt or hand-edited .lic produces the same failure as a missing one.
  Fix: replace with a clean copy from your license source.
• Shared library not on the loader path.
  A clean link doesn't guarantee runtime resolution. Per platform:
   macOS: libsertaintycore.dylib (or libsertaintyserver.dylib) on DYLD_LIBRARY_PATH, or @rpath set to the Development Kit's lib/.
   Linux: library on LD_LIBRARY_PATH, or RPATH / RUNPATH covers lib/.
   Windows: sertaintycore.dll on PATH, or sitting alongside the executable.
• Wrong application identifier passed to init.
  The application-name and version arguments identify your binary to the license. A typo or mismatch produces a clear "license does not authorize this application" error.
  Fix: match the license's bound identifiers exactly.
• Insufficient permissions.
  sertainty.lic not readable by the process (wrong owner, missing traverse rights on a parent folder) produces a "cannot read license" error.
  Fix: standard chmod / ACL rules apply.

Getting more detail: call uxp::sys::setLogging(uxpLogInfo) (C++) or the C equivalent immediately after init succeeds. Subsequent operations then log resolution paths and decisions to your error stream, which helps when an ambiguous message doesn't pin down the cause on its own.

Yes. The Sertainty API has two strict lifecycle rules that apply to every C and C++ application using the Application Development Kit:

• No API calls before initLibrary has successfully completed. The library must complete its initialization before any other Sertainty API call is made. Calling any Sertainty function before uxpsys_initLibrary() (C) or uxp::sys::initializeLibrary() (C++) is undefined behavior.
• No API calls after releaseLibrary has been called. Once uxpsys_releaseLibrary() (C) or the C++ equivalent has run, the library's internal state is torn down. Subsequent Sertainty API calls are undefined behavior.

The standard application lifecycle therefore looks like:

C

int main(int argc, char *argv[])
{
    /* 1. Initialize the library FIRST. No Sertainty calls before this. */
    uxpsys_initLibrary(buffer, argc, argv,
                       "sertainty.lic",
                       "Sertainty",
                       "MyApp",
                       "MyApp 1.0.0");
    if (uxpba_getSize(buffer)) { /* init failed; do not call further API */ }

    /* 2. Use the API between init and release. */
    /* ... open Vaults, create Identities, run Workflow tasks, etc. ... */

    /* 3. Release at shutdown. No Sertainty calls after this. */
    uxpsys_releaseLibrary(buffer);
    return 0;
}

If initLibrary itself fails, the library is not in a usable state and no further Sertainty API calls should be attempted. See What should I check if library initialization fails? for diagnostic steps.

Once you have an Identity (.iic from How do I create a simple Identity using UXL?), you can use it to protect one or more files inside a Vault. The Identity is embedded into the Vault at creation, so only the matching .iic (or, for delegate managed access, an authorized user resolved through the Delegate Service) can open it later.

The UXL script

This is essentially the body of the flow_a_id_uxp.uxl sample:

replace procedure uxp_from_id()
{
  int sf;
  string idSpec       = "$(SAMPLE)/temp/sampleid.iic";   // Existing ID
  string uxpSpec      = "$(SAMPLE)/temp/sample.uxp";     // Output Vault file (.uxp)
  string dataPdfSpec  = "$(SAMPLE)/SampleData/data.pdf";
  string dataPdf2Spec = "$(SAMPLE)/SampleData/data2.pdf";

  // 1. Create the new Vault, embedding the Identity.
  sf = sf::newUxp(uxpSpec, idSpec, "IDFile|Replace");
  if (errorstring) { printf("Error: %1\n", errorstring); return; }

  // 2. Add one or more files (virtual files) to the Vault.
  sf::addFile(sf, "data.pdf",  dataPdfSpec,  -1, -1, "Compress");
  sf::addFile(sf, "data2.pdf", dataPdf2Spec, -1, -1, 0);

  // 3. Close the Vault to flush and finalize.
  sf::closeUxp(sf);

  printf("Vault created.\n");
}
uxp_from_id();

Run as SertaintyScript -b @flow_a_id_uxp.uxl. The full sample is ~/Sertainty/Developer/examples/uxl/flow_a_id_uxp.uxl.

Same task as UXL: protect one or more files inside a Vault using an existing .iic Identity. The flow is open new Vault, add files, close.

The C program

This is essentially the body of the flow_a_id_uxp.c sample:

#include "uxpfile_c.h"
#include "uxlbytearray_c.h"
#include "uxpsys_c.h"

int main(int argc, char *argv[])
{
    uxlByteArray *buffer = uxpba_newHandle();
    uxpFileHandle appHandle;
    const char *idSpec       = "$(SAMPLE)/temp/sampleid.iic";
    const char *uxpSpec      = "$(SAMPLE)/temp/sample.uxp";
    const char *dataPdfSpec  = "$(SAMPLE)/SampleData/data.pdf";
    const char *dataPdf2Spec = "$(SAMPLE)/SampleData/data2.pdf";

    /* 1. Initialize the library. */
    uxpsys_initLibrary(buffer, argc, argv, "sertainty.lic", "Sertainty", "SampleC", "Sample 2.0.0");
    if (uxpba_getSize(buffer)) return 1;

    /* 2. Create the new Vault, embedding the Identity. */
    appHandle = uxpfile_newHandle();
    uxpfile_openNewFile(appHandle, uxpSpec, idSpec, IdFile, ModifierReplace, 0);

    /* 3. Add files, then close. */
    uxpfile_addVirtualFromFile(appHandle, "data.pdf", dataPdfSpec, -1, -1, ModifierCompress);
    uxpfile_addVirtualFromFile(appHandle, "data2.pdf", dataPdf2Spec, -1, -1, 0);
    uxpfile_close(appHandle);

    uxpba_freeHandle(buffer);
    uxpfile_freeHandle(appHandle);
    return 0;
}

Two things to note:

• The Vault file is tracked by an opaque handle. uxpfile_newHandle() allocates it; uxpfile_close() flushes and finalizes; uxpfile_freeHandle() releases it. Per-call status is available via uxpfile_errorStatus(appHandle).
• addVirtualFromFile can be called repeatedly to bundle as many files into the Vault as you need before closing. Each becomes an independently addressable "virtual file" inside the container.

The full sample (with per-call error reporting and license-init checks) is ~/Sertainty/Developer/examples/c/flow_a_id_uxp.c.

Same task as UXL and C: protect one or more files inside a Vault using an existing .iic Identity, this time through the C++ API. The flow is open new Vault, add files, close.

The C++ program

This is essentially the body of the flow_a_id_uxp.cpp sample:

#include "uxpfile.h"
#include "uxlbytearray.h"
#include "uxpsys.h"
#include <iostream>

int main(int argc, char *argv[])
{
    const char *idSpec       = "$(SAMPLE)/temp/sampleid.iic";
    const char *uxpSpec      = "$(SAMPLE)/temp/sample.uxp";
    const char *dataPdfSpec  = "$(SAMPLE)/SampleData/data.pdf";
    const char *dataPdf2Spec = "$(SAMPLE)/SampleData/data2.pdf";

    try
    {
        /* 1. Initialize the library. */
        uxp::sys::initializeLibrary(argc, argv, "sertainty.lic", "Sertainty");

        /* 2. Create the new Vault, embedding the Identity. */
        uxp::file data;
        data.openNewFile(uxpSpec, idSpec, IdFile, ModifierReplace, 0);

        /* 3. Add files (the destructor will close the Vault). */
        data.addVirtualFileFromFile("data.pdf",  dataPdfSpec,  -1, -1, 0);
        data.addVirtualFileFromFile("data2.pdf", dataPdf2Spec, -1, -1, 0);
    }
    catch (uxl::exception &e)
    {
        std::cout << "Error: " << e.getErrorText() << std::endl;
        return 1;
    }
    return 0;
}

Two things differ from the C version:

• uxp::file is RAII. The destructor closes the Vault when the object goes out of scope, so there's no explicit close() or freeHandle() call to remember.
• Errors come back as exceptions. A uxl::exception covers init, open, and add, so one try/catch replaces per-call status checks.

The full sample (with explicit license-failure handling) is ~/Sertainty/Developer/examples/cpp/flow_a_id_uxp.cpp.

Once a Vault exists on disk, opening it is a two-step flow: open the file, then run an authentication loop until the engine returns StatusAuthorized or StatusNotAuthorized. The loop is necessary because authentication may take multiple rounds: the engine challenges, you respond, the engine may challenge again.

The example below uses the C++ API. C and UXL implementations of the same flow are supported; see the Sample Code section for the language-specific walkthroughs.

uxp::file data;
data.openFile(uxpFileSpec, ShareAll);

bool done = false;
while (!done)
{
    int status = data.authenticate();
    switch (status)
    {
        case StatusAuthorized:
            done = true;
            break;
        case StatusNotAuthorized:
            return 1;
        case StatusChallenged:
            for (auto &t_ch : data.getChallenges())
            {
                uxp::challenge ch(t_ch);
                ch.setValue(/* user's response for ch.getPrompt() */);
                data.addResponse(ch);
            }
            break;
    }
}
// data is now authorized; you can read virtual files

The status code semantics (Authorized, Challenged, NotAuthorized, Canceled) are covered under What status codes will I see during authentication? in the Authentication section. The full sample, including a getResponse() helper that simulates known credentials, is ~/Sertainty/Developer/examples/cpp/flow_a_id_uxp.cpp.

Both forms produce the same authenticated uxp::file object; the difference is where the bytes come from.

• openFile(path, shareMode). The Application Development Kit manages disk I/O. Use this for normal .uxp files at known paths. The engine reads and writes through the path directly.
• openBuffer(bytearray, shareMode). You supply the Vault's contents as an in-memory uxl::bytearray. Use this when the Vault arrives over the network, came from another protected container, or is being assembled programmatically. After modifying through this handle, call flushBuffer() to materialize changes back into the bytearray.

Authentication, virtual-file access, and SQL queries work identically once the file is open. Pick the form that matches where the Vault lives.

There are two common patterns. The simpler one is exportVirtualFile(), which writes a virtual file directly to a path on disk:

C++

data.exportVirtualFile("data2.pdf", "/tmp/copy2.pdf", ModeRead);

For finer control (streaming into a buffer, processing chunks, or piping to a non-file destination) use the open/read/close trio:

C++

uxp::openVFHandle *handle = data.openVirtualFile("data.pdf", ModeRead);
uxl::bytearray buffer;
while (data.readVirtualFile(handle, buffer))
{
    // process buffer.data() / buffer.size()
}
data.closeVirtualFile(handle);

readVirtualFile() returns false when the file is exhausted. The full sample is ~/Sertainty/Developer/examples/cpp/flow_a_id_uxp.cpp, which uses the streaming form to write a copy to disk and then verify it with compareExternalFile().

After openNewFile() (or openFile() with write share), the uxp::file object exposes a family of addVirtualFile* calls plus per-file management methods:

• From an external file: data.addVirtualFileFromFile("name.pdf", srcPath, -1, -1, modifiers);
• From an in-memory buffer: data.addVirtualFileFromBuffer("name.bin", bytearray, modifiers);
• Empty (then write to it via openVirtualFile): data.createVirtualFile("name.txt", modifiers);

The -1, -1 arguments are start-offset and length; -1 means "all of the source." The modifier flags (ModifierCompress, etc.) follow the same convention as openNewFile().

Per-file management methods include removeVirtualFile(), renameVirtualFile(), getVirtualFileInfo() (size, timestamps, attributes), and setVirtualFileInfo(). Browse the contents with getVirtualFileNames(). The same Vault can hold many virtual files; each is independently readable once authenticated.

Yes. Vaults support a full round-trip edit cycle. Once a recipient authenticates, they can add new virtual files, modify existing ones, remove files, or run SQL updates against contained data. After they close the Vault, the modified .uxp can be sent back to the original sender (or anyone else with a matching Identity), and the changes are visible when the file is reopened.

The mechanics, end to end:

1. Recipient opens the Vault with data.openFile(path, ShareReadWrite) (or ShareAll for full read+write+delete).
2. Recipient authenticates with their Identity. The recipient must have a User definition inside the Vault. See Can multiple users access the same Vault? for how multi-user Vaults are constructed.
3. Recipient modifies content using addVirtualFileFromFile(), addVirtualFileFromBuffer(), renameVirtualFile(), removeVirtualFile(), or SQL queries via uxp::sql::query.
4. Recipient calls data.close() to flush and finalize. The modifications are now persisted in the .uxp on disk.
5. Recipient sends the modified .uxp back via any transport: email, file share, USB, cloud bucket. The protection travels with the file.
6. Original sender opens the modified file with their Identity. The new and modified content is immediately visible.

Two requirements for a clean round-trip:

• Both parties need to be Users in the Vault. A Vault can hold multiple User definitions. For an edit-and-return workflow, the original sender adds both their own User and the recipient's User when creating the Vault. Each side authenticates with their own credentials.
• Per-user privileges control what each side can do. A recipient might be granted read-only access (no modifications), append-only (can add but not delete), or full read/write. Privileges are baked into the Vault at creation time and enforced on every authentication, so an unauthorized "edit" doesn't fail at write time; it fails when the user tries to do something their privileges don't allow.

The same .uxp is binary-portable across operating systems (see Can I create a Vault on one operating system and open it on another? under Core Concepts), so the round-trip works unchanged when the two parties are on different platforms. For broader collaboration patterns (multiple recipients, each getting their own Vault) see How do I send protected files to multiple recipients, each getting different protection? under Workflow Scenarios.

It depends on how the Vault was set up. The rules embedded in the Identity govern who can open it, and any control you didn't bake in at creation time can only be revoked if there's a server in the loop.

Three scenarios, in order of how much control you keep:

• Delegate managed Vault
  The Vault embeds a Delegate Identity pointing at a Sertainty Services server. The server is the authority on who can authenticate.
  To revoke: remove or disable the user on the server. The next time the recipient's UXP Engine contacts the delegate, authentication is refused.
  Caveat: if the delegate has offline caching enabled, a previously authenticated user can keep working from their cached access list until the cache window expires. See How does offline access work with Delegate caching?.
• Identity with expiration baked in at creation
  The ID Definition includes a RulesPreset with an expiration date.
  To "revoke" after the fact: you can't change a .iic after it's been used to create Vaults, the rules travel inside the Vault, embedded at creation. But if you anticipated needing time-limited access and set the expiration up front, the Vault refuses to open past that point with no server required.
• Vault with a Compliance date baked in
  The Vault carries an embedded Vault Expiration date under its Compliance settings.
  To "revoke" or adjust after the fact: a user with Owner privilege can update or turn off the Compliance date via Tech Hub → Vault Explorer → Data → Compliance, unless Compliance Locked has been set (which makes the settings permanent). The Vault is inert until opened; when opened after the Vault Expiration date has passed, the compliance check shreds the internal data — the file's shell remains but is empty of accessible content. See What is a Compliance date, and how does it affect Vault access?.
• Plain Vault with a static embedded Identity, no Delegate, no expiration
  The recipient's Identity is embedded directly in the Vault, with no server in the loop, no Identity expiration, and no Vault Expiration. The recipient holds everything needed to open the Vault.
  To revoke: no mechanism exists. The Vault enforces only its own embedded rules; without a server checkpoint or a baked-in expiration, there's nothing to revoke against. Plan ahead: use a Delegate, set an expiration on the Identity, or set a Compliance date on the Vault.

Practical notes:

• Revocation applies to future authentication attempts. Content the recipient has already authenticated and extracted is plaintext outside the Vault, treat it like any other data you've shared.
• Revocation does not delete the Vault from the recipient's machine. The file stays where it is; it just refuses to open.
• For both "valid for 30 days" semantics and the ability to revoke earlier on demand, combine the two: register the Identity with a Delegate and set an expiration rule. Whichever fires first wins.

See What is the Delegate Service, and when should I use it? for the full Delegate model.

For Vaults that hold gigabytes (database snapshots, VM images, video archives) loading everything into memory isn't viable. The C++ API exposes two tuning levers:

• openVirtualFile(name, ModeRead) returns a handle that backs readVirtualFile(handle, buffer). The buffer is reused across calls; the engine fills it with the next chunk and you process before reading more. This is the streaming form shown under "How do I export/extract files from a protected Vault?" above.
• setPreferences() on the uxp::file object lets you tune the underlying pageSize and cacheSize. Larger pages favor sequential throughput; larger caches favor random-access patterns. Defaults are reasonable for most workloads; reach for these only if profiling shows the I/O layer is the bottleneck.

For writes, addVirtualFileFromBuffer() accepts a uxl::bytearray you've assembled in chunks, and the engine handles segmenting it into pages internally.

Three methods help you move and verify data without round-tripping through external files:

• copyVirtualFile(srcName, destUxpFile, destName). Copies a virtual file from this Vault into another open uxp::file object, preserving content and metadata.
• compareVirtualFiles(name, otherUxpFile, otherName). Byte-compares two virtual files (potentially in different Vaults), returning true if identical.
• compareExternalFile(name, externalPath). Compares a virtual file against a file on disk. Useful as a post-extract integrity check.
• checksumVirtualFile(name). Returns a checksum of the virtual file's contents for later verification or audit logs.

All require the source Vault (and the destination Vault, where applicable) to be authenticated.

Yes. That's what the uxp::id object (an "ID session") is for. Authenticate once against the Identity, then open as many Vaults as you need. The engine treats the open session as already-authorized for any Vault that was created from that Identity, so the per-Vault authentication loop is skipped.

C++

uxp::id idhandle;
idhandle.openSessionFile("$(SAMPLE)/temp/sampleid.iic");

// Authenticate once against the ID (challenge loop omitted here)
while (idhandle.authenticate() != StatusAuthorized) { /* respond */ }

// Now any Vault created from this ID opens without further auth
uxp::file data;
idhandle.openUxp(data, "$(SAMPLE)/temp/sample.uxp", ShareReadOnly);
data.exportVirtualFile("data2.pdf", "/tmp/copy2.pdf", ModeRead);
data.close();

idhandle.closeSession();   // Or let RAII handle it

Session lifetime can be controlled with disableTimeOut() (disable idle-timeout for long-running batch jobs) and validated with isSessionOpen() / validateSession() before reuse. The simple-examples kit demonstrates the simpler "open and authenticate per Vault" pattern in flow_a_id_uxp.{c, cpp, cs, uxl}; the SSO session flow shown above isn't currently demonstrated by a shipped sample, but the API surface is covered in the Sertainty Technology Guide's Single-Sign-On section under Core Framework.

This is the C++-level mechanism behind the SSO feature described in What is Single-Sign-On in Sertainty UXP Technology? under Core Concepts.

The while (status != StatusAuthorized) { switch(status) ... } polling loop is fine for command-line samples, but for GUI applications or services you usually want to register a callback that the engine invokes when challenges arise. Both uxp::id and uxp::file support this:

C++

idhandle.setChallengeCB([](uxp::challenge &ch) {
    // Called by the engine when it needs a response.
    ch.setValue(promptUserFor(ch.getPrompt()));
    return 1;   // 0 = user canceled
});

idhandle.setProgressCB([](int percent, const char *msg) {
    updateProgressBar(percent, msg);
});

With callbacks registered, authenticate() runs to completion in one call instead of needing a manual loop; the engine pumps challenges into your callback as they arise. Available callbacks include setChallengeCB, setProgressCB, and timeout callbacks. The C++ ABI uses std::function so lambdas and bound member functions both work.

The C++ API uses uxl::exception as a single unified exception type for all error conditions: library init failure, missing license, invalid Identity, malformed Vault, authentication failure, I/O error, SQL syntax error. A single try/catch covers the entire flow:

C++

try
{
    uxp::sys::initializeLibrary(argc, argv, "sertainty.lic", "Sertainty");
    uxp::file data;
    data.openFile(uxpFileSpec, ShareAll);
    /* ... authenticate, read, etc. ... */
}
catch (uxl::exception &e)
{
    std::cerr << "UXP error: " << e.getErrorText() << std::endl;
    return 1;
}

A common idiom, visible in most of the C++ samples, is a nested try/catch around initializeLibrary() specifically, separating "no license" from operational errors so you can give the user a clearer "ensure you have a valid installation and license" message before the rest of the program runs.

uxl::exception::getErrorText() returns a human-readable message; for programmatic dispatch, query the underlying status code and use the same dispatch table as for authentication returns.

Methods that return a status (rather than throwing) use one of three return idioms:

• int status codes. E.g. authenticate() returns StatusAuthorized, StatusChallenged, StatusNotAuthorized, or StatusCanceled. These are the values you switch on; their meanings are covered in What status codes will I see during authentication? in the Authentication section.
• bool returns. E.g. compareExternalFile() returns true on a successful match. Failures (file not found, etc.) come back as exceptions, not as false.
• uxp_int64 and other typed returns. E.g. checksumVirtualFile() returns the checksum value; SQL valueInt64() returns the column value.

Whenever a method can signal both "authoritative result" and "operation failed entirely," the result type is reserved for the result and the failure path raises uxl::exception. That's why most code in the C++ samples wraps the whole flow in one outer try/catch and uses status codes only for the explicit branching points (auth state, transaction outcome).

A Vault can act as a SQLite-compatible database, with the tables stored inside the protected container. Open a uxp::sql::query against an authenticated uxp::file, then prepare/execute/iterate:

C++

uxp::sql::query query(&data);

// One-shot DDL/DML
query.exec("create table t1 (c1 string, c2 number)");
query.exec("insert into t1 (c1, c2) values ('Jon', 7)");

// Prepared select with column iteration
query.prepare("select *, rowid from t1 where c1 like ?");
query.bindValue(0, std::string("G%"));
query.exec();

while (query.next())
{
    for (int i = 0; i < query.columnCount(); i++)
    {
        uxl::variant var = query.value(i);
        std::cout << query.columnTable(i) << "." << var.getName()
                  << ": " << var.toString() << std::endl;
    }
}

The flow is the standard SQLite shape: prepare parses the SQL, bindValue substitutes the ? placeholders, exec runs the query, next advances through result rows. The query object is RAII-aware; statement resources are released automatically when it goes out of scope.

For non-SELECT statements, two related methods are useful: executeUpdate() runs an INSERT / UPDATE / DELETE and returns the number of affected rows, and execScript() executes a multi-statement SQL script in one call. After any execution, numRowsChanged() reports how many rows the most recent statement modified, and setUxp() re-binds an existing query to a different open uxp::file.

UXP SQL is not currently demonstrated by a shipped sample in the simple-examples kit; the Data Service chapter of the Sertainty Services Reference Guide covers the API surface in full.

bindValue(index, value) is overloaded for the common scalar types: std::string, integers (16, 32, and 64 bit, signed and unsigned), doubles, uxl::bytearray for blobs, and date/time types via uxl::datetime. bindCount() returns the number of placeholders the prepared statement holds, so generic code can iterate without knowing the SQL upfront.

For results, three retrieval styles co-exist:

• Typed accessors. valueText(col), valueDouble(col), valueBlob(col), plus the full set of integer-width accessors: valueInt16, valueInt32, valueInt64, valueUInt16, valueUInt32, valueUInt64. Best when you know the column's type and want it back as that type directly.
• Generic value(col). Returns a uxl::variant. Best for dynamic / unknown-shape queries; .getName(), .toString(), .toInt64(), etc. extract whichever form you need.
• Column metadata. columnCount(), columnTable(col), columnName(col) let you walk a result set without prior knowledge of its schema (useful for diagnostics, generic exporters, or building a UI grid).

UXP SQL otherwise behaves as SQLite, so the data types are SQLite's: NULL, INTEGER, REAL, TEXT, BLOB. The protection layer is invisible to your queries.

Two equivalent forms exist. The plain-SQL form is simplest:

C++

query.exec("begin transaction");
query.exec("insert into t1 (c1, c2) values ('Pete', 10)");
query.exec("rollback transaction");   // or "commit transaction"

The class-based form uses uxp::sql::transaction, which is RAII-aware: the destructor rolls back if the object goes out of scope without an explicit commit. That makes it safer in code paths with early returns or exceptions:

C++

{
    uxp::sql::transaction txn(&data);
    query.exec("insert into t1 ...");
    query.exec("update t1 set c2 = ...");
    txn.commit();   // omit -> automatic rollback
}

Transactions can be nested; each begin paired with its own commit/rollback operates as a savepoint. The transactional API surface is documented in the Data Service chapter of the Sertainty Services Reference Guide; no shipped sample currently demonstrates UXP SQL transactions in the simple-examples kit.

Delegation is the mechanism that lets an Identity grant temporary, scoped access to other users without exposing the original Identity's credentials. It's what powers the Delegate Service (see What is the Delegate Service, and when should I use it? in the Services section).

The C++ API exposes the consumer side via methods on uxp::id:

• getDelegateNames(). List the delegated IDs available to the current authenticated session.
• getDelegate(name). Retrieve a specific delegate as a usable uxp::id object that can open its own Vaults.
• createTempID(). Build an ephemeral Identity for short-lived access flows.

The producer side (provisioning delegates, configuring the Delegate Service backend in SQLite or MySQL, wiring up subscribers) is not currently demonstrated by a shipped sample in the simple-examples kit. The Delegate Service chapter of the Sertainty Services Reference Guide covers the API surface and the configuration flow in detail.

uxl::bytearray is the workhorse buffer type for the C++ API: ID XML, SmartMessage payloads, virtual-file streams, SQL blob columns, and library-init error messages all flow through it. Treat it like std::string for binary data: it owns its memory, supports append(), clear(), data(), and size(), and is move-friendly.

C++

uxl::bytearray buffer;
buffer.append(srcBytes, length);

const char *raw = buffer.data();
size_t      n   = buffer.size();

// Common round-trips
uxp::sys::fileReadAll("$(SAMPLE)/SampleData/hello_id.xml", buffer);  // load from disk
uxp::sys::fileWriteAll(outPath, buffer, ModifierReplace);            // save to disk
data.addVirtualFileFromBuffer("name.bin", buffer, 0);                // load into Vault

Two notes:

• Initialization to a path string. buffer.assign(pathString) followed by uxp::sys::processStandardMacros(buffer) is the standard pattern for resolving $(SAMPLE)-style macros into absolute paths before passing to non-Sertainty APIs (e.g. fopen).
• uxl::secureByteArray is a hardened sibling for credentials and other secrets: same shape, but the contents are zeroed on destruction and protected against memory inspection. Use it for response strings before they're handed to challenge::setValue().

The simple-examples kit doesn't ship a standalone bytearray sample, but every flow file under examples/cpp/ and examples/c/ exercises this type heavily, see flow_a_id_uxp.cpp for typical patterns: file read/write through uxl::bytearray, in-memory append, conversion to and from API calls.

Every Vault generates an activity log of its interactions — authentications, opens, reads, writes, and compliance events. Where that log is recorded is configured through the Identity's EventSetup rule, with the Server-side Data Registry as the suggested model (it enables near-real-time monitoring; see What's the difference between a Vault's internal events and the server's Vault Events?). This entry describes the in-Vault option — one of several destinations, chosen when the audit record needs to travel with the artifact rather than live on a server, and when no external visibility is desired: no outside system can see activity on the Vault until an authorized party opens it and reads the log. When enabled, the log is embedded in the Vault itself: open the Vault on any machine and the full history is available to authorized readers, no server required.

Each row captures:

• Event Date — when the event fired
• Action — such as New Vault, Open, Update, AddFile, Close, or Read
• Status — success or failure of the action
• Username — the User who triggered the event (where known)
• Message — human-readable detail

Selecting a row exposes the full Event Attributes: the machine configuration at the time (network, operating system, RAM, location, time zone), the full event detail (action, date, status, message, user), and the Vault attributes (application name and version, file name and identifier, protecting Identity, name, and owner).

Reading the internal log requires three things: a valid Sertainty license, an application or process built to read events (not every Vault-opening app includes this capability), and a User with the ReadEvents per-user privilege — see What is an ID Definition (ID Def)? for where that privilege is declared. In Tech Hub the log is surfaced in Vault Explorer under the Events tab, with filter and export-to-file options.

This is different from the server-side event store the Sertainty Server maintains — see What's the difference between a Vault's internal events and the server's Vault Events?. For the Tech Hub view, see Sertainty Tech Hub Guide, Events tab.

Vault signatures are digital signatures applied to a Vault or to specific virtual files inside it, carried inside the Vault itself. They produce a tamper-evident record that a particular User authored or endorsed a given file, available long after the signing session has ended.

• Who can sign. Only Users whose per-user privileges include Sign. See What is an ID Definition (ID Def)? for where privileges are declared on a User Definition.
• Who can read signatures. Only Users whose per-user privileges include ReadSignatures. Signer and reader are separate privileges — a custodian who needs to verify evidence does not need the authority to sign new material.
• Where they live. Signatures travel inside the Vault. In Tech Hub they are visible from Vault Explorer under the Signatures tab, which lists each signature with filter and search.

Typical use cases:

• Non-repudiation on sensitive deliverables, so the signer cannot credibly deny authorship later.
• Chain-of-custody evidence, where a custodian's signature on a file at handoff produces a durable record of who certified its state.
• Legal and regulatory artifacts where the signed artifact must stand on its own, separate from any surrounding system log.

Related: How does Sertainty support chain of custody?, What events does a Vault record internally?. For the Tech Hub view, see Sertainty Tech Hub Guide, Signatures tab.

Sertainty Tech Hub is the umbrella desktop application for creating, managing, and administering Sertainty deployments without writing code. It ships as one of the installation kits (see What installation kits are available?) and runs in two modes:

• Standalone (default). Single-user and small-business use on one machine, with no server required. Covers the full core workflow: create Identities in Identity Studio, define access rules in Policy Studio, create Vaults with the New Vault wizard, work with them in Vault Explorer, browse them in Asset Browser, and send lightweight protected content through SmartMessage.
• With Sertainty Server (add-on for scale). When Tech Hub is paired with Sertainty Server, two additional modules become visible: Server Manager (for shared user administration through delegates, Vault activity registry, and Vault tracking) and Workflow Manager (for automated tasks such as Auto-Protect, Auto-Unprotect, and chain-of-custody workflows). These modules ship with Tech Hub — there is no separate install — and are hidden until Server is available.

When to use Tech Hub:

• Day-to-day business use as a no-code tool for securing and managing data (standalone)
• Training and demonstrations without writing any code (standalone)
• Evaluation before committing to a custom application (standalone)
• Administering a shared or multi-user Sertainty Technology deployment through a GUI instead of the command line (with Server)
• First-time setup of a Workflow deployment (with Server; alternative to editing host.xml / tasks.xml by hand)
• A fast way for developers to learn the technology by using it before building on the Application Development Kit

The component flow. The Tech Hub organizes work in three bands (Foundation → Identity and Policy → Protected Data), with side entries for wizards and shortcuts. In sequence:

• Setup and login — account, login Identity, session
• Policy Studio — add, manage, update policy presets
• Identity Studio — create, manage, share Identities (uses Policy presets)
• New Vault — guided wizard, built on an Identity
• Vault Explorer — protected workspace for an open Vault
• SmartMessage — secure messaging and chat
• Servers and workflow — automate and scale

Side entries:

• New Identity Wizard — wizard that walks through Identity creation and completes into Identity Studio
• Asset Browser — filtered view that surfaces Vault artifacts only and opens one straight into the Explorer

Naming history. Tech Hub is the current name for what has evolved across three releases:

• Sertainty Assistant (earliest) — focused primarily on ID Editor and Rules Editor, the direct predecessors of today's Identity Studio and Policy Studio.
• Sertainty Data Manager — the intermediate rename between Assistant and Tech Hub.
• Sertainty Tech Hub (current) — the umbrella application, standalone by default (Identity Studio, Policy Studio, New Vault, Vault Explorer, SmartMessage, Asset Browser), with Server Manager and Workflow Manager modules that appear when Tech Hub is paired with Sertainty Server.

The first time Tech Hub launches, it has no account yet, so it opens directly into the Application Setup wizard. The wizard handles four things in sequence:

• Create your user account (username, credentials, preferences).
• Set useful application preferences (default library location, appearance).
• Create your Tech Hub login Identity in the background. This is the Sertainty Identity used every time you log in.
• Create your initial Identity Library, seeded with that login Identity.

After setup completes, subsequent launches open the Login screen. Enter your username and answer the challenges from your login Identity. Once authenticated, the Home screen appears with a sidebar of quick start actions (Identity Studio, Policy Studio, New Vault, and others you pin) and the menu bar across the top.

Your Tech Hub account is the local login you create during the Application Setup wizard. Your Sertainty Identity is the thing that actually protects data.

They are not the same object, but setup links them: the wizard creates a login Identity in the background and uses it as the authenticator for your account. When that login Identity is also the Identity you use to protect your Vaults, you get single sign-on into those Vaults for the session. When they are different Identities, the account only gets you into the application; each protected library or Vault then authenticates separately.

See What is an Identity? for the underlying object, and the Account glossary term.

Your password is simply the response to the Password challenge pair on your login Identity. It is never stored in readable form, so there is nothing to reset or email.

• If you set up the Recovery tab in advance and the login Identity has additional challenge pairs, Recovery is the way back.
• If the login Identity only ever had the single default Password pair, there is no recovery path. You can create a new account, but anything protected by the old login Identity stays protected — which, in practice, means permanently inaccessible.

This is the reason to add extra challenge pairs to the login Identity early rather than leaving the default pair in place. For the generic answer, see What happens if I forget my credentials?.

The Tech Hub login is always backed by a Sertainty Identity that setup creates. What that gets you depends on whether the login Identity is also the Identity protecting your data:

• Same Identity — logging into Tech Hub authenticates you for your protected libraries and Vaults as well, for the session. This is single sign-on.
• Different Identities — the login only gets you into the Tech Hub application. You authenticate to each protected library or Vault separately.

See What is Single-Sign-On in Sertainty UXP Technology?.

You have two options, and either lets you keep working with your existing library without recreating it:

• Keep its login separate. Move the library into data/desktop/ and set it as your Preferred Library in Tech Hub Preferences. The library keeps its own authentication, independent of your Tech Hub login.
• Enable single sign-on. Export the Identity that protects the library as an .iic file, place it in the same folder, and create a new Tech Hub account that uses that Identity as its login Identity. From then on your Tech Hub login unlocks the library in the same session.

See How do I upgrade from an earlier release to v5? for the broader upgrade context, and the Identity Library glossary term.

A challenge pair is a prompt and its expected response, used to authenticate a user. You manage them on a Member's Challenge Pairs tab in Identity Studio; for a human user, add them manually with New Prompt. (AutoGen is for machine Identities; it generates long alphanumeric prompt/response strings, not something a person would type.)

Only one challenge pair is required per Identity, but 15 is the recommended minimum. The engine selects challenges at random at authentication time, and 15 is where that random selection has enough depth to work effectively.

See What rules govern challenge responses? and the Member glossary term.

On launch, Tech Hub starts authenticating automatically using the username saved in your Preferences, so the username prompt appears first rather than the full login panel. If you have more than one login, click Cancel on that prompt to dismiss it; the login panel then appears and you can enter a different username.

Policy Studio manages policy presets: reusable sets of policy parameters that can be applied when creating an Identity or a Vault. Presets carry response masking, geo fencing, alert configuration, and other rule-based restrictions authored once and reused across many Identities.

The presets file is policypresets.xml. Two named groupings live inside each preset:

• Identity Profile Policies — policies that apply to the Identity as a whole (host and location restrictions, privileges, alert configuration).
• Member Policies — policies that apply to individual members within an Identity (per-member privileges, credential rules, access windows).

Open Policy Studio from the sidebar or from Actions → Policy Studio. Two presets ship by default: Normal and WorkflowMachine.

For the detailed per-tab reference (Identity Profile Policies, Member Policies, preset creation workflow), see the Policy Studio section of the Sertainty Tech Hub Guide.

The New Identity Wizard is a guided side entry that walks through Identity creation start-to-finish and completes into the Identity Studio workspace. It is the fastest way to create a new Identity without navigating Identity Studio's full interface first.

Open the wizard from Actions → New Identity in the sidebar, or from the New Identity button inside Identity Studio.

The wizard collects the essentials (Identity name, owning library, policy preset, initial member profile, credentials) then hands off to Identity Studio, where the resulting Identity is loaded for further editing or immediate use.

Identity Studio is where Identity Libraries and the Identities inside them are created, edited, and shared. An Identity Library is a container that holds one or more Identities.

Common actions:

• Open an Identity Library — select an existing library file, or use the default library defined in Preferences.
• Create a new library — start fresh with a new library file.
• Create a member profile — define a person, machine, or process that can later become part of an Identity.
• Create an Identity — assemble a new Identity from member profiles and a policy preset. Choose human or machine form depending on how the Identity will authenticate.

Each Identity has:

• Identity Profile settings — the Identity-level settings (owner information, applied policy preset, Identity-level privileges).
• Member Credential settings — per-member credentials, challenge pairs, and per-member policies.

Open Identity Studio from the sidebar (if it is pinned to your quick start actions) or from Actions → Identity Studio.

For deep reference on Member Credential settings, Challenge Pairs, and Identity Profile settings, see the Identity Studio section of the Sertainty Tech Hub Guide.

The Save Identity action in Identity Studio exports an Identity Profile so it can be moved to another location, handed to a colleague, or made available to a server or workflow. To initiate, right-click the Identity Profile in the Element panel and choose Save Identity. The submenu offers four destinations:

• Save Identity to an IIC File — writes a portable .iic Identity file (the typical choice for sharing through a directory or with a colleague).
• Save Identity to Workflow Manager — saves the Identity where workflow tasks can use it.
• Save Identity to Server Manager — saves the Identity to a Sertainty Server under an existing user.
• Save Identity to an XML File — exports as XML.

For an .iic export, the follow-up dialog takes a New file name (or a Browse… path) and optional flags for Read-write Architecture, Compress, and Replace. The resulting .iic is the Identity artifact itself, not a wrapper around credentials, so protect it the same way you'd protect any shared key material: the file name is not checked against the Identity inside it, so adopt a naming convention (for example surname-firstname.iic) before people start exporting, and treat the Identity Content confirmation dialog on import as the real check of which Identity a file holds.

For step-by-step detail, see the Sharing an Identity subsection under Identity Studio in the Sertainty Tech Hub Guide.

A machine Identity is used to automate protect and unprotect operations — servers, laptops, scheduled jobs, and Workflow Manager tasks all authenticate through machine Identities rather than through human challenges. See What is a machine ID? for the broader concept.

In Tech Hub, create one in Identity Studio: right-click the Identity Profiles folder and choose New Machine Identity. The New Machine ID dialog collects a name, the policy preset to apply (for example Workflow, the machine-to-machine preset; use Manage Policy Presets to customize), and the machines included (via Add Current Machine, Add Machine from File, or Clear). Optional flags cover Read-write Architecture, Compress, and Replace. Click OK to create.

For step-by-step detail, see the Creating a machine identity subsection under Identity Studio in the Sertainty Tech Hub Guide.

The New Vault wizard walks through creating a Sertainty-protected Vault in two steps. The Vault is built on an existing Identity, which determines who can open it later.

Step 1, name and configure the Vault. Give the Vault a name and target location, pick the Identity that will govern access, and choose any Vault-level options (Domain, compression, expiration).

Step 2, choose files and folders to protect. Add the files or folder trees to include in the Vault. The wizard creates the Vault with the selected Identity embedded, so the resulting .uxp file is self-protecting and portable.

Start the wizard from New Vault in the sidebar (if pinned) or from Actions → New Vault. After the Vault is created, it can be opened in the Vault Explorer.

The Vault Explorer is the protected workspace that appears after unlocking a Vault. It exposes the virtual files inside the Vault for browsing, extraction, and (where permitted by the Identity) modification.

To open a Vault directly, use Open Vault in the sidebar or Actions → Open Vault. The Open Existing Vault dialog asks for the Vault file path (browse or select from Recent), then walks the authentication conversation with the embedded Identity. Once authenticated, the Explorer opens with the Vault loaded.

The Asset Browser is an alternative entry point: it can open a Vault straight into the Explorer without going through the Open Vault dialog.

A Vault carries a snapshot of the Identity that protected it at the moment it was created, so later changes to that Identity — added or removed members, rotated challenge pairs, a tightened policy, a custodian transfer — do not reach the Vault on their own. To push the updated Identity into an existing Vault, open it in Vault Explorer and choose Data → Update Identity for Vault. In the Update Identity for a Vault dialog, choose the replacement Identity from an Identity File (.iic) or from an Identity Studio Identity, then click Commit. This is an Owner-privileged action.

The update swaps the embedded Identity for the chosen replacement; the Vault's protected contents are unchanged. For deployments that would otherwise require updating many Vaults, a delegate Identity is the lower-maintenance pattern: because its members stay current in the delegate database, each Vault receives the updated details in real time when it next authenticates a member, with no per-Vault commit.

For step-by-step detail, see the Updating a Vault's Identity subsection under Open Vault in the Sertainty Tech Hub Guide.

SmartMessage is a simple mechanism for protecting small pieces of data such as text messages. It uses the same protection technology as a Vault but is scoped to messages rather than files. Once text is encoded, copy it into an email or text message; the recipient uses their Tech Hub to decode.

A valid Identity is required to encode a SmartMessage and to decode one; the sender uses their Identity to protect the message, and the recipient uses theirs to open it.

Open the SmartMessage encoder from Actions → SmartMessage.

Tech Hub includes modules for the deeper administrative surfaces of a Sertainty deployment. These are not part of standalone Tech Hub — they become visible only when Tech Hub is paired with Sertainty Server. The modules ship inside Tech Hub itself; no separate install is needed.

• Server Manager — connects to a local or remote Sertainty Services server. Supports Vault tracking, Delegate management, and Workflow administration from the GUI. Open from Actions → Server Manager.
• Workflow Manager — manages Workflow Service configuration and tasks (Source/Destination Nodes, Auto-Protect, Auto-Unprotect). Open from Actions → Workflow Manager.
• Edit Servers — add and manage saved Sertainty server connections used by Server Manager and other modules. Open from Actions → Edit Servers.

These modules replace what would otherwise require Application Development Kit calls or manual configuration file editing. For the underlying concepts (Services architecture, Workflow patterns), see the Services and Server setup and Workflow Scenarios sections.

For deep reference on Server Manager and Workflow Manager (including Configurations, Address Configuration, and Advanced Filters), see the Server & Workflow Management section of the Sertainty Tech Hub Guide.

A Workflow Configuration is a named collection of tasks that protect and unprotect data under one shared machine Identity. In Workflow Manager, each connected System (the host the server is running on) expands into a Configurations folder and a Scripts and Identities folder; every configuration listed under Configurations has its own Tasks folder plus a private Scripts and Identities folder for configuration-local assets, alongside anything shared at the system level.

Only one configuration is Active at a time (shown with status Active; the rest are Idle). Right-click Configurations to New Configuration, run the Configuration Wizard, or Import Configuration from an XML file. The wizard is the guided path: it names the configuration, optionally creates a machine Identity bound to the local machine (the reliable way to produce a valid Workflow-preset Identity), and walks a per-task sub-wizard for each task (operation, source and destination folders, file-type filters, Identity, delete-source and create-folders flags). Right-click an existing configuration for Activate Configuration, Export Configuration, Edit Configuration XML, Rename, Duplicate, Delete, or Reset Statistics.

A default installation can be seeded with Create Examples, which populates Default, OfficeExample (watches a folder and auto-protects or auto-unprotects office documents), and ServerExample (a multiple-server pattern). For end-to-end Workflow deployment patterns, see the Workflow Scenarios section. For step-by-step detail, see the Configurations material under Server & Workflow Management in the Sertainty Tech Hub Guide.

In Tech Hub, a Configuration controls where protected data can be accessed by combining a hardware fingerprint, a location, and a network into a single identifier. A Configurations tab appears on an Identity and on a Member in Identity Studio, and on a preset's Identity Profile Policies and Member Policies in Policy Studio; it works the same way in every place.

The Sertainty Address Configuration dialog is where that combination is viewed, edited, or entered by hand. It opens from a Configurations tab when you choose Current Configuration (to capture the local hardware, location, and network as a new configuration) or click View on an existing entry. Under Identification, each of Configuration, Hardware, Location, and Network has a name and a unique identifier — the identifiers together form the configuration's fingerprint. A red asterisk beside an identifier means an exact match will be overridden by the advanced filter search. The Properties table lists the detected device and location attributes. Additional controls:

• Hardware File Paths — valid folder locations on this hardware where a Vault may reside; a wildcard * matches any folder.
• Get Current — populate from the current hardware and network.
• Generate Identifiers — hash the property tables into a fresh identifier for each element type.
• Advanced Filters — open the Advanced Configuration Filters dialog (see below).
• Export — write the current configuration to a Sertainty Configuration file.
• Active — whether this address may be used during authentication.

Click OK to save. For step-by-step detail, see the Sertainty Address Configuration dialog under Configurations in the Sertainty Tech Hub Guide.

By default, a Configuration requires an exact match on both location and network. Advanced Configuration Filters relaxes that constraint so a configuration can match a range of values — useful when the acceptable location is a region rather than a point, or when the acceptable network is a block of addresses rather than one. Open it from Advanced Filters on the Sertainty Address Configuration dialog.

The dialog has two groups:

• Location — Valid Latitude, Valid Longitude, and Valid Range (in kilometers) define the allowed area, and Invalid Latitude, Invalid Longitude, and Invalid Range carve out an excluded area within it.
• Network — a Valid IP Address and an Invalid IP Address allow and deny network matches respectively.

When any filter is set, the red asterisk on the matching identifier in the Address Configuration dialog signals that an exact match will be overridden by the filter search. For step-by-step detail, see the Advanced Configuration Filters subsection under Configurations in the Sertainty Tech Hub Guide.

The Asset Browser is a filtered file browser that surfaces only Sertainty artifacts in a folder: Vault files (.uxp), Identity files (.iic), Identity Studio libraries, configuration files, and license files. It provides a focused view of the protected data and credentials in a location without wading through other file types.

Open it from Actions → Asset Browser. Point it at a working directory; results appear grouped by artifact type. From there, common actions include:

• Open a Vault — opens the selected Vault straight into the Vault Explorer (skipping the Open Vault dialog).
• Add to favorites — pin frequently used artifacts for quick access.
• Show details — view artifact-specific information (Identity owner, Vault metadata, etc.).

The Asset Browser is a side entry in the Tech Hub component flow: it doesn't sit in the main sequence, but it is a common shortcut for anyone who works with Sertainty artifacts regularly.

UXL, the UXP Scripting Language, is Sertainty's scripting language, built on a subset of C with Sertainty developed extensions for security, portability, and ease of use. It runs inside the UXL Script Engine, executed by the SertaintyScript command-line utility, which ships with both the Developer Kit and the Server kit.

Reach for UXL when you want to automate Vault work without writing a full C or C++ application: creating Vaults from the command line, adding or exporting files, setting attributes, protecting data, or inspecting Vault status and event history. It's the shortest path from "I have a folder of files" to "I have a protected Vault," and it's also what the Workflow Service executes for automated task pipelines.

SertaintyScript is a command-line tool that exposes the UXL Script Engine. It supports both interactive and batch modes. Things you can do with it:

• Create a new Vault
• Add files to a Vault
• Export protected data from an existing Vault
• View the status of a Vault
• View the event history of a Vault
• Compile UXL source into a protected binary form

Common flags: -b (batch: execute and exit), -c "<UXL command>" (one-liner), -p <uxp-entity> --file <input-file> (wrap an input file into a Vault; pair with -I <id> for the Identity), --p1..--p10 (pass parameters into the engine), -s <pref=value> (set a Sertainty preference), and -l <logfile> (record all output to a file). Run with -h for the complete list.

Two modes, both via the same utility.

Interactive: launch SertaintyScript with no arguments to enter the uxl> prompt. Type expressions line by line and exit with exit. Good for exploring and one-off tasks:

• uxl> int id;
• uxl> id = sf::newUxp("mymusic.uxp", "myid.iic", "IdFile");
• uxl> sf::addFile(id, "song1.m4a", "song1.m4a", 10000, 2);
• uxl> sf::closeUxp(id);
• uxl> exit

Batch: put the same commands in a file (for example, newuxp.uxl) and run the utility with -b plus @filename to execute and exit:

SertaintyScript -b @newuxp.uxl

Batch mode is what you'd invoke from cron jobs, CI pipelines, or the Workflow Service.

Six types, all variable-width and 64-bit where applicable:

• bytearray, variable-length byte array (holds text or binary data)
• int: 64-bit signed integer
• float, double-precision floating point
• string, variable-length character string with no maximum size
• date, standard date and time
• list, variable-length array holding any UXL type or user-defined type

C types not on this list (char, short, unsigned ints, pointers, structs) are unsupported. UXL also auto-converts values between types where it can: assigning a string containing digits to an int variable will parse it; if the conversion isn't possible, the script stops with an error.

UXL starts as a C subset but diverges in a few practical ways:

• Scoping: only two levels (global and procedure). There's no block scope; a variable declared inside an if or for remains visible for the rest of the procedure.
• Untyped arguments: procedure parameters aren't type-fixed. A procedure can accept any type and make decisions at runtime based on what it got. Return values work the same way.
• Rules: UXL adds a RULE construct alongside PROCEDURE. See the next question.
• Type coercion: values auto-convert between types where possible rather than requiring explicit casts.
• Case sensitivity: user identifiers are case-sensitive, but keywords and built-in procedure names are case-insensitive.
• Optimization side-effect: identifiers are converted to internal codes for performance, so runtime error messages can show internal names instead of the variable names you wrote. To get human-readable errors while debugging, compile with the ModifierNoOptimize modifier.

Both are declared with similar syntax, but a rule is a special kind of procedure that takes no formal arguments and can declare inference dependencies on other rules or on data.

The dependency syntax is DEPENDS ON RULE <name> or DEPENDS ON DATA <expression>, with optional ON MATCH, ON NOMATCH, BEFORE INFERENCE, and AFTER INFERENCE blocks. A rule's body doesn't execute until its dependencies are satisfied, and a parent rule can implicitly trigger a dependent rule whose current execution state is NoAction.

Use a regular PROCEDURE for straight-line code you call directly. Use a RULE when you want declarative "this runs if these preconditions are true" logic; the inference engine handles orchestration so you don't have to wire it up manually.

Three options, most to least direct:

Command-line parameters. --p1 through --p10 flags on SertaintyScript. Inside the script they appear as the built-in string variables p1 .. p10:

SertaintyScript -b @process.uxl --p1 "input.txt" --p2 "output.uxp"

Macro substitution at compile time. A $(var-name) token in UXL source is replaced with the value of a compile-time variable. Useful for baking environment-specific values into a compiled script. Macro variables are set via the C++ uxp::sys::compileUXL API.

Conditional compilation. #ifdef, #ifndef, #define, and #undefine on their own lines let you compile different code paths depending on whether a UXL variable name exists. Similar to C's preprocessor but lighter. Must be the first item on the line to be recognized.

Every UXL procedure call populates two built-in variables:

• errorcode, an integer. Zero means success; non-zero identifies the error.
• errorstring, a string. Empty means success; otherwise contains a human-readable error message.

The idiomatic pattern is to check errorstring immediately after any call that might fail and bail out cleanly:

UXL

bytearray data;
data = file::readAll("input.xml");
if (errorstring)
{
  printf("Error reading input: %1\n", errorstring);
  return;
}

Both variables reset on the next call, so always check before making another one. If you need to preserve an error message for logging or return-value purposes, copy it into your own string variable right after the failed call.

errorcode is useful when you want to branch on the specific error (for example, retry on a network failure vs. give up on a file-not-found). The numeric values are listed in the services API reference for server calls and in the Scripting Guide's namespace reference for core operations.

UXL source can be wrapped inside a Vault so it can be distributed without exposing the script source or being modified at runtime. Protected scripts can't be edited without invalidating the Vault wrapper, and any embedded credentials stay sealed inside the Vault.

From the Script Utility, pair -p / --protect <uxp-entity> with -f / --file <script.uxl> to wrap the source:

Shell

SertaintyScript -b --protect myscript.uxp --file myscript.uxl --id myid.iic

The result is a Vault. V5.1 does not document a separate compiled-script extension such as .uxlc or .uxc. To run a protected script, the Workflow Service or SertaintyScript extracts and executes it through the UXP runtime under the embedded Identity's access policy.

Programmatically, the C++ API exposes uxp::sys::compileUXL(...) for embedding a true compile step into a larger build. That call accepts macro-variable definitions, which let you bake environment-specific constants (server URLs, file paths, credentials stored as Secure Strings) into the compiled artifact at build time.

UXL's file:: namespace covers the common file operations you'll need for scripting:

• file::readAll(path), reads an entire file into a bytearray. Good for XML definitions, config files, or any input that fits comfortably in memory.
• file::writeAll(path, data, modifiers), writes a bytearray to a file. The third argument is a modifiers string (the source guide uses the parameter name mods); "replace" overwrites an existing file.
• file::exists(path), returns a truthy value if the path exists.
• file::remove(path), removes a file or folder from disk.
• file::copy(src, dst), copies a file.

All paths support Sertainty's dynamic file specification tokens like $(SAMPLE), $(HOME), and any macro variables defined at compile time, so file::readAll("$(SAMPLE)/SampleData/hello_id.xml") resolves to the right absolute path at runtime without hard-coding the install location.

For binary or streaming operations (reading chunks at a time, seeking within a file), see the extended file:: functions in the Scripting Guide's namespace reference.

UXL supports token substitution in file paths and string values, so scripts don't have to hard-code installation locations. A token has the form $(name) and is replaced at runtime with the value of the named variable.

Common built-in tokens:

• $(HOME), the Sertainty home folder (where RSF files and default config live)
• $(SAMPLE), the root of the Application Development Kit examples folder
• $(INSTALL), the installation root
• $(TEMP), a temporary workspace (often tied to the current session sandbox on server installations)

You can also define your own tokens:

• Compile-time via #define name at the top of a UXL file. #define is a presence flag (no value) used by #ifdef / #ifndef for conditional compilation. To inject values at compile time, use the C++ uxp::sys::compileUXL API, which accepts macro-variable definitions that populate matching $(var-name) tokens.
• Runtime via setting variables before executing the script. For example, the p1 through p10 command-line parameters populate tokens with matching names.

Usage in a script:

UXL

string idPath = "$(SAMPLE)/SampleData/hello_id.xml";
bytearray xml = file::readAll(idPath);

The same path works on any machine regardless of where Sertainty is installed, since $(SAMPLE) is resolved locally.

Sertainty Services is a collection of server-side extensions to UXP Technology: a layer that adds capabilities beyond what a Vault can do on its own. Five services are available; each extension loads on demand, and Core Services is the base layer all others depend on:

• Core Services. Shared metadata, user management, journaling
• Data Service. Server-side Vault and Identity creation, plus a registry for tracking events
• Delegate Service. Remote user-access management for Vaults
• Utility Service. General-purpose helpers for server-side scripting (file, string, XML)
• Workflow Service. Automated file-watching task pipelines

You need a Services server when you want centralized auditing, dynamic user-access management via delegates, automated workflows running without human intervention, or when you're serving Vault operations to clients that don't have the libraries installed locally. For self-contained Vault work (create an object, share it, open it on another machine) no server is needed.

Services support both UXL and Web APIs. Storage is either SQLite (embedded, small installations, no DBA) or MySQL (high volume, requires administration).

The shortest path is the bundled UXL script. From the webserver/ folder in your installation:

Shell

SertaintyScript -b @setupservices.uxl

That initializes the database, creates the admin user, and applies default configuration.

For manual setup, the essential UXL calls are:

UXL

// Initialize the server and its database
sv::initServer(user, credentials, db-type, db-options);
// Open and authenticate an admin session
sv::startServer();
sv::openSession("admin-user");
// Set the 32-character access code used to encrypt service messages
sv::setAccessCode(session, "your-private-code");

Then start the HTTP listener as a standalone process:

Shell

{sertainty-install-folder}/bin/SertaintyHttpServer --port 4000

The --port value above is a deployment preference. The Sertainty-recommended default is 4000; 5050 and 8080 are other common dev / demo choices. Port 80 works for production traffic but requires root or administrator privileges on most platforms. Default db-type is SQLite; pass MYSQL with a db-options table (server, port, schema, user, password) for high-volume installations. Full flow lives in the Server Basics chapter of the Sertainty Services Reference Guide.

The HTTP server (SertaintyHttpServer) hosts the Workflow Service alongside the other Sertainty Services. Bringing up the HTTP server brings up the Workflow Service with it: the API is published over HTTP, and the services engine inside the same runtime executes Workflow Tasks: watching configured folders, running UXL scripts, writing logs.

The complete first-time setup walkthrough, with verification checks, common failure modes, and an end-to-end Auto-Protect example, lives in the Getting Started with Workflow section. For the underlying call signatures of the initialization API, see How do I set up a Sertainty Services server?.

Two notes that apply to any deployment:

• TLS is optional. Vault and delegate communication with the server is protected by Sertainty's own secure message protocol, not by TLS: each request and response carries its own AES-256 GCM envelope (12-byte IV, 16-byte tag, ciphertext, base64-encoded), so messages stay confidential without TLS. SertaintyHttpServer listens on HTTP. If your environment requires HTTPS on the wire, you can front it with an HTTPS-terminating reverse proxy (nginx, Caddy, IIS) as an extra layer of defense in depth.
• Stopping cleanly. Stop SertaintyHttpServer to take both the HTTP API and the Workflow Service offline together. Wrap it in a service manager (systemd, launchd, Windows Service Control Manager) so it restarts cleanly across reboots and so log capture is consistent.

The HTTP server and the Workflow Service run in the same runtime, not as separate processes. SertaintyHttpServer is the network listener for every Sertainty Service; the Workflow Service is one of those Services. The services engine inside that runtime executes UXL Tasks; the operating system runs external-executable Tasks. There is no separate Workflow process to start, stop, or monitor. One process, one lifecycle.

The split of responsibility

• HTTP layer. Owns the network endpoint, the access code encrypted message envelope, and the session sandbox for uploaded files.
• Workflow Service. Owns the workflow/ folder, the running task threads, log output, and the file-watcher state. Hosted in the same process as the HTTP layer.

Where edits flow

When an admin changes a workflow setup from Tech Hub (or any custom client), the request follows this path:

Tech Hub
  -> SertaintyHttpServer
    -> Workflow Service (wf::*)
      -> writes host.xml / tasks.xml on disk
        -> the Workflow Service's file watcher detects the change
          -> affected tasks stop and restart with new definitions

No explicit "reload" step is needed. If host.xml itself changes, all tasks restart; if only one task's definition changes, just that task restarts.

Where files flow

Two distinct filesystem domains exist on the host, and they don't overlap:

• HTTP session sandbox. Where files travel between a remote client and the server. file::upload lands a file into the session's private workspace; file::download pulls one back. The workspace is wiped when the session ends. Admins can configure additional trusted paths the session can read from.
• Workflow folder. workflow/configurations/<Name>/, the watch folders defined in tasks, and the scripts/ folders. The Workflow Service operates here directly. Workflow Tasks read and write here; they do not see the HTTP session workspace.

If you need to push a file into a watch folder via the HTTP API: upload it to a session workspace, then call a Utility Service script that copies it into the watch folder's path (which must be in the trusted paths list). For most production deployments it's simpler to mount the watch folders separately (network share, S3 sync, etc.) and let the Workflow Service's local file watcher pick them up.

Administering Workflow without the HTTP API

A single-machine, single-admin Workflow deployment doesn't need the HTTP server's remote API at all. A host can be activated from two local paths:

• Sertainty Tech Hub (GUI). Via the Workflow Manager module.
• Sertainty Script Utility (CLI). The SertaintyScript command line.

Edit host.xml and tasks.xml directly and let whichever local tool you prefer activate the configuration. The HTTP server only becomes necessary when you want:

• Remote administration from another machine
• Multi-machine coordination
• Programmatic access to workflow state from another host

Task execution model

Each Workflow Task runs as a separate thread within the services engine process. That has two practical consequences: tasks can run concurrently against different watch folders without serial blocking, and a single misbehaving task script can affect log volume but does not crash the surrounding HTTP server. If many tasks misbehave simultaneously, restart the HTTP server to bounce the whole services engine cleanly.

The services architecture uses a secure SQLite database for all administrative data in every configuration. The question is where volatile user data (users, audits, directives) is stored.

Use SQLite-only for small deployments: it's easy to set up, needs no database administrator, and works well for a low number of users. Use MySQL when the user community may grow into thousands or millions: all high-volume elements move into MySQL for performance, while security components remain in the front-end SQLite database. MySQL requires an administrator and the appropriate client library (libmysqlclient on Linux/macOS, libmysql.dll on Windows).

See the Using MySQL to Store Server Data section of the Server Basics chapter of the Sertainty Services Reference Guide.

The access code is a 32-character private string shared between a Services server and its trusted clients. Every request and response over the Web API is encrypted with AES-256 GCM using the access code as the key, a fresh 12-byte IV per message, and a 16-byte authentication tag.

Set it server-side with sv::setAccessCode(session, "<32-char-code>"). Sertainty recommends exactly 32 characters of unpredictable random data for best security. Shorter codes are accepted but weaker. If you change the code, every client that talks to the server must be updated to the new value; there's no gradual rollover.

Roles are bit-encoded integer flags, so a single user can hold any combination. The built-in roles:

• BASIC (1), perform non-privileged operations
• SYSADMIN (2), perform any operation (full admin)
• USERS (4), create other user entries
• SUBUSERS (8), create sub-users
• JOURNAL (16), access and maintain the Services Journal (the server's event / audit record of user activity)

Custom services can define their own private roles, but those must not collide with the built-in bit positions or other service roles.

The Delegate Service lets you manage Vault access dynamically, without rebuilding the Object when the user list changes.

A static Vault bakes authorized users' Identities directly into the Vault. Simple and self-contained, but if the user list changes, you rebuild the Vault.

A delegate-based Vault embeds a Delegate Identity: a placeholder that knows how to reach a Services server. When a user tries to authenticate, the UXP Engine contacts the delegate's home server, which validates the user against its current subscriber list and returns the real Identity if allowed. Add or revoke users on the server and every Vault pointing at that delegate picks up the change immediately.

A hybrid Vault combines both: a few static users (e.g., department heads) plus one or more delegates for a broader rotating user base.

Use a delegate whenever the user list changes often: employee turnover, project rotations, customer access sharing. Use a static Vault when the user list is small, stable, and you want zero runtime dependencies. A Vault can hold zero, one, or many delegates; a typical pattern is one delegate per department or tenant.

The Workflow Service runs automated data workflows. Tasks are triggered either by file-change events (a watched folder gains, loses, or updates a file) or by timed events (the folder's contents are processed on a schedule). Each task can be a UXL script or an external executable, and include/exclude filters using wildcard syntax decide which files participate.

Typical use cases: auto-protect a folder so every file dropped in becomes a Vault; auto-unprotect incoming Vaults using a compiled unprotect script; run a transport or processing pipeline on protected data.

One operational note worth internalizing: editing files directly in a watched folder can cause a deadlock or endless processing loop. The recommended pattern is to copy files in, not edit in place. For how the Workflow Service runs alongside the HTTP server (shared runtime, per-task threading, filesystem domains), see How does the HTTP server host Workflow?.

By default a delegate-based Vault requires a live connection to the delegate service every time the object is opened. For users who need offline access (laptops on flights, field devices without connectivity) the delegate owner can enable local caching.

When caching is on, a successful online resolution stores the user's access list locally with an expiration window set by the delegate owner. Subsequent offline opens authenticate against that cached list until the expiration hits, at which point the user must come back online and resolve again to extend the window.

The delegate owner controls both whether caching is enabled and how long the cache is valid, so a user can't exploit the mechanism indefinitely. Caching is off by default; turn it on explicitly when your users need offline access.

The Data Registry is a sub-component of the Data Service that stores Vault event records centrally, so owners can audit and report on usage.

For events to reach the registry, four things must line up:

• The Vault's owner username must be registered in the Services database
• The ID used to create the Vault must have RecordRemote set to 1
• The ID must have RemoteURL pointing to the services server (or a local database file)
• At least one of LogAccesses, LogFailures, LogMessages, or LogRepeats must be set to 1

These are Rule fields; you can set them via a Rule Preset, by editing the ID Definition XML (which is source; see What is an ID Definition (ID Def)?), or from the Sertainty Tech Hub.

At runtime, when a Vault event fires, the engine sends a record to the registry. If the registry doesn't already have a record for that Vault, it creates one automatically; the event is appended either way. Owners can query events via the services API, but only for Vaults they own.

Yes. A Vault can be configured to log every access attempt (successful or failed) with the location, time, source IP, and reason for failure. Logs can be kept locally or "called home" to a configured endpoint. Because the event records use a standard structured format, they can be ingested by any SIEM that accepts syslog, JSON, or HTTP-pushed events.

This is one of the few remote behaviors a Vault exhibits, and it's opt-in: enable RecordRemote, set RemoteURL, and set the relevant LogAccesses / LogFailures flags in the ID definition. See the previous question for the server-side ingestion path through the Data Registry.

Many service API functions accept a structured filter document that compiles to a SQL WHERE clause. The format is XML with a small set of opcodes:

XML

<Filter>
  <and>
    <eq>
      <column>username</column>
      <string>Grace</string>
    </eq>
    <lt>
      <column>someint</column>
      <number>10</number>
    </lt>
  </and>
</Filter>

Operand types: column, string, number, date (ISO YYYY-MM-DDTHH:mm:ss). Comparison opcodes: eq, neq, lt, leq, gt, geq, like, in. Logical opcodes: and, or. Plus limit for paging (an optional second operand is the starting row).

Column names are case-insensitive. Subqueries aren't supported, and and/or automatically parenthesize their operands so precedence is explicit. The filter above generates (username = 'Grace') and (someint < 10).

The Services API uses two ranges of error codes. Every Web API response carries a <Status> element with the code and a <StatusMessage> with human-readable context.

Session and authentication

• 1, operation successful
• 2, the user must respond to authentication challenges
• 3, access denied
• 214, general error; the accompanying <StatusMessage> describes the specific problem

Database, user, and filter (800s)

• 801, services database is invalid
• 802, no privilege for the attempted operation
• 803, database must be opened read/write
• 804, session is invalid
• 805, specified user not found
• 807, user already exists
• 809, cannot delete self
• 813, invalid journal filter
• 816, data item not found
• 818, invalid event filter
• 819, invalid user filter
• 820, invalid subscriber filter
• 821, invalid service
• 826, invalid UXP filter

Delegate and subscription (800s)

• 806, delegate not found
• 808, delegate already exists
• 810, user is not a subscriber
• 811, user is already a subscriber
• 812, user does not match the user in the Identity
• 814, Identity already exists
• 815, Identity not found
• 817, user must have a valid Identity
• 822, subscription expired
• 823, subscription reached maximum accesses
• 824, no valid delegate IIC available
• 825, subscription access denied

Production callers should switch on <Status> and surface <StatusMessage> in logs; the message often contains specific detail (which field, which user) that the numeric code alone doesn't.

A Server Sandbox is a scoped filesystem workspace on the Sertainty Services server that confines where a service session's file operations can read and write. It prevents a compromised session (or a buggy UXL task) from reaching arbitrary paths on the server host.

Every authenticated services session gets a private sandbox folder where temporary files can be uploaded, generated, and downloaded. Files in a session's private sandbox are automatically deleted when the session ends.

Beyond the session sandbox, the server administrator can configure trusted path entries: specific directories on the server filesystem that selected sessions are allowed to touch. A workflow task that needs to watch a long-lived input folder, for instance, would be granted a trusted path rather than running inside the ephemeral session sandbox.

Any attempt by a web service function to create, read, or write a file outside the session sandbox or a configured trusted path fails with an access error. The relevant API entry points are file::upload and file::download for session-sandbox file operations.

All five services share the same session, user, and database infrastructure, but each has a distinct focus:

• Core Services. The foundation layer. Manages users, roles, sessions, the Services Journal, and the shared database, everything the other services depend on. Always in use whenever any other service is in play.
• Data Service. The Vault-centric layer. Creates and manages Vaults, Identities, and a Data Registry for tracking Vault events. If your server is handling Vault creation or event reporting, you're using the Data Service.
• Delegate Service. Dynamic access management for Vaults. Resolves delegate-based users at runtime against a live subscriber list.
• Utility Service. General server-side helpers for file operations, XML parsing, string handling, and other housekeeping that scripts need. Most Workflow tasks pull from Utility Service functions.
• Workflow Service. Automated file-watching task execution. Runs on top of everything above.

A typical services deployment uses all five: Core for user admin, Data for UXP operations and event logging, Delegate for dynamic user lists, Utility for script helpers, and Workflow for automation. A minimal deployment can use just Core + Data if you're not running automation or delegates. Each service extension is loaded on demand, so an installation that doesn't use Workflow doesn't pay any runtime cost for it.

A sub-user is a user account managed beneath a primary (parent) user on a Sertainty Server, rather than directly under a server administrator. Creating one requires the SUBUSERS role (or an administrator role), which lets a primary user manage their own set of users without being granted server-wide admin.

A sub-user is a full user in its own right. It has its own credentials, its own record folders, and can own its own Delegates, Sub-Users, Subscriptions, and User Identities — the same tree any user has. Its username must match a user inside a Sertainty Identity.

Visibility is controlled by the parent:

• Public — the sub-user can be used by other users on the server.
• Private — the sub-user is visible and usable only to the parent who owns it.

Because the sub-user belongs to its parent, deleting the parent also deletes its sub-users.

Typical use cases:

• Delegated administration — a department lead or project owner provisions and manages the users under their responsibility, without being promoted to server admin.
• Tenant-style separation — an application or team-owner account provisions users on behalf of its own customers, each account's users kept beneath that account.
• Scoped admin responsibility — the parent sees only its own tree, so the blast radius of a mistake is bounded.

For the related delegation concept (where identities, not users, are managed centrally), see What is the Delegate Service, and when should I use it?. For the Tech Hub view, see Sertainty Tech Hub Guide, Sub-users.

Sertainty tracks Vault activity in two distinct places. The Server-side Data Registry is the suggested model; the Vault-internal event log is an option used when the audit record needs to travel with the artifact. They complement each other and answer different questions.

Vault-internal event log (optional). When the Identity's EventSetup rule is configured to record events in-Vault, the log is embedded in the Vault itself. It travels with the artifact — open the Vault on any machine, authorized readers see the full history. No external visibility or monitoring: no outside system can see Vault activity until an authorized party opens the Vault and reads its event log. No network or server required. Reading requires a valid Sertainty license, an application or process built to read events (not every Vault-opening app does), and a User with the ReadEvents per-user privilege. In Tech Hub the log is viewed from Vault Explorer's Events tab. See What events does a Vault record internally?.

Server-level Vault Events (suggested model). Activity the Sertainty Server has recorded for Vaults that are registered with it, through the Data Registry. Enables near-real-time monitoring of Vault activity across the deployment — administrators and SIEM pipelines can see what is happening to each registered Vault as it happens. Queryable from Tech Hub's Server Manager under Vault Events, with search and filter across Vaults and users. Only Vaults whose protecting Identity is configured to report to the server appear here — see How does the Data Registry track Vault events?.

When to use which:

• Operational monitoring and near-real-time activity tracking across many Vaults — use the server-level Vault Events. One place to query current activity, filter by user or date, and spot patterns as they happen.
• SIEM correlation — pair the server-level events with Can Vaults feed access events into a SIEM?.
• Forensic or self-contained audit — use the Vault's internal log. Works offline, resists tampering because it is sealed inside the Vault, and is still available when the Vault leaves your environment.
• When the audit must stay invisible to any external system — use the in-Vault log alone. Preferred for classified material where even the fact of access is sensitive, air-gapped environments with no server, or situations where the Vault's access history must stay inside the authorized community without touching infrastructure the owner does not control.
• Chain of custody — use both; see How does Sertainty support chain of custody?.

For the Tech Hub views, see Sertainty Tech Hub Guide, Events tab and Sertainty Tech Hub Guide, Vault Events.

The Sertainty Server exposes a live view of its own state in the Server Status panel of Tech Hub's Server Manager. It is an at-a-glance operational dashboard rather than a historical metric store.

The panel reports live counts of:

• Sessions — currently active server sessions
• IDs — identities defined on the server
• Users — user accounts
• Delegates — delegate identities
• SubUsers — sub-users beneath other users; see What are sub-users in Sertainty Server, and when would I use them?
• Subscriptions — delegate subscriptions

The same panel exposes Restart Server and Stop Server actions, and surfaces the server-wide preferences (ping interval, authentication timeout, session pool size, stale-session handling, activity auditing, services logging, server URL).

Use it to:

• Confirm the server is running and accepting connections before you troubleshoot elsewhere.
• Verify counts match expectations — a sudden drop in sessions or a jump in subscriptions is a visible operational signal.
• Spot license-scope mismatches — identities, users, and delegates against what the deployment is sized for.

What it is not: a metric history or a SIEM feed. For historical event data and cross-system correlation, pair this view with the server event log and Can Vaults feed access events into a SIEM?.

For the Tech Hub view, see Sertainty Tech Hub Guide, Server Status.

When Sertainty Server interacts with a machine (its own host, or a client that connects to it), it captures a snapshot of that machine's environment as the identification criteria by which the machine is recognized. The snapshot is what access-policy evaluation compares against when a Vault or Identity restricts where it may be opened. In Tech Hub, the same snapshot is what the Sertainty Address Configuration dialog shows; see What is the Sertainty Address Configuration dialog?.

The captured criteria fall into four areas, each with a human-readable name and a numeric identifier (the four identifiers together form the machine's fingerprint):

• Configuration — a summary identifier that composes the other three into a single configuration fingerprint.
• Hardware — machine fingerprint drawn from device and OS detail: architecture, machine host name, serial, model, memory, OS version, and the set of valid Hardware File Paths on this host where a Vault may reside.
• Location — the resolved geographic location (latitude, longitude), optionally relaxed into a region via What are Advanced Configuration Filters?.
• Network — the network environment the machine is reachable on: IP address, hostname, and network environment detail, optionally relaxed into an address block via What are Advanced Configuration Filters?.

When this matters:

• Authoring restrictive access policies. A Vault or Identity can require that the opener's hardware, location, or network matches an authorized profile; the server-captured criteria are what that check runs against. See Can I restrict Vault access to a specific network? and How does geo fencing work, and what enforces the location?.
• Troubleshooting a denied open. If a connected machine looks different than the policy expected (new IP, moved location, swapped hardware), inspecting the captured criteria is the first step; the identifiers show exactly which element changed.
• Seeding a configuration from the current machine. Workflow Manager can View server machine information or Export server machine to a local file, giving you a configuration you can import elsewhere.

For step-by-step detail, see Sertainty Tech Hub Guide, Server machine information and the Configurations section of the Sertainty Tech Hub Guide.

No. Workflow is an automation layer for unattended bulk processing, useful when you want files dropped into a watch folder to be protected (or unprotected) automatically, at scale, without anyone running code. If you're evaluating Sertainty for the first time, or your use case is application-embedded protection (a desktop app, a microservice, a script that wraps files on demand), you do not need Workflow.

When you should set up Workflow:

• You have a steady stream of incoming files that need to be protected as they arrive (backup landings, batch ingest, automated reports).
• You want hands-off protection on a server, with no human in the loop.
• You're consolidating multiple Source/Destination Nodes under a single Workflow platform (e.g. multi-NFS backup, multi-hypervisor environments).

When you can skip the rest of this section:

If you're just trying to understand what Sertainty does or evaluating the technology, jump ahead to:

• Sample Code, copy-pastable first programs in UXL, C, and C++.
• Working with Vaults, how to open, read, query, extract, and stream from existing Vaults.
• Workflow Scenarios, what automation Workflow can do for you, useful for deciding whether to come back to this section later.

You can always set up Workflow later once you've decided it fits your use case.

What the rest of this section covers

A command line, step by step runbook for setting up a working Workflow from scratch on a single host, with no GUI required. The runbook walks through:

1. Initialize the Sertainty Services server.
2. Start the HTTP server (the Workflow Service comes up with it).
3. Create the Workflow folder hierarchy.
4. Create your first Workflow configuration.
5. Run your first protect.
6. Validate the round-trip with Auto-Unprotect.

Each step ends with a verification check so you know whether to move on or stop and fix something. This is the right starting point for Application Development Kit developers, sysadmins automating deployments, and anyone scripting Sertainty into a CI or orchestration pipeline. If you already know the territory and want the condensed version, see What are the steps to set up the HTTP server with Workflow? instead.

A short pre-flight checklist, grouped by category. Verify each item before starting Step 1.

Software installed

• Sertainty Server kit — required.
  • Install root: ~/Sertainty/Server/
  • Contains: bin/, webserver/, and (after first run) the workflow/ folder
  • Provides: SertaintyHttpServer, the Workflow Service, and SertaintyScript
• Sertainty Tech Hub — recommended for creating Workflow configurations.
  • Provides the Workflow Manager GUI
  • Alternative is editing host.xml and tasks.xml by hand; see How do I set up Workflow end to end without Tech Hub?

License

• A valid sertainty.lic file placed where the Application Development Kit can find it. The install root works, as does any path on the system search list. Without a valid license, server initialization fails immediately.

Decisions to make

• Database backend. SQLite is the default and requires no setup. MySQL is needed for high volume deployments and requires an existing MySQL instance, a private schema, a dedicated DB user with full privileges on that schema, and the MySQL client library on the path. See Should I use SQLite or MySQL for the Server framework?.
• Admin username and credentials. You'll create the SYSADMIN account during initialization. Pick a username plus one to three prompt and response pairs (challenge pairs).
• A 32 character access code. Random unpredictable bytes are best. Save it somewhere you'll remember; clients use it to encrypt every request to the server.

Identity

• An Identity (.iic file). If you don't have one yet, follow How do I create a simple Identity using UXL?. The Identity gets embedded in every protected Vault this Workflow produces and gates who can access them.

If any of these are missing, fix them before continuing.

Watch folders and output folders for individual Workflow tasks are configured per task in Tech Hub — you don't need to pre-create them here.

Two commands. That's all it takes to stand up the Workflow server infrastructure on a local machine — but this entry walks through every prompt in between, because a first-time setup has more moving parts than "two commands" implies.

Once the infrastructure is running, use Tech Hub → Workflow Manager to create your first Workflow configuration. Tech Hub creates the Workflow folder hierarchy for you the first time you make a configuration, so there's nothing to pre-create here.

At a glance. Two kits are involved. This entry sets up the first one.

Two things to know:

• Server install location. The Server kit installs at:
  • macOS / Linux: ~/Sertainty/Server/
  • Windows: C:\Users\<username>\Sertainty\Server\
• License placement. Each installed kit needs a sertainty.lic file in its own home/ folder. Your Sertainty license typically covers all kits you're licensed for, so the same license file can be copied into each kit's home/ folder.

Before you start:

• Sertainty Server kit installed, with sertainty.lic in its home/ folder.
• A private access code — the shared secret the server and all clients will use. Any string works; short memorable codes are fine for local setup and demos, but use a strong random string (32 characters of random bytes is a good target) for production. Save it — you'll enter it during setup and every client will need it.
• Database choice: SQLite (default for local; no separate setup) or MySQL (requires an existing MySQL instance).

# macOS / Linux
cd ~/Sertainty/Server/webserver

# Windows
cd %USERPROFILE%\Sertainty\Server\webserver

# macOS / Linux
pwd     # should print ~/Sertainty/Server/webserver
ls      # should show setupservices.uxl and servicesadmin.xml

# Windows (PowerShell or cmd)
cd      # PowerShell: prints current path.  cmd: shows current path.
dir     # should show setupservices.uxl and servicesadmin.xml

# macOS / Linux
../bin/SertaintyScript -b @$HOME/Sertainty/Server/webserver/setupservices.uxl

# Windows
..\bin\SertaintyScript.exe -b @"%USERPROFILE%\Sertainty\Server\webserver\setupservices.uxl"

You are authorized
Setting Server URL
Updating services administrator user identity

Finished initializing DB
Services Administrator user: SYSADMIN

Run SertaintyHttpServer to start the server.

# macOS / Linux
../bin/SertaintyHttpServer --port 4000

# Windows
..\bin\SertaintyHttpServer.exe --port 4000

Sertainty Http Server V5.x.x (Build ###)
Running on http://127.0.0.1:4000/(Press CTRL+C to quit)

curl http://localhost:4000/

# macOS / Linux
cd ~/Sertainty/Server/webserver
../bin/SertaintyHttpServer --port 4000

# Windows
cd %USERPROFILE%\Sertainty\Server\webserver
..\bin\SertaintyHttpServer.exe --port 4000

That's it. Now switch to Tech Hub.

The infrastructure is ready. When you're set up with Sertainty Tech Hub, the flow to create your first configuration looks like this:

• Install the Sertainty Tech Hub kit (separate from Server; needs its own license in its own home/ folder).
• Open Tech Hub and go to Actions → Server Manager.
• Connect to your local Server as SYSADMIN (the initial admin created in Step 1) using the Server URL and access code you set.
• From Server Manager, create additional users — including other admin users — rather than sharing the SYSADMIN credentials.
• Then go to Actions → Workflow Manager, create your first configuration, and add tasks (Auto-Protect, Auto-Unprotect, and beyond).
• Activate the configuration. Tech Hub writes the underlying tasks.xml / host.xml and creates the Workflow folder hierarchy on demand — no hand-editing.
• Before going into production, update the SYSADMIN challenge/responses:
  • In Tech Hub, open Identity Studio and import servicesadmin.xml from ~/Sertainty/Server/webserver/.
  • Make the updates (change challenge prompts and responses, adjust any other Identity Profile settings).
  • Export the Identity Profile to an .iic file.
  • Save the exported .iic into ~/Sertainty/Server/webserver/ (replacing the existing servicesadmin.iic).

If something goes wrong.

Keeping the server up in production.

Step 2 runs in the foreground. For a real deployment, wrap it in a service manager so it restarts on reboot:

• Linux — systemd unit under /etc/systemd/system/
• macOS — launchd plist under ~/Library/LaunchAgents/
• Windows — NSSM or built-in Windows service tooling

For the CLI-only path (no Tech Hub, hand-edit configurations), see How do I set up Workflow end to end without Tech Hub? below.

This is the command-line path — needed only if you're not using Tech Hub. Tech Hub's Workflow Manager module does all of Steps 3-6 for you (creates the folder hierarchy on demand, writes tasks.xml and host.xml correctly, adds tasks through a GUI, activates configurations). If you have Tech Hub installed, do Steps 1-2 to bring up the infrastructure, then open Tech Hub → Actions → Workflow Manager and skip the rest of this entry.

The runbook walks through six steps:

1. Initialize the Sertainty Services server.
2. Start the HTTP server (the Workflow Service comes up with it).
3. Create the Workflow folder hierarchy.
4. Create your first Workflow configuration.
5. Run your first protect.
6. Validate the round-trip with Auto-Unprotect.

Each step ends with a verification check. Work through them in order.

Step 1. Initialize the Sertainty Services server.

Creates the SYSADMIN account, the services database, and registers the access code. Runs once per server install.

Running the bundled setupservices.uxl script is all Step 1 requires. The script drives the full initialization and prompts for the values you decided on in the pre-flight checklist:

Shell

SertaintyScript -b @{sertainty-install-folder}/webserver/setupservices.uxl

Prompts, in order:

• Whether to initialize a new services database (default <No>)
• The database type (SQLITE or MYSQL)
• (MySQL only) host, port, and password for the uxpds user
• The Server URL (type http://127.0.0.1:4000 — the recommended default; the current script may still show port 80 in the prompt)
• The 32 character private access code

Prefer to do this manually? The equivalent UXL-call sequence is documented in How do I set up a Sertainty Services server?.

Verify it worked:

• Console output ends with a success message (no exceptions logged).
• A services.iic file appears in the webserver/ folder.
• SQLite: a database file appears next to it.
• MySQL: the schema you specified now contains Sertainty metadata tables.

If it fails:

• "License not found": sertainty.lic is not where the Application Development Kit is looking. Place it in the install root.
• "MySQL connection refused": verify host/port/credentials with a generic MySQL client first (mysql -h host -P port -u user -p).
• "Permission denied": the user running the script cannot write to the webserver/ folder. Run as an admin or change folder permissions.

Step 2. Start the HTTP server.

The HTTP server (SertaintyHttpServer) is the listener that exposes Sertainty Services over HTTP. Without it, no client can talk to the server remotely.

Run the listener:

Shell

{sertainty-install-folder}/bin/SertaintyHttpServer --port 4000

The --port value above is a deployment preference. The Sertainty-recommended default is 4000; 5050 and 8080 are other common dev / demo choices. Port 80 works for production HTTP traffic but requires root or administrator privileges on most platforms.

For production, wrap this command in a service manager so it stays up across reboots:

• Linux: systemd unit file under /etc/systemd/system/
• macOS: launchd plist under ~/Library/LaunchAgents/
• Windows: NSSM or built-in service tooling

Verify it is listening:

• The console shows a "listening on port N" message and stays running.
• From another terminal, curl http://localhost:4000/ returns something (even an XML error response confirms the listener is alive).

If it fails:

• "Port already in use": another process is on that port. Use a different --port value or stop the other process.
• "Library not found": set the OS dynamic-library search path so it includes the Development Kit's library folder (LD_LIBRARY_PATH on Linux, DYLD_LIBRARY_PATH on macOS, PATH on Windows).
• "Database not found": you skipped Step 1. Run setupservices.uxl first.

Step 3. Create the Workflow folder hierarchy.

On a fresh install, the workflow/ folder hierarchy needs to be created before you can activate a configuration. The shipped example.uxl script creates example configurations alongside the auto-created Default config:

Shell

SertaintyScript -b @{sertainty-install-folder}/webserver/example.uxl

This is a one-time setup step; once workflow/ exists, you don't need to run example.uxl again unless you want to reset to defaults. Host activation can be performed from the Sertainty Tech Hub GUI (Workflow Manager module), the SertaintyScript command line (Sertainty Script Utility), or the HTTP server's remote API.

Verify it materialized:

• The folder {sertainty-install-folder}/workflow/ exists with configurations/ and host.xml inside.
• At least one configuration folder is present (Default/).
• host.xml's <ActiveConfig> reads Default (the auto-created baseline).

If it fails:

• "License not found": sertainty.lic is not in a search location. Step 1's fix applies here too.
• Permission errors: the user running the script can't write to the install root. Re-run with the appropriate permissions.

Step 4. Create your first Workflow configuration.

Use Auto-Protect as the starter scenario; it is the most common first task and the easiest to validate end-to-end. A configuration is a folder plus an XML file; create both directly.

Create the configuration folder. (Note: the names scripts and host.xml are reserved and cannot be used as configuration names.)

Shell

mkdir -p workflow/configurations/MyFirstWorkflow/scripts

Place your Identity (.iic from the pre-flight checklist) into the new scripts/ folder so the Workflow Service can find it:

Shell

cp /path/to/myidentity.iic workflow/configurations/MyFirstWorkflow/scripts/

(Alternatively, place it in workflow/scripts/ to share across all configurations.)

Create tasks.xml with one Auto-Protect task at workflow/configurations/MyFirstWorkflow/tasks.xml. Workflow tasks reference UXL scripts by name; the Workflow Service finds them in the configuration's scripts/ folder or the shared workflow/scripts/ folder:

XML

<?xml version="1.0"?>
<Tasks>
  <Task type="Change">
    <Description>Auto-protect incoming files</Description>
    <Executable type="uxl">protect.uxl</Executable>
    <LogFile>protect.log</LogFile>
    <Folder maxfiles="0">/path/to/your/inbound</Folder>
    <FileScanner>true</FileScanner>
    <Include>*.*</Include>
    <Exclude>*.log,*.tmp</Exclude>
    <Parameter pos="1">files-to-process</Parameter>
    <Parameter pos="2">/path/to/your/output</Parameter>
    <Parameter pos="3">scripts/myidentity.iic</Parameter>
    <Parameter pos="4">false</Parameter>
  </Task>
</Tasks>

Replace /path/to/your/inbound, /path/to/your/output, and myidentity.iic with your actual paths and Identity filename. The Executable type accepts two values: exe (a native binary or shell script) and uxl (a UXL script located in the configuration's scripts/ folder or the shared workflow/scripts/ folder).

Canonical Parameter positions (the full set documented in taskformat.xml):

• pos 1. Files to Process. Reserved and auto-populated by the Workflow Service with the triggering file list.
• pos 2. Destination Folder.
• pos 3. ID for New Vault (for protect tasks) or Unused (for unprotect tasks).
• pos 4. Delete Files (true / false).
• pos 5. Admin ID.
• pos 6. Events Vault.
• pos 7. Archive Vault (or split option).
• pos 8–10. Typically unused.

Activate the configuration by editing workflow/host.xml:

XML

<Host>
  <ActiveConfig>MyFirstWorkflow</ActiveConfig>
  <ApplicationName>MyApp</ApplicationName>
  <ApplicationVersion>1.0</ApplicationVersion>
  <TasksEnabled>true</TasksEnabled>
</Host>

The Workflow Service's file watcher detects the change automatically and restarts tasks against your new configuration.

Verify the configuration:

• The folder workflow/configurations/MyFirstWorkflow/ exists with tasks.xml and scripts/.
• tasks.xml is well-formed (xmllint --noout tasks.xml passes).
• The Identity file is in either the config's scripts/ folder or the shared workflow/scripts/.
• The Workflow Service's log shows "Restarting tasks for configuration MyFirstWorkflow" within a few seconds of host.xml being saved.
• host.xml's <ActiveConfig> reads MyFirstWorkflow.

If it fails:

• "Watch folder does not exist": create the folder before activating. The Workflow Service refuses to start tasks against a missing folder.
• "Identity not found": the .iic file is not in either of the two scripts/ folders. Copy it there.
• "tasks.xml malformed": XML syntax error. Run xmllint --noout (or any XML validator) and fix.
• "Configuration not picking up the change": the file watcher missed it. Restart the HTTP server to bounce the Workflow Service.

Step 5. Run your first protect.

The Workflow Service is watching the inbound folder; dropping a file there should kick off the protect task.

Drop a test file:

Shell

cp /tmp/test.txt /path/to/your/inbound/

Use copy, not edit-in-place; editing files inside a watch folder can cause feedback loops.

Watch the log:

Shell

tail -f workflow/logs/protect.log

Within a few seconds you should see lines indicating the task fired, the file was read, the Identity was applied, and a .uxp was written.

Verify the protect ran:

• The output folder contains a .uxp file (e.g., test.txt.uxp).
• The log shows a "success" line, not an exception.
• Depending on your task config, the original file is either still in the inbound folder or has been deleted.

If nothing happens:

• The file did not match the Include filter, or it matched the Exclude filter. Check the patterns.
• The file's modification time is older than the last task run; the Workflow Service skipped it. touch newfile.txt to update the timestamp.
• The HTTP server is not running, or the active configuration isn't the one you edited. Re-check Steps 2, 3, and 4.
• The task threw an exception. Inspect the log for the actual error and fix the underlying cause (license, permissions, missing identity).

Step 6. Validate the round-trip via Auto-Unprotect.

Creating a .uxp is half the round-trip. The other half is opening it and confirming the data extracts cleanly. The documented path is to add an Auto-Unprotect Workflow task that watches the output folder and unwraps anything that lands there.

The shipped script that generates a deployable auto-unprotect is genau.uxl, which produces a compiled auto-unprotect from unprotect_template.uxl. (For protected split-and-rejoin Workflows, unprotectjoin_template.uxl plays the same role on the destination side.) Build the auto-unprotect for your Identity, then add a second task to tasks.xml:

XML

<Task type="Change">
  <Description>Auto-unprotect outgoing files</Description>
  <Executable type="uxl">example_autounprotect.uxl</Executable>
  <LogFile>unprotect.log</LogFile>
  <Folder maxfiles="0">/path/to/your/output</Folder>
  <FileScanner>true</FileScanner>
  <Include>*.uxp</Include>
  <Parameter pos="1">files-to-process</Parameter>
  <Parameter pos="2">/path/to/your/restored</Parameter>
  <Parameter pos="4">false</Parameter>
</Task>

Drop a .uxp into the output folder and watch workflow/logs/unprotect.log.

Verify the round-trip:

• A restored file appears in /path/to/your/restored/ (e.g., test.txt).
• diff /tmp/test.txt /path/to/your/restored/test.txt shows zero differences.
• The file size and contents match the original byte-for-byte.

If it fails:

• Authentication errors: the embedded auto-unprotect could not authenticate against the Vault's Identity. Re-build the auto-unprotect using genau.uxl with the matching Identity.
• "Vault malformed": the protect run failed mid-write. Re-check Step 5's log for the original error and start over.
• Auto-unprotect not picking up the file: verify the Include filter, the watch folder path, and that the file's modification time is later than the last task run.

For a manual command-line unprotect outside Workflow (interactive challenge response, useful for one-off checks), see the Sample Code entries that show the C / C++ / UXL patterns for opening a Vault and extracting its contents.

Once this works end to end, you have a functional command line Workflow deployment. Everything beyond this is variation: more tasks, more configurations, more sophisticated scripts (compliance.uxl, archive.uxl, protectsplit.uxl, transport.uxl, unprotectjoin_template.uxl, and so on), and remote / multi-machine setups. To administer the same deployment through a GUI from here on, the Workflow Manager module of Sertainty Tech Hub covers the equivalent path.

A scan list of common stumbles. Each entry: symptom → cause → fix.

• setupservices.uxl exits immediately with "License not found" → sertainty.lic is not in a search location → place it in the install root or set the appropriate environment variable.
• SertaintyHttpServer exits with "Port already in use" → another process is on that port → choose a different --port or stop the other process.
• SertaintyHttpServer exits with "library not loaded" or similar → the OS can't find the Sertainty libraries → set LD_LIBRARY_PATH (Linux), DYLD_LIBRARY_PATH (macOS), or PATH (Windows) to include the Application Development Kit's library folder.
• Workflow log says "Watch folder does not exist" → the folder named in <Folder> wasn't created → create it, then restart the HTTP server.
• File dropped into watch folder, nothing happens → Include/Exclude filter mismatch, or file modification time too old → check filters; touch the file to update its timestamp.
• Task references an Identity but fails to run → .iic not in either the config-private or shared scripts/ folder → copy it to one of those folders.
• Edits to tasks.xml don't take effect → the Workflow Service's file watcher missed the change, or the config you edited isn't active → verify host.xml's <ActiveConfig>; if needed, restart the HTTP server to bounce the Workflow Service.
• Workflow appears active but logs are silent → the Task's <FileScanner> is false, so position-1 parameters aren't being supplied → set <FileScanner>true</FileScanner> for tasks that operate on triggering files.

Almost every Sertainty Workflow deployment is described in terms of two roles:

• Source Node. The machine where the data originates and where files get protected before they leave. Typically a workstation, server, or NFS endpoint owned by the data sender.
• Destination Node. The machine that's authorized to receive and access the protected file. Each Destination has its own unique Identity, and protected files can only be opened by the Destination they were prepared for.

The Workflow platform is deployed on both. On the Source, an Auto-Protect task processes a folder and protects any new file as a Vault file using the intended Destination's Identity. Transport (cloud sync, SFTP, email, anything you already use) moves the Vault file to the Destination. On the Destination, an Auto-Unprotect task processes an inbound folder, authenticates each arriving Vault file against the local Identity, extracts the original, and hands it off to whatever process normally consumes the data.

On both sides, the folder a task operates against can be either watched or scheduled. Pick the mode that matches the upstream behavior:

• Watched (change-event). The task fires the moment a new file lands in the folder or an existing file changes. This is the right mode for steady file streams: one file at a time, processed as it arrives.
• Scheduled (timed-event). The task processes the folder's contents on a schedule (for example, every hour or at 02:00 nightly), without watching for individual file events between runs. This is the right mode when an upstream process drops multiple files together and you don't want to start protecting before the whole batch has finished: system backups, nightly processing extracts, batch ETL outputs, end of day report exports.

The same Source and Destination roles apply in either mode; only the trigger differs.

Source and Destination can be different machines (most use cases), or the same machine for internal workflows like backup and restore.

A conventional encrypted file relies on an external key. Whoever holds the key can open the file, so the security of the transport ultimately depends on key management discipline: the key has to travel with the file or through a parallel trusted channel, and any leak compromises the protection. (For the full UXP-vs-encryption contrast, see What is the UXP Technology, and how is it different from conventional encryption?.)

In a Workflow transport, a Vault file behaves differently. The data is protected, as a Vault file, using a specific Destination's Identity. The Identity is embedded in the Vault at creation, and only that Destination can open it. If the file is intercepted in transit, copied to the wrong machine, or accidentally sent to the wrong recipient, it's unusable: there's no key to extract, no password to share, and no path for an unauthorized user to gain access.

This is what lets ordinary file sharing channels (cloud storage, FTP, email) work as transport without becoming the security boundary. The transport doesn't need to be secure because the protection travels with the file. Even if an attacker intercepts the Vault file mid-flight, only the intended Destination can open it.

Yes. Sertainty Workflow doesn't replace your file sharing infrastructure; it protects files before they enter that infrastructure and unprotects them on the other side. The transport in the middle is yours.

In practice this means a file landing in a Source folder triggers Auto-Protect, the Vault file lands in an outbound folder you've configured, and from there your existing system (Box, Dropbox, OneDrive, SFTP, an internal file server, even email attached delivery) carries it to the Destination. The Workflow's Auto-Unprotect then processes an inbound folder on the Destination side, authenticates each arriving Vault file against the local Identity, and grants access.

Both the Source folder and the Destination's inbound folder can be either watched (the task fires on file events) or scheduled (the folder is processed on an interval). See What's a Source Node and a Destination Node in a Sertainty Workflow? for both trigger modes and when to use each.

Because the protection travels with the data, the security posture of your transport doesn't matter the way it normally would. The channel can be plain FTP, an unsecured cloud share, or an internet exposed mailbox, and the data inside the Vault remains accessible only to the intended recipient.

The pattern is one folder per Destination on the Source Node. Each folder has an Auto-Protect task configured with that specific Destination's Identity.

An example setup:

• Manufacturer A's folder: Auto-Protect uses Manufacturer A's Identity. Files dropped here become Vault files accessible only by Manufacturer A's Destination Node.
• Manufacturer B's folder: same idea, with Manufacturer B's Identity embedded in each Vault.
• Manufacturer C's folder: Manufacturer C's Identity embedded in each Vault.

Drop the same source file into all three folders and you produce three different Vault files, each one accessible only to its intended recipient. The pattern scales the same way for customer by customer email attachments, per client geospatial deliveries, or per team document sharing. Whatever the grouping, create one folder and one task per Destination.

Yes, with an email proxy front end. The pattern:

• Vendors send email to a proxy address that you operate, instead of sending directly to their customers.
• The proxy receives the email, identifies the intended customer, and extracts the attachment into that customer's designated folder on the Source Node.
• Auto-Protect runs against each customer folder using that customer's Identity, protecting the attachment as a Vault file.
• The protected Vault file is delivered (via your transport of choice) to the customer's Destination Node.
• Auto-Unprotect at the Destination authenticates against the local Identity and extracts the attachment for the customer to read in clear form.

Two operating constraints worth knowing: the workflow can't be significantly disruptive to the vendor (so the front end stays as ordinary email they're already sending), and email is the entry point (so you can't bypass the proxy). Beyond those, the rest of the pipeline is the standard Source Destination Identity pattern.

Vaults can grow arbitrarily large; they can hold gigabytes of bundled files, video archives, VM images, database snapshots, and so on. Some transport channels (email attachments, ticket system uploads, certain partner FTP gateways) impose maximum file sizes that may be smaller than the Vault you need to move.

Sertainty Workflow includes a paired Split / Join UXL script set that handles this pattern:

• Split (Source). A split UXL script picks up the source Vault and breaks it into a series of pieces. The piece size is a script parameter, so you can match it to whatever your transport allows.
• Join (Destination). A paired join UXL script runs on the receiving end and reassembles the pieces back into the original Vault, byte for byte.

The destination process then picks up the rejoined Vault and authenticates as normal. The Split / Join roundtrip is transport level only, not a protection or authentication step. Protection stays intact end to end because the pieces remain UXP encoded; an attacker who intercepts one or several pieces in transit gets fragments of an encrypted file, not plaintext.

Split and Join are UXL Workflow scripts, so they slot naturally into the Workflow Service's automation model: drop a large Vault into a Source folder on the Source Node, have the Workflow Service run the split script and dispatch the pieces, with the Destination Node's Workflow Service reassembling them on arrival.

For large Vaults, a scheduled trigger on the Source folder is typically the better choice over a watched trigger. A watched trigger fires as soon as a file appears, which on a large or multi-file data drop risks starting protection before the upstream process has finished writing. A scheduled trigger waits for a known interval before processing, so the whole data set is in place before the split script runs. The larger the data, the higher the likelihood that scheduled is the right mode. See What's a Source Node and a Destination Node in a Sertainty Workflow? for both trigger modes.

See What is the Workflow Service and when would I use it? and Can Sertainty Workflow integrate with my existing file sharing system? for the surrounding Workflow context.

Yes. Archive is just another Destination. The same Auto-Protect / Auto-Unprotect pattern handles long term storage with a few configuration differences:

• Designate a single archive-only Destination Node (local or cloud) and generate an Identity for it.
• Auto-Protect uses the archive Destination's Identity to protect files as Vault files.
• The Vault file gets moved to archive storage, not the Destination Node itself, just a storage location you manage (cloud bucket, NAS, cold storage tier).
• When a file is needed again, move it from archive storage back to the Destination Node's inbound folder. Auto-Unprotect runs and either extracts the data, destroys the original, or re-protects it with a new lifecycle for continued holding.

Processed files can live in cold storage indefinitely with the same Identity embedded guarantee: they can only be accessed by the archive Destination, or by an updated Identity if you migrate the archive to a new machine.

For archives that may outlive the people, teams, or roles authorized at the time of archiving, consider using a Delegate Identity instead of a static archive Identity. A Delegate is a proxy identity managed through the Delegate Service: each archived Vault carries the Delegate, and access decisions resolve at retrieval time against the current subscriber list on a Sertainty Services server. This mitigates future access issues (departed personnel, reorganizations, audit policy changes) without having to re-protect the archived Vaults themselves.

One design consideration with the Delegate approach: retrieval may need to be a manual unprotect rather than an Auto-Unprotect task. Delegate authentication has to reach the Services server at retrieval time, and most archive retrieval flows benefit from a deliberate, audited request rather than a folder watcher that fires automatically. Either model is supported; pick the one that fits the surrounding archive process design. See What is the Delegate Service, and when should I use it?.

Yes, and this is one of the cases where Source and Destination collapse into a single machine. The workflow is entirely internal:

• One central admin location runs the Workflow platform and watches every NFS in the backup environment. (NFS, Network File System, is the network attached storage protocol hypervisors use to write VM images to a shared volume.) Each NFS is associated with its hypervisor.
• A backup VM image lands in its NFS's inbound folder.
• Auto-Protect protects it as a Vault file using a single Source/Destination machine Identity.
• The protected Vault file moves to cold storage within the NFS and is held according to your retention policy, possibly for years.
• When a hypervisor needs to be rebuilt, the protected backup is moved to the outbound folder, Auto-Unprotect authenticates against the same Identity, extracts the VM image, and hands it off to your recovery process.

Because Source and Destination are the same environment, you only manage one Identity for the whole backup workflow, and configuration lives in a single centralized place even though the protection covers every NFS in your fleet.

Chain of custody is the unbroken, tamper-evident record of who handled data, when, and in what state, as it moves between custodians. Sertainty supports this pattern when deployed as Sertainty Server + Sertainty Tech Hub, with the Workflow Manager module in Tech Hub used to set up and administer the chain.

Four Sertainty capabilities that support chain of custody:

• Identity-bound access at every open. Each Vault authenticates against its embedded Identity on every open attempt. Only recognized custodians can produce a legitimate access event; unknown users are refused before they reach the data.
• Event recording travels with the artifact. Each Vault records its own auth attempts, opens, and modifications. Events can also stream to the Sertainty Server's Data Registry for a centralized audit trail across the deployment, and out to a SIEM (Splunk, Sentinel, QRadar, or similar) for correlation with other custody signals.
• Policy is embedded, not attached. Access rules live inside the Vault, sealed at creation. A custodian in possession of the Vault cannot silently loosen access, extend expiration, or hide events without breaking authentication.
• Workflow automation at custodian boundaries. The Workflow Service runs Auto-Protect on ingress and Auto-Unprotect on egress at every custodian handoff, so each transition between environments is a scripted, logged event rather than a manual step.

A typical chain-of-custody workflow (Sertainty Server + Tech Hub):

1. Set up the infrastructure. Bring up Sertainty Server and install Tech Hub. When Tech Hub is paired with Sertainty Server, the Workflow Manager and Server Manager modules become available. See the Getting Started with Workflow section and the Sertainty Tech Hub section.
2. Create the custody Identity in Tech Hub. In Identity Studio, create the Identity that will govern access to material in the chain. Use a Delegate Identity rather than a static Identity if the custodian list will change over time; Delegate lets you add or revoke custodians on the Server without rebuilding each Vault. See What is the Delegate Service, and when should I use it?.
3. Configure the initial protect step. In Workflow Manager, create a Source-Node configuration on the environment where custody begins (evidence collection point, intake system, ingestion endpoint). Add an Auto-Protect task that wraps every arriving file into a Vault using the custody Identity, then hands the Vault to whatever transport moves it to the next custodian.
4. Configure the handoff points. At each downstream custodian environment, create a Destination-Node configuration in Workflow Manager. Add an Auto-Unprotect task that authenticates arriving Vaults against the Delegate Identity, and (if the material moves on) an Auto-Protect task that re-wraps output for the next handoff.
5. Track activity centrally. Server Manager surfaces the Data Registry — a live record of Vault activity across every configured Node. Filter by Vault, Identity, custodian, or time window; export for external audit; feed into a SIEM.
6. Terminate custody when the timeline ends. Set a Compliance date on Vaults that must be permanently unrecoverable after a retention window. When opened after that date, the Vault self-destructs its contents on activation. See What is a Compliance date, and how does it affect Vault access?.

What lands in the audit trail:

• Every authentication attempt against the Vault (success and failure), with the challenging User, source device, source network, and geo where policy captures them
• Every open, extraction, and modification, including the User's Vault-level privileges at the time (Read / Write / Owner / ReadEvents / etc.)
• Failed-policy events (unauthorized location, unauthorized device, out-of-schedule attempt) that would otherwise be invisible
• Custodian changes at the Delegate level (add, revoke, role change) — recorded on the Sertainty Server
• Workflow task transitions (Auto-Protect fired on file X at time T, Auto-Unprotect fired on file X at time T'), recorded by the Workflow Service

Custodian handoff mechanics:

• Adding a custodian: add the new User to the Delegate on the Sertainty Server via Tech Hub → Server Manager → Delegate management. Every Vault using the Delegate picks up the change on next open; existing Vaults do not need to be rebuilt.
• Revoking a custodian: remove or disable the User on the Delegate. Their next open attempt fails and is recorded. If offline caching is enabled, revocation takes effect after the current cache window expires; see How does offline access work with Delegate caching?.
• Transferring Owner privilege: the current Owner can update the Vault's Identity (via Data → Update Identity for Vault in Vault Explorer) to promote the next custodian to Owner, with the event recorded in the audit trail.
• Sealing the record. When custody ends and the audit record must be preserved as-is, set the Vault to Read-Only Vault and check Compliance Locked so the Compliance settings can no longer be changed. See What is a Compliance date, and how does it affect Vault access?.

Tech Hub's Workflow Manager includes a Demonstration configurations toolbar button that creates two example workflows under Configurations. They are a good way to see a working configuration before building your own, and work as starting templates to copy and modify.

• OfficeExample — watches a folder for office documents and automatically protects (or unprotects) them. It ships with four tasks: Auto-archive log files (a timed task that periodically protects log files into a Vault), Office Protect (watches Office/ToProtect for office documents), Office Unprotect (watches Office/ToUnprotect for Vault files), and Office Unprotect (Downloads) (watches the user's downloads folder for Vault files).
• ServerExample — simulates a multiple-server workflow.

The button warns before it runs that it will overwrite any existing example or demonstration configurations, and confirms when it has finished creating the configurations and their simulated workflow folders.

Treat the examples as read-write scaffolding: open one, inspect its tasks and scripts, then copy it into a configuration of your own rather than editing the demonstration in place. For the concept of what a configuration is, see What is a Workflow Configuration in Tech Hub?. For the Tech Hub view, see Sertainty Tech Hub Guide, Example workflows.

FIPS 140-2 and its successor FIPS 140-3 are U.S. federal standards published by NIST that define security requirements for cryptographic modules. They are administered through the Cryptographic Module Validation Program (CMVP). FIPS 140-3 is the active standard as of 2023; FIPS 140-2 certificates remain valid until their expiry date.

A cryptographic module is the specific hardware, software, or firmware component that implements approved cryptographic functions (encryption, hashing, key generation, etc.). The FIPS standard validates the module, not the full application or Application Development Kit that calls it.

FIPS compliance is typically required for:

• U.S. federal government agencies and their contractors
• Systems handling Controlled Unclassified Information (CUI) or Sensitive But Unclassified (SBU) data
• FedRAMP-authorized cloud services (Moderate and High baselines)
• DoD systems under STIGs or RMF authorization
• Healthcare (certain HIPAA contexts) and financial systems with specific regulatory requirements

No. Only the cryptographic module within the Application Development Kit needs FIPS 140 validation. The rest of the Development Kit, networking layers, serialization, UI helpers, business logic, does not need to be validated. It must, however, invoke the validated crypto module correctly and must not bypass it or call non-validated crypto routines.

The crypto library or engine that the Application Development Kit calls must hold a current CMVP validation certificate. Common examples include:

• OpenSSL with FIPS Provider (validated under CMVP)
• AWS-LC-FIPS (Amazon's validated cryptographic library)
• Bouncy Castle FIPS (Java / C#)
• Microsoft CNG / Windows cryptographic primitives
• wolfCrypt FIPS Edition

Key management code that calls into the validated module is generally within scope for compliance review, but does not itself need a separate certification. The critical requirement is that all key generation, storage, and derivation operations use only the validated module's approved algorithms. If key management logic implements any cryptographic operations directly (outside the validated module), those operations would fall outside the FIPS boundary and would be non-compliant.

See What encryption does UXP Technology use? for how Sertainty handles keys inside the Vault boundary.

The cryptographic boundary is the precisely defined perimeter of the validated module. All FIPS-approved operations must occur inside this boundary. Your Application Development Kit and application must not perform any cryptographic operations outside it, for example, using a language runtime's built-in crypto (e.g., Python's hashlib calling a non-validated backend) would violate the boundary.

Separate application-level validation may be required in these specific scenarios:

• The application implements custom cryptographic logic (not delegated to a validated module).
• Specific agency contracts explicitly require CMVP validation of the full application binary.
• The application is being certified under a hardware security module (HSM) program where the HSM must be independently validated.
• The system is seeking NIAP Common Criteria certification, which has its own scope requirements.

"FIPS mode" means the application is configured to exclusively use the validated cryptographic module and has disabled all non-approved algorithms. For example, enabling OpenSSL's FIPS provider forces the process to reject calls to non-approved ciphers like MD5 or RC4. Running in FIPS mode is a runtime configuration requirement, it is not automatic and must be explicitly enforced.

To claim FIPS compliance, your application and Application Development Kit must:

• Use only CMVP-validated cryptographic modules (check the active NIST CMVP list).
• Operate those modules in their approved mode of operation.
• Ensure no code path invokes non-validated crypto, including third-party libraries, language runtimes, or OS primitives.
• Use only FIPS-approved algorithms (AES, SHA-2 / SHA-3, RSA, ECDSA, etc.) and key lengths.
• Disable or remove non-approved algorithms (MD5, DES, RC4, SHA-1 for signatures, etc.).

Check the NIST CMVP Active Certificates list at csrc.nist.gov/projects/cryptographic-module-validation-program. Always verify the specific version / build of the library you are linking against, a newer or older build of the same product may not be validated. The certificate will also specify the approved mode of operation you must follow.

FIPS validated means the module holds an active CMVP certificate issued by NIST, it has been independently tested by an accredited lab.

FIPS compliant is an informal term sometimes used by vendors to mean their product uses approved algorithms or is designed to meet FIPS requirements, but has not necessarily been submitted for or passed CMVP testing.

For regulated environments, only FIPS validated modules satisfy the formal requirement.

Reference: NIST CMVP. Cryptographic Module Validation Program.

For Sertainty-specific FIPS answers, see Does Sertainty use FIPS-validated cryptography? and If I build an app with UXP Technology, is my application automatically FIPS validated? in the How data stays protected section.

Controlled Unclassified Information (CUI) is the federal data classification for information that requires protection under DoD and federal contracts but is not classified. NIST SP 800-171 establishes the baseline security requirements for CUI handling in nonfederal systems.

Sertainty UXP Technology addresses CUI handling at the data layer:

• Per-file access control. Every Vault enforces its own access rules at every open. CUI documents are protected by the authentication policy embedded at creation. Aligns with 800-171 Access Control (3.1) and Identification and Authentication (3.5).
• Per-file audit trail. Each Vault can record access events (successful and failed) to the Data Registry and / or an external SIEM. Aligns with Audit and Accountability (3.3).
• Offline / disconnected authentication. Vaults authenticate without network connectivity, supporting field and contingency CUI handling. Aligns with Media Protection (3.8) and System and Communications Protection (3.13).
• Cryptographic protection. FIPS 140-3 validated AES 256 protects CUI at rest, in flight, and in use. See Does Sertainty use FIPS-validated cryptography? and What encryption does UXP Technology use?.
• Source-level protection of access policy. The ID Definition XML must be protected as source code (see What is an ID Definition (ID Def)?) since it carries the access rules for CUI-handling Vaults.

Sertainty does not by itself satisfy all 800-171 controls. Controls in the Configuration Management (3.4), Maintenance (3.7), Personnel Security (3.9), Physical Protection (3.10), and Security Assessment (3.12) families remain organizational responsibilities. UXP addresses the data-protection layer; the rest of the customer's program supplies the surrounding controls.

Continuous monitoring is a foundational RMF requirement: ongoing visibility into security control effectiveness, vulnerabilities, and access events. Sertainty supports ConMon through several mechanisms:

• Per-Vault event reporting. Each Vault can be configured to report access attempts to the Sertainty Data Registry. Rules in the Identity gate this behavior (RecordRemote, RemoteURL, LogAccesses, LogFailures, LogMessages, LogRepeats). Events include user, time, location, and policy outcome.
• SIEM export. Event records use a structured format consumable by syslog, JSON, or HTTP-pushed event sinks; they can feed Splunk, Sentinel, QRadar, or other DoD-approved SIEM stacks.
• Real-time access tracking. The Data Registry provides a queryable repository of every Vault event across the deployment.
• Failure-mode events. Failed authentication attempts, geo-fence violations, time-window violations, and mitigation triggers all generate event records, providing direct visibility into both authorized and unauthorized activity.

See How does the Data Registry track Vault events? and Can Vaults feed access events into a SIEM? for the underlying mechanisms.

What Sertainty does not provide:

• A complete SIEM platform: Vaults feed your existing SIEM, doesn't replace it.
• Continuous vulnerability scanning: supplied by your other ConMon tooling.
• ATO posture monitoring: supplied by your GRC / ConMon tooling.

UXP's design makes it well-suited to data spillage prevention scenarios. Cross-domain spillage (sensitive data leaving an authorized environment for an unauthorized one) happens through common patterns: emailed to the wrong recipient, copied to a USB drive, uploaded to an unsecured cloud share, accidentally synced to a less-trusted system. UXP's protection model addresses these directly:

• Protection travels with the file. A Vault that leaves an authorized environment retains its access controls. The protected contents stay protected on the destination, regardless of where the destination is. See Does Vault protection still apply if a file leaves my secure environment?.
• Identity-embedded access. Each Vault authenticates against the embedded Identity (or Delegate). A user in the destination environment cannot open a Vault unless they hold the right Identity. Wrong-recipient mishandling produces an inert binary blob that the recipient cannot decrypt.
• Per-file audit trail of every attempt. Failed attempts at the destination produce event records routed back to the source organization's Data Registry / SIEM. Spillage attempts become detective signals.
• Air-gap-compatible. Vaults authenticate offline, so the protection extends to removable-media transfers across air gaps. See What is an airgap, and does Sertainty UXP Technology work in airgapped environments?.

UXP is not a cross-domain solution (CDS) in the formal NSA / IC sense. CDS systems mediate transfers between security domains (for example, NIPR to SIPR) with NSA-evaluated guards. A Vault is a complementary file-level protection that travels with the data; it does not replace a CDS, but it does ensure that even if spillage occurs at the boundary, the data inside the Vault remains protected by its embedded policy.

Government and military operations routinely require working in environments where connectivity is by design absent, intermittent, or tightly restricted. The most familiar example is a Sensitive Compartmented Information Facility (SCIF): an accredited space for handling SCI-level material, with strict physical, procedural, and emanations controls and no live link to unclassified networks. Comparable scenarios appear across DoD and the Intelligence Community:

• SCIFs and Special Access Program Facilities (SAPFs). Accredited domestic spaces for handling TS/SCI or SAP-controlled material.
• Tactical Operations Centers (TOCs) and Forward Operating Bases (FOBs). Deployed locations where SATCOM is contested, throttled, or intentionally silenced.
• Naval and submarine operations. Surface vessels underway with intermittent satellite comms; submarines under prolonged emissions-control conditions.
• Airborne C2 and ISR platforms. E-4B / E-6B command aircraft, RC-135 / AWACS ISR, and similar platforms operating with selectively enabled comms.
• Coalition partner facilities. Multi-national operations where allied personnel need to access shared mission data without using one nation's classified network as the transport.
• DDIL conditions generally. The DoD term for Denied, Disrupted, Intermittent, or Limited bandwidth operating environments, a recognized JADC2 design constraint.

Sertainty UXP Technology is well-suited to these environments because its protection model does not depend on live connectivity:

• Authentication is local. Every Vault authenticates against the Identity embedded in it at creation. No Sertainty service, license server, or external directory needs to be reachable at open time. See Can a Vault authenticate users without any network connectivity? for the offline guarantee.
• The license file is local. sertainty.lic is read from the Application Development Kit's home/ folder at process startup; there is no online license-validation call. Installations inside a SCIF or on a deployed platform stay functional indefinitely without phone-home. See What happens to Vault files if my license expires?.
• Protection travels with the file. A Vault burned to optical media, copied to a USB drive, or carried on a hard-disk transfer kit between facilities remains protected end to end. Loss or interception of the media does not expose the contents. See Does Vault protection still apply if a file leaves my secure environment?.
• Per-file access control inside the facility. Personnel inside a SCIF do not automatically have access to every protected file in the facility. Each Vault enforces its own rules at every open, supporting compartmentalization within the cleared population.
• Audit events survive disconnected operations. Failed authentication attempts, mitigation triggers, and successful opens can be recorded to the Data Registry on the local host. When the system later reconnects to a higher tier, events can be replayed into a SIEM or audit pipeline. See Can Vaults feed access events into a SIEM? and How does the Data Registry track Vault events?.
• Cross-facility transfer with intact protection. Moving a Vault from one SCIF to another, via courier with removable media or across an accredited cross-domain transfer path, preserves the access policy. The receiving facility's personnel still must authenticate against the embedded Identity to open the file. See Can Sertainty UXP Technology help prevent cross-domain data spillage?.

What Sertainty UXP Technology does not replace:

• Accredited classified networks (SIPRNet, JWICS, NIPRNet, CWAN, and equivalents) and the cross-domain solutions that mediate transfers between them. A Vault is a file-level protection that travels with the data; it does not substitute for an NSA-evaluated cross-domain guard or an accredited classified transport.
• Physical and emanations security. SCIF accreditation, TEMPEST controls, RF shielding, and secure-room construction standards remain physical-security and facility-engineering responsibilities outside UXP's scope.
• Personnel security and clearance management. Whether a given user holds the appropriate clearance to receive a UXP-protected file is a personnel-security determination handled by the customer's program; the Vault enforces what the access policy says, but the policy itself must be set correctly.
• Independent ATO posture. Sertainty itself does not currently hold a DoD or IC Authority to Operate. Operating the Development Kit inside a SCIF or any classified environment requires the customer's own ATO review against the appropriate framework (RMF / DoD 8510.01 for DoD systems, ICD 503 for IC systems). The FIPS 140-3 validation of the cryptographic module UXP uses is one input to that review, not a substitute for it.

For the foundational mechanics that make these scenarios work, see What is an airgap, and does Sertainty UXP Technology work in airgapped environments? for the general airgap framing, Can a Vault authenticate users without any network connectivity? for offline auth, and Can Sertainty UXP Technology help prevent cross-domain data spillage? for cross-boundary data handling.

NIST SP 800-88 defines three sanitization categories: Clear (logical overwrite), Purge (cryptographic erase or physical-level overwrite), and Destroy (physical destruction). DoD environments commonly require Purge or Destroy for media that has held CUI or classified data.

Sertainty UXP Technology's destructive mitigation capabilities align with 800-88 as follows:

• Logical-level Clear. Both the per-file Shred (ModifierShred) and the whole-Vault Shred-and-Destroy options perform a logical-level overwrite of the data being removed. On traditional magnetic media (rotating HDD), this approximates 800-88 Clear sanitization for the affected data.
• Purge limitations on solid-state media. As noted in Can a Vault really self-destruct, and under what conditions?, electronic shred cannot guarantee physical-level erasure on SSD or NVMe due to wear-leveling and block remapping. A Vault's destructive actions complete at the logical level but do not satisfy 800-88 Purge requirements on solid-state media.
• Cryptographic erase complementary. Because each Vault holds its keys inside itself, destroying the Vault also destroys the keys, effectively rendering any cached or scattered fragments cryptographically inaccessible. This is the "cryptographic erase" approach 800-88 recognizes for solid-state media.
• Destroy category. Physical destruction of the media (the 800-88 Destroy category) remains an organizational responsibility outside UXP Technology.

UXP Technology's destructive capabilities are best understood as part of an organization's overall 800-88 strategy, not a complete substitute for it.

Yes, through Sertainty's per-file access control. UXP's design accommodates multi-level security patterns without requiring a separate MLS platform:

• One Identity per classification level. Create a distinct Identity for each classification level (UNCLASSIFIED, CUI, SECRET, etc.). Vaults protecting data at a given level are created with that level's Identity embedded.
• Per-Identity policies. Each Identity carries its own access rules (clearance-equivalent challenges, location restrictions, time windows). A user holding only the UNCLASSIFIED Identity cannot open a Vault created with the SECRET Identity, even if they have file-system access to it.
• Workgroup composition for cleared roles. A workgroup Identity can represent a group of users at a specific clearance level. Members are added or removed by managing the underlying individual Identities.
• Delegate-managed clearance lists. For larger or dynamic populations, a Delegate Identity routes authentication to a Sertainty Services Server that maintains the authoritative clearance list, with audit events flowing into the Registry.
• Per-file audit at every level. Access attempts (successful and failed) at each level produce event records, supporting clearance-violation detection and after-action audits.

Important context: UXP supports the data-protection layer of an MLS deployment. A formal MLS implementation (Bell–LaPadula / Biba enforcement at the OS or hypervisor level, NSA-evaluated cross-domain guards, classified-network separation) involves controls outside UXP's scope. UXP is well-suited as the file-level enforcement layer within an MLS architecture rather than as the entire architecture.

The Sertainty Development Kit is a restricted technology subject to U.S. encryption export laws administered by the Department of Commerce, Bureau of Industry and Security (BIS).

Key classification details:

• Commodity Classification: ECCN 5D002, sub-paragraph c.1
• Classification effective date: August 13, 2021
• Controls: NS Column 1, AT Column 1, and EI
• License Exception: ENC, authorized under EAR Sections 740.17(A) and (B)(3)

Yes, in most cases. Any application that incorporates Sertainty technology requires a BIS filing before it can be deployed or distributed outside the United States and Canada. This applies regardless of where the code lives: cloud servers, mobile devices, desktops, laptops, gateways, radios, or any other platform.

Yes. If your application is strictly restricted to use within the United States and / or Canada only, a BIS filing is not required. The moment the application is intended for use or distribution outside those two countries, a filing becomes necessary.

You must obtain the export classification at least 30 days before any deployment or distribution outside the United States.

No. Even within the United States, employees or contractors who are legal citizens of countries on the U.S. Government's restricted ("bad") country list cannot be given access to the code or the application. This restriction applies to both employees and contractors.

Yes. For encryption technology, Canada is treated the same as the United States under the EAR. Canada is the only country in the world that does not have an "X" in the NS Column 1 or AT Column 1 of the BIS country chart, meaning no license or exception is required to export to Canada on those grounds. Additionally, the EI control (§ 742.15) explicitly exempts Canada.

No. You cannot export out of Canada to destinations outside the United States. The Canada exemption applies only to the U.S.-to-Canada transfer.

No. Sertainty's export rights are based on the ENC exception under the EAR. That ENC exception does not automatically extend to products built by Sertainty's business partners that incorporate or bundle the Application Development Kit.

Bundled products, those that include or use the Sertainty Development Kit, may or may not independently qualify under the ENC exception. Your right to export your bundled product may fall under a separate part of the EAR, and you must determine your own classification and exception eligibility.

Business partners should independently determine the export classification of their bundled product and apply for the appropriate BIS classification or license exception, at least 30 days prior to any export outside the U.S. and Canada. Consult with qualified export counsel familiar with the EAR if there is any uncertainty.

Work these five checks in order before diving deeper. Each rules out a whole class of problems:

• Confirm the license is present and valid. A missing or expired sertainty.lic stops every UXP operation. See What happens to Vault files if my license expires?.
• Confirm the library initializes. Initialization is the first call any program makes against the Application Development Kit and where setup problems surface first. See What should I check if library initialization fails?.
• Run the built-in smoke test. The UXL Flow A sample exercises a full create-and-reopen round trip and prints PASS on success:

Shell

cd ~/Sertainty/Developer/examples/uxl
SertaintyScript -b @flow_a_id_uxp.uxl

If this passes, your install, license, and engine are healthy and the problem is in your own code or data.

See How do I verify a v5 Release install is working?. - Read the actual error message. Don't guess from behavior, capture the text.

See How do I read the error when a UXP operation fails?. - Isolate the failing step. Note whether it fails at create, open, authenticate, or extract; that alone points you to the right entry below.

How failures are surfaced depends on which interface you're calling. In every case the goal is the same: capture the human-readable message text, which is the authoritative diagnostic rather than a numeric code alone.

• Core C / C++ API. Calls report failure and write a human-readable message into the uxlByteArray * buffer you pass in; read it with uxpba_getData(). Full walkthrough: What should I check if library initialization fails? and How do I handle and interpret UXP API error codes and status returns?.
• UXL scripts. After a call, test errorstring and stop or branch on it:

UXL

bytearray data;
data = file::readAll("input.xml");
if (errorstring) {
  printf("Error reading file: %1\n", errorstring);
  return;
}

See How do I handle errors in UXL?.
- Services API. The service layer returns structured status/error codes for message-level failures. See What error codes should I expect from the Services API?.

Always log the captured message alongside the operation you attempted (create / open / authenticate / extract) and the Identity or Vault involved. That pairing turns a vague "it failed" into a one-line diagnosis.

From V5.0 onward, an invalid or expired license disables all operations that run through the UXP Technology: opening or creating Vaults, authenticating Identities, and any UXL/C/C++/service that loads the Sertainty libraries. Symptoms therefore look like a total failure at the first UXP call, not a partial one.

• Check the file is where the engine expects it. The license is sertainty.lic in the ~/Sertainty/Developer/home/ directory. Licenses are issued per customer; if you placed the file there manually, verify the filename spelling and case are exactly sertainty.lic.
• Check it hasn't expired. Replace an expired sertainty.lic with an updated file obtained through your Sertainty contact.
• Check permissions and integrity. The process must be able to read the file, and the file must not be truncated or altered in transit (re-download if unsure).

Background and exact behavior on expiry: What happens to Vault files if my license expires?. Protected Vaults are never harmed by an expired license; access is simply gated until a valid license is back in place.

Initialization failures almost always trace back to environment rather than logic. Capture the message the library writes on failure (see What should I check if library initialization fails?), then check, in order:

• License. The single most common cause; see the license entry above.
• Runtime libraries are found and loadable. The Sertainty shared libraries must be on the OS loader path, and match your process architecture (no 32/64-bit or edition mismatch):
  • Linux: LD_LIBRARY_PATH
  • macOS: DYLD_LIBRARY_PATH
  • Windows: PATH
• Edition matches your platform. Confirm you installed the correct SertaintyDeveloper for your OS and CPU.
• Required support files exist. The home/ directory must contain sertainty.rsf (a distributed file shipped with the Application Development Kit) alongside sertainty.lic. The runtime locates home/ by searching the directory containing the Sertainty core library, the current working directory of the running application, and the directory adjacent to the core library.
  
  See the Home Directory section of the Sertainty Technology Guide's Core Framework chapter.

Confirm a clean baseline with the Flow A smoke test in How do I verify a v5 Release install is working?. If that runs, initialization works and the issue is in how your application loads the libraries.

Authentication is the challenge/response loop that gates access to a Vault. When it fails, capture the status the engine returns at each prompt.

See What status codes will I see during authentication?.

• Right Identity, right Vault. Confirm you're authenticating with the Identity that actually governs this object.
• Prompt/response alignment. Answer every challenge the engine issues, in order, with values that exactly match the responses stored for that User inside the Identity; a missing or mismatched response fails the whole loop.
• Policy conditions are met right now. Access policies can gate on time windows, location, or other conditions; a valid credential can still be denied if those conditions aren't currently met.
• No network assumptions. UXP authentication is designed to work offline; if you added a network-dependent step, verify it independently. See Can a Vault authenticate users without any network connectivity?.

The canonical open-and-authenticate sequence is in How can an existing Vault be opened and authenticate to read its contents?.

Distinguish "can't open the file at all" from "opens but won't authenticate." This entry is the former; for the latter see the authentication entry above.

• File integrity. A Vault transferred over a channel that altered bytes (e.g. text-mode FTP, an email gateway that rewrote it) can be corrupted. Compare size/checksum against the source and re-transfer in binary/raw mode if they differ.
• Complete file. A truncated or still-uploading object will fail to parse. Confirm the transfer finished.
• Cross-OS is expected to work. A Vault created on one operating system opens on another; if it doesn't, suspect transfer corruption rather than platform. See Can I create a Vault on one operating system and open it on another?.
• Engine can read the object's format. v5 engines can open Vaults created by earlier versions. Vaults created in v5 are not backward-compatible; earlier engines cannot open them.
• You are using an application built with the UXP Technology. Opening a Vault requires an application that has the UXP Technology built in (Sertainty Tech Hub, a custom Application Development Kit application, or Workflow Auto-Unprotect); there is no generic viewer. See How do I open a Vault? Do I need a special app?.

Compile/link failures are environment mismatches, not runtime issues. Start from the documented build environment: What environment do I need to build against the v5 Release?. Then check:

• Toolchain version. The Sertainty libraries are 64-bit and compatible with standard compilers; see the Sertainty Technology Guide for the current minimum toolchain requirements.
• Headers and libs from the same release. Mixing headers from one Application Development Kit version with binaries from another causes unresolved-symbol and ABI errors. Use one SertaintyDeveloper throughout.

• Correct library on the link line. Link against the Sertainty core library for your platform and any dependencies it requires:

  • Linux: lib/libsertaintycore.so
  • macOS: lib/libsertaintycore.dylib
  • Windows: bin/sertaintycore.dll

  UXP libraries use cdecl on Linux/macOS and stdcall on Windows; the caller must match the correct calling convention.
  - Architecture match. Object files, the Sertainty libraries, and your target must all be the same architecture (no x64/arm64 or 32/64 mix).

Unresolved symbols at link time mean the library isn't found or is the wrong build; unresolved symbols or "library not loaded" at run time mean the loader path is wrong; see the initialization entry above.

Service-side failures split into transport (can't reach the server) and authorization (reached it, message rejected).

• Server is up and reachable. Confirm the service is running and the host/port are reachable from the client (firewall, container networking, wrong endpoint).
  Setup reference: How do I set up a Sertainty Services server?.
• Access code matches. Service API messages are secured by the access code; a mismatch rejects otherwise valid requests.
  See What is the access code, and how does it secure service API messages?.
• Database backing the service is available. The services database (SQLite or MySQL) must be reachable and initialized.
  See Should I use SQLite or MySQL for the Server framework? for setup requirements.
• Read the returned code. Map the response against What error codes should I expect from the Services API?.

A few terms appear throughout the Application Development Kit and the rest of this Knowledge Base.