Security You Can Trust
Identity Mesh runs on your own Windows servers and SQL Server. Identity data stays in your network, secrets live in a secret store you choose, every change lands on a tamper-evident audit chain, and each feature keeps its own permissions and boundaries.
Security Posture
Built for on-premises deployment with enterprise security at every layer
Identity Mesh is designed as on-premises software that deploys within your own data center or private infrastructure. Your identity data stays within your network: there is no vendor cloud, no multi-tenant infrastructure, and no outbound connection the product needs. Every outbound path is one you configure and can leave off: a cloud directory connector, an email provider, Azure Key Vault, or the optional AI assistance, which is off by default and sends nothing until you enable it and accept its data agreement.
Security Features
Secret Protection (DPAPI, Key Vault or HashiCorp)
Connection strings, passwords, API keys, and sensitive configuration values are held in a secret store, never in configuration or identity records, and resolved at runtime via secret:// references. Choose Windows DPAPI on the host, Azure Key Vault, or HashiCorp Vault, and switch between them from Settings.
- AES-256 via Windows DPAPI, or Azure Key Vault / HashiCorp Vault
- Machine-bound keys (LocalMachine scope)
- Encrypted connector connections: LDAPS to Active Directory, HTTPS to cloud services, TLS to SQL Server
- Runtime-only decryption (secrets never in config files)
- Password attributes redacted at storage, in the API and in the portal
Access Control
Role-based access control with Windows Negotiate authentication (Kerberos/NTLM), or Entra ID sign-in, for the Admin UI and API. Permissions are named per feature area, so Vault, workflows, groups and migration each have their own.
- Role-based access control (RBAC)
- Windows Negotiate auth (Kerberos/NTLM)
- Least-privilege principle: a role carries only the permissions it needs
- Vault-only role for people who check out credentials and nothing else
- Workflow approvals: the person a run is for can never approve it; operator overrides are recorded as such
Tamper-Evident Auditing
Every identity change, admin action, vault event and group decision is logged with full context and hash-chained: each row carries the hash of the row before it, so an edited or deleted entry breaks the chain and the verification says where.
- Before/after value tracking
- Run history per connector
- Four hash-chained audit tables, verified from the portal or the engine
- SIEM forwarding: file, Windows Event Log, Syslog, webhook, Microsoft Sentinel (CEF/LEEF)
- Subject-access export and erasure that leaves a chained marker
Workflow Boundaries
Automation runs with the same discipline as a sync: signed code only, signed messages out, and a human in the loop where you put one.
- Custom steps load only as Authenticode-signed packages from publishers you allow-list; unsigned code never runs
- Outbound webhooks carry an HMAC-SHA256 signature and timestamp so the receiver can verify every delivery
- PowerShell steps run under a credential held in the secret store, with file or inline scripts you control
- Loop and burst guards hold runaway runs for an operator instead of letting them flood a directory
Vault Separation
Identity data decides who may ask. Credential material is handled apart from it.
- Credential material is encrypted in the secret store and never written to identity records
- Released one checkout at a time with a one-time reveal; IdentityMesh Connect opens Remote Desktop without showing the password
- Own permissions and role; access scoped by group membership your connectors already import
- Every nomination, approval, checkout, check-in and rotation is a chained audit event
Supply Chain and Disclosure
What you can verify about the software itself before it runs.
- Release installers are Authenticode-signed; a CycloneDX SBOM is published with each release
- STRIDE threat model maintained; RFC 9116 security.txt published
- Licences are RSA-4096 signed and verified on every sync cycle
- Coordinated disclosure: see the disclosure policy and acknowledgements
Encryption Architecture
How Identity Mesh protects secrets at rest and in transit
- EnteredConnector credential
- Stored
- EncryptedDPAPI, Azure Key Vault or HashiCorp Vault
- At run time
- UsedRead by the connector at run time
Secrets at Rest — Windows DPAPI
Identity Mesh uses the Windows Data Protection API (DPAPI) to encrypt all secrets stored in the SQL database. DPAPI is a built-in Windows cryptographic service that provides symmetric encryption without requiring your application to manage encryption keys directly.
How DPAPI Works
- AES-256 encryption — DPAPI uses AES-256-CBC (Advanced Encryption Standard with 256-bit keys) as its underlying cipher. This is the same encryption standard used by governments and financial institutions worldwide.
- Machine master key — The AES key is derived from the Windows machine's master key, which is itself protected by the machine's DPAPI system key. This key is bound to the specific server where Identity Mesh is installed.
- No key management burden — You do not need to generate, rotate, store, or distribute encryption keys. Windows handles key lifecycle automatically through the LSA (Local Security Authority).
- Non-exportable — Encrypted secrets cannot be decrypted on a different machine. Even if the SQL database is copied, the secrets remain encrypted and unreadable without the originating server's machine key.
LocalMachine Scope
Identity Mesh encrypts secrets using the LocalMachine scope by default. Any process running on the server can decrypt the secret, but it cannot be decrypted on any other machine. This is the recommended scope for Windows services.
Host Binding
Each DPAPI secret records the server that encrypted it. If the database is moved to another server, a connector that needs the secret refuses to run and names the original server in its error, rather than silently falling back to another credential. Re-enter the secrets on the new server, or use Azure Key Vault or HashiCorp Vault so secrets travel with the deployment.
What Gets Encrypted
secret:// referenceData in Transit
TrustServerCertificate configurableLicense Protection
Identity Mesh licenses are cryptographically signed using RSA-4096 with SHA-256 signatures. The public key is embedded in the engine binary, and the license file is verified on every sync cycle. License files cannot be tampered with or forged — any modification invalidates the RSA signature.
On-Premises by Design
Your data never leaves your infrastructure
Windows Service Deployment
Installed as a Windows Service via MSI on your own servers. No cloud infrastructure required.
Your SQL Server Database
All identity data, audit logs, and configuration are stored in your own SQL Server instance.
Air-Gapped Compatible
The sync engine, Admin API and portal need no outbound internet connection. Cloud connectors, email providers, Azure Key Vault and AI assistance are the only outbound paths, and each exists only if you configure it.
Complete Data Sovereignty
You control where your data resides, how it's backed up, and who has access. No third-party processing unless you switch on AI assistance, which sends only what its data agreement lists, to the provider and key you chose.
Security Architecture
Three trust zones. Everything durable and every secret stays in the first; the second reaches in outbound-only; the third exists only where you create it.
Zone 1 · Your servers
Everything durable and every secret-handling component lives here, under identities you choose at install.
- Admin Portal (IIS) — Static Angular app over HTTPS. Signs in with Windows Negotiate or Entra ID. Holds no data and no secrets.
- Admin API (Windows service) — Kestrel over HTTPS. Enforces every permission server-side, hosts the relay hub, the workflow worker and the Vault, group and migration sweeps. Only this process and the engine touch the secret store.
- Sync Engine (Windows service) — Runs imports, joins, flows, projections and exports. Talks only to SQL Server and to the systems its connectors are given. Never to the API.
- SQL Server — Identity data, configuration, workflow runs and the four hash-chained audit tables. TLS on the connection; TDE and backups are yours to run.
- Secret store — DPAPI on the host (LocalMachine, host-bound), or Azure Key Vault, or HashiCorp Vault. Secrets are referenced by name from configuration and resolved only at runtime.
Zone 2 · Remote segments
Branch offices, partner data centres and segments with no inbound access.
- Relay Agent (Windows service) — Outbound HTTPS only, to the Admin API, authenticated with an API key or an Entra service-principal token. Loads the same signed connector DLLs. Receives already-resolved credentials for its assigned connectors and never decrypts a stored secret.
- Directories and databases it reaches — Active Directory over LDAPS, SQL Server over TLS, files on a share, all from inside that segment.
Zone 3 · Outside, only if you configure it
No path in this zone exists until an administrator creates it, and each one is visible in Settings or on a connector.
- Cloud directories — Entra ID through Microsoft Graph, Okta and Workday through their APIs, over HTTPS with app-only credentials held in the secret store.
- Email provider — SMTP, Mailgun or Microsoft 365 for notifications and approval requests.
- Azure Key Vault — If chosen as the secret store, secrets live there instead of on the host.
- AI provider — Claude or Azure OpenAI, with your key. Off by default; nothing is sent until the Enterprise switch is on and the data agreement is accepted. Every request is audited.
What crosses each boundary
The questions a CISO asks
Straight answers, each backed by a runbook you can hand to your own security team.
One product holds sync, privileged credentials and audit. What is the blast radius?
Smaller than it looks. Credential material never sits in identity tables: it is encrypted in the secret store, DPAPI bound to the host or an external Azure Key Vault or HashiCorp Vault, so a copied database yields no secrets. Vault, workflows, self-service groups and AI assistance each have their own permissions and roles, are switched on separately, and can be left off. Each feature's events chain in its own audit table.
Who can read the secrets?
The service identity on the host, or the identity you grant in Key Vault or HashiCorp Vault. The portal and API never return a stored secret. Password attributes imported from directories are redacted at storage, in the API and in the portal. Vault credentials are revealed once per checkout and rotated on check-in, on a schedule, or on demand.
What leaves our network?
Nothing the product needs. Outbound paths exist only where you create them: a cloud directory connector, an email provider, Azure Key Vault, or AI assistance. AI assistance is off by default, requires the Enterprise switch and a signed data agreement that lists exactly what is sent, uses your own provider key, and audits every request.
Can an administrator cover their tracks?
Not quietly. Admin, object, vault and group audit tables are append-only and hash-chained; verification reports the first broken link. Events forward in near real time to a SIEM the administrator does not control. Operator overrides on approvals are recorded as overrides, with who and when.
How is separation of duties enforced?
Permissions are named per feature area and roles carry only what they need. The person a workflow runs for can never approve it, even as an operator. High-impact groups need a second administrator decision. A vault-only role checks out credentials and does nothing else.
What code runs on our servers?
Release installers are Authenticode-signed and ship with a CycloneDX SBOM. The transform engine is a sandboxed expression language with no arbitrary code execution. Custom workflow steps load only as signed packages from publishers you allow-list; the PowerShell step is one such package and runs scripts from a folder you control under a stored credential.
How do we recover, and what about key escrow?
Everything durable is in your SQL Server, backed up with your own tooling. DPAPI secrets deliberately do not travel between hosts; on a rebuilt server you re-enter them, or use Key Vault or HashiCorp Vault so secrets follow the deployment. An active/passive topology is documented; active-active is not supported and the site says so.
Privacy and regulatory obligations?
Subject-access export and right-to-erasure endpoints leave a chained audit marker. Attributes carry a sensitivity classification. Retention windows are yours to set. Transparent Data Encryption and connection encryption are covered by a customer-side runbook, and SOC 2 and ISO 27001 control mappings sit inside the audit, TDE, erasure and sensitivity runbooks.
Agent identity, tenet by tenet
NIST proposed ten design tenets for agent identity management. Our one-page brief maps each tenet to IdentityMesh as it stands today: four available now, three covered in part, and three on the roadmap.
Have Security Questions?
Our team is ready to discuss your requirements and answer any questions about our security posture.