Security & Verification

This page explains how Vault Platform security works in practice — the specific mechanisms, enforcement order, and what is checked at each boundary. For compliance posture, sub-processor lists, and pen-test scoping, see the Trust Center.

The No-Egress Principle

Vault Platform is built on a single foundational rule: your document data never leaves your Azure environment.

Unlike a conventional PDF SaaS API where you upload data to a vendor's cloud, every render in Vault Platform happens inside your own Azure subscription. The rendering engine runs in your Dispatcher Function App. Templates are retrieved from your SharePoint. Generated PDFs are stored in your SharePoint or your Azure Blob Storage. At no point does a document payload, a template, or a generated file transit outside your tenant boundary.

Security Architecture Overview

flowchart TB
  subgraph External["Entry Points"]
    SPFx["SharePoint / SPFx<br/>VaultLifecycle UI"]
    D365["Dynamics 365 / Power Automate<br/>Power Platform Connector"]
    Portal["Vault eSign Portal<br/>(External Signers)"]
  end

  subgraph CustomerTenant["Your Azure Environment"]
    Entra["Microsoft Entra ID<br/>Authentication & JWT Issuance"]
    Disp["Vault Dispatcher Function App<br/>JWT validation · Feature gates · Render engine"]
    SB["Azure Service Bus<br/>Priority Queues (MSI-connected)"]
    Proc["Processor Function Apps<br/>VaultWorkflow · VaultESign · VaultDelivery · VaultAudit"]
    KV["Azure Key Vault<br/>All secrets — vendor staff have no standing access"]
    SP["SharePoint<br/>Templates · Generated Docs · Activity List"]
    Blob["Azure Blob Storage<br/>Audit JSONL · Dispatch payloads · Archives"]
    Entra --> Disp
    Disp --> SB
    Disp --> KV
    Disp --> SP
    Disp --> Blob
    SB --> Proc
    Proc --> KV
    Proc --> SP
    Proc --> Blob
  end

  subgraph VaultShared["Vault Platform Shared Services"]
    Lic["Licensing API<br/>licenseKey + tenantId only"]
    Notify["VaultNotification<br/>Metadata only — no document content"]
  end

  SPFx -->|"Entra ID Bearer JWT + Function Key"| Disp
  D365 -->|"OAuth 2.0 Bearer JWT"| Disp
  Portal -.->|"HMAC portal token · HTTPS"| Disp
  Disp -.->|"licenseKey + tenantId"| Lic
  Proc -.->|"Event metadata only"| Notify

What Crosses to Vault Shared Services

This reference answers the question that matters most for data residency and compliance reviews: exactly which data transits Vault Shared Services infrastructure, per product.

Data transit reference by product

Notes on in-memory transit and byte paths

Signature PNG (VaultESign): The signer draws their signature in the browser on the portal UI. When they submit, the portal server constructs an HMAC-signed callback body — which includes the signature PNG — and POSTs it to your Dispatcher. The PNG transits portal servers in-memory during this callback. It is not stored on portal servers and the callback is HMAC-verified by your Dispatcher before use.

File attachments (VaultWorkflow): Attachment uploads use a pre-signed Azure Blob SAS URL issued by your Dispatcher. The browser uploads the file bytes directly to your Azure Blob Storage container — the portal server is never in the upload path and never receives the file content.

Document download (VaultDelivery): The delivery portal (portal.vaultpdf.io) serves session metadata only (document name, expiry, state). When the recipient downloads, their browser calls your Dispatcher's SAS endpoint, which issues a short-lived Azure Blob SAS URL. The document bytes stream directly from your Azure Blob Storage to the recipient's browser — portal servers are not in the byte path at any stage.

Notification emails: In vault-shared mode, the notification payload (email address, portal link, document name, notification type) transits the VaultPDF notification service. In customer-acs mode, notifications are sent directly from your own Azure Communication Services instance and Vault Shared Services is not involved for delivery or workflow notifications. See Email Provider Configuration for the current VaultESign caveat.

Layer 1 — Microsoft Entra ID Authentication

Every request to Vault Platform begins at Entra ID. This is not optional and cannot be bypassed.

SharePoint / SPFx callers

VaultLifecycle is a SharePoint Framework (SPFx) web part and command set deployed inside your SharePoint environment. Before the SPFx components load:

1. The user must authenticate to your SharePoint site with a valid Entra ID session.
2. SharePoint enforces site-level permissions. A user without access to the VaultPDF SharePoint site cannot reach the page.
3. Only after a valid SharePoint session is established does the SPFx runtime load and the VaultLifecycle workspace become visible.

There is no way to access VaultLifecycle content by guessing or crafting a URL. Authentication to SharePoint is a hard prerequisite.

Power Platform / Dynamics 365 callers

The Vault Platform Power Platform Connector uses OAuth 2.0 with Entra ID as the identity provider. Every API call carries a Bearer JWT. The Dispatcher Function validates the token on every request — there is no session or cookie that persists across calls.

Direct API callers

Direct calls to the Dispatcher Function API require:

• A valid Azure AD Bearer JWT (validated on every hop)
• A Function host key passed as ?code= in the query string

Both must be present. The function key is stored in your SPFx property bag (encrypted at rest by SharePoint) and is never embedded in client-side source code.

Layer 2 — VaultLifecycle Access Control

VaultLifecycle enforces a four-layer access control model. All four layers apply identically whether the workspace is opened manually (by clicking the command button) or via a deep link.

Layer 2a — SharePoint site authentication

Covered above. Unauthenticated users cannot reach the page.

Layer 2b — SharePoint list permissions (server-enforced)

All data in VaultLifecycle is read from the VaultPDF_Activity SharePoint list via SharePoint REST API. SharePoint enforces list-level read permissions server-side on every request. A user who does not have Read access to the VaultPDF_Activity list receives an HTTP 403 — the SPFx client receives no data regardless of what filters are set.

This is independent of the SPFx UI. The UI cannot show data that SharePoint refuses to return.

Layer 2c — Admin role resolution (live server-side call on every open)

When the VaultLifecycle workspace opens, it immediately makes two live SharePoint REST calls before displaying any results:

GET /_api/web/currentuser?$select=IsSiteAdmin
GET /_api/web/currentuser/groups?$select=Title

These calls resolve the user's actual admin status from the server at open time. The isAdmin value derived from these calls controls:

• Whether the user sees all items or only items they are permitted to see
• Whether the Configuration panel and admin-only actions are available

There is no client-side override for admin status. A URL parameter, a manipulated prop, or a cached value cannot elevate a user's permissions — the live server response is authoritative.

A user is treated as admin if either:

• They are a SharePoint Site Collection Administrator, or
• They are a member of the VaultPDF.Admin SharePoint group

Layer 2d — Item-level access control (VPDFRestrictionMap)

After SharePoint returns the list of activity items, each item passes through a client-side visibility check before being shown. Items where VPDFExcludeFromSearch=true never return from SharePoint at all (pre-filtered at the OData query level). For all other items, the following rules apply:

VPDFRestrictionMap is a pipe-delimited string stored on each activity item. An example value:

Finance.Approvers=admin|HR.Managers=operational

This means members of the Finance.Approvers SP group see the item at admin level; members of HR.Managers see it at operational level; everyone else sees nothing.

When an item is visible but at operational level (not admin), sensitive fields such as PdfHash, internal metadata, and document integrity controls are redacted — the item is still findable and openable, but privileged information is withheld.

Layer 3 — API Authentication (Dispatcher Function)

Calls from VaultLifecycle to the Dispatcher Function for extended data (audit events, signing state, delivery state, workflow state) use AadHttpClient — the SharePoint Framework's AAD-integrated HTTP client.

Every such request:

1. Automatically attaches a Bearer JWT scoped to the Dispatcher Function's AAD application registration (API_RESOURCE_ID)
2. Includes the Function host key as ?code= (stored encrypted in the SPFx property bag)
3. Is validated by the Dispatcher on receipt — both the token audience and the function key must be valid

Neither of these values is readable from the browser's URL bar, local storage, or network responses in plaintext. The AAD token is issued by Entra ID with a short TTL and is automatically refreshed by the SPFx AAD client.

Layer 4 — Managed Identity for Azure Services

Inside the Dispatcher and Processor Function Apps, all access to Azure services uses Managed Identity (MSI). No passwords, connection strings with credentials, or client secrets are stored in application code or environment variables for Azure resource access.

VaultPDF vendor staff have no standing access to your Key Vault. The secrets your deployment uses (JWT signing keys, encryption keys, ACS keys) are provisioned by your team and accessible only by your Function App's MSI.

Licensing Security

License entitlements are cryptographically signed using JWS ES256 (ECDSA P-256). VaultPDF holds the private signing key. Your Dispatcher holds only the public verification key — it can verify entitlements but cannot forge them.

The runtime uses a 4-tier cascade:

Deep-Link Security

VaultLifecycle supports deep links — URLs with query parameters such as ?batchId=, ?correlationId=, or ?sourceSystem= that pre-populate the search and auto-open the workspace. This is useful for source systems (Dynamics 365, Business Central) that want to provide a one-click link directly to a specific document's lifecycle view.

What a deep link does

What a deep link cannot do

• Grant access to a user who is not authenticated to SharePoint
• Elevate a user's admin status
• Show items the user's SP permissions do not allow
• Show items the user's VPDFRestrictionMap visibility does not permit

A non-privileged user who follows a deep link with a valid ?correlationId=... will see zero results if the corresponding activity item is restricted — the search executes, returns nothing (because SP enforces permissions and the visibility check excludes the item), and the workspace is empty.

CorrelationId and BatchId are globally unique

CorrelationIds and BatchIds are UUID v4 values generated by Vault Platform at render/dispatch time. They are globally unique by construction — no sourceSystem qualifier is needed to identify a specific record. A source system can safely use:

https://your-sharepoint-site/SitePages/Home.aspx?batchId=082ab853-7852-47f0-b078-1927d2d92619

and it will always resolve to exactly that batch. Adding &sourceSystem=D365_FO is harmless but redundant for GUID-based lookups.

eSign Security

VaultESign uses short-lived HMAC-SHA256 portal tokens to authenticate external signers. These tokens are issued by the Dispatcher and verified by the eSign Portal.

The eSign Portal is stateless — it does not store document content. Document bytes are streamed from your storage via the Dispatcher at the moment of signing, and the Portal never retains them.

Document Integrity Verification

Every PDF generated by Vault Platform is SHA-256 hashed at render time. The hash is stored in the VaultPDF_Activity list (PdfHash column) and in the audit JSONL.

Verification process

From VaultLifecycle, any document with a stored hash can be verified in one click:

Audit chain integrity

The immutable audit JSONL uses a hash chain: each event includes a previousHash field linking it to the prior event. The verifier API checks chain continuity from the first event to the most recent. A gap or modification in any event breaks the chain and is reported.

Data Encryption

In transit

All communication within Vault Platform uses HTTPS with TLS 1.2+. This includes:

• SPFx → Dispatcher Function
• Dispatcher → SharePoint Graph API
• Dispatcher → Azure Blob Storage
• Dispatcher → Azure Key Vault
• Dispatcher → Licensing API
• Azure Service Bus connections (AMQP over TLS)

The Dispatcher Function App has httpsOnly: true enforced in the Bicep deployment template. HTTP is rejected at the Azure layer.

At rest

Key Management

All Vault Platform secrets are stored in your Azure Key Vault. The deployment Bicep template provisions the Key Vault with:

• enablePurgeProtection: true — irreversible; prevents secret deletion bypassing soft-delete
• 90-day soft-delete retention
• No standing access granted to VaultPDF vendor staff

Key rotation is an operator action:

az keyvault secret set \
  --vault-name <your-kv-name> \
  --name esign-encryption-key \
  --value <new-key>

The approver-email ciphertext schema includes a keyId field to support re-encryption on key roll without data loss.

Input Validation and Injection Prevention

Security Layer Summary

The following table summarises what is enforced at each boundary for a typical VaultLifecycle open — manual button click or deep link:

Compliance Summary

For the full sub-processor list and data processing addendum, see the Trust Center.