Your core business data, encrypted twice — with primitives that a quantum computer does not break.
Organizations run their most sensitive processes on Dexon BPM: tax enforcement, medical claims, credit approval, citizen records. This page describes how that data is protected, in the language a security team uses for a third-party assessment.
Encryption in transit
Two layers, not one
TLS protects the channel. But TLS is terminated — at load balancers, corporate proxies, inspection appliances. Dexon BPM adds a second layer that survives that termination.
Layer 1 — TLS 1.3
HTTPS only, on every endpoint: the API rejects traffic without TLS. TLS 1.3 is preferred, with the minimum version enforced by policy on every endpoint and verified at each deployment, and HSTS.
Layer 2 — application-level AES-256 →
Every request and response body between the browser and the API is additionally encrypted with AES-256, under keys derived per session with PBKDF2 and SHA-512, with fresh random material per message. Every message is also cryptographically authenticated and verified before it is decrypted: an altered or forged message is rejected, never processed. Where TLS is inspected, the inspector sees the envelope, not the business data.
Before login, too
Credentials and the session token itself never travel in the clear — not even inside TLS. The pre-authentication exchange is encrypted under a credential of each integration consumer, generated by the customer's own administrator and revocable without affecting the others — Dexon does not hold those secrets.
Encryption at rest
Column-level, inside the database
On top of the platform encryption of the hosting (transparent data encryption and storage encryption on Azure, or whatever the client runs on-premises), Dexon BPM encrypts designated categories of data with AES-256 at the column level: platform configuration, integration credentials, and the business fields the client or the product classify as confidential — including the event log of every case.
An actor with read-only access to the database — a DBA, an exfiltrated backup, a copied disk — does not obtain those contents in the clear. Data encryption keys are not stored next to the data. And integrity is protected as well as confidentiality: every encrypted value and every stored document carries cryptographic authentication, so altered or forged data is rejected before it is processed.
Software supply chain
Signed code, managed dependencies
Quantum resistance
What "quantum-resistant" means here — precisely
The relevant threat today is harvest now, decrypt later: capture encrypted traffic or backups now, decrypt them when a cryptographically relevant quantum computer exists. What such a computer breaks (Shor's algorithm) is classical asymmetric cryptography — RSA, elliptic curves. What it does not break in any practical sense are the symmetric primitives: Grover's algorithm reduces AES-256 to roughly 128 bits of post-quantum strength, still infeasible, and SHA-512 keeps ample margins.
Both of Dexon BPM's own encryption layers — the application-layer encryption of payloads and the column-level encryption at rest — use exclusively symmetric primitives: AES-256, SHA-512, PBKDF2, the ones NSA's CNSA 2.0 retains as quantum-resistant. Their keys are derived from shared secrets and never travel through an asymmetric key exchange. Business data captured today in those layers is therefore not exposed to a future quantum decryption.
Dexon BPM provides quantum-resistant confidentiality of business data in transit and at rest, through its own encryption layers — which use only symmetric primitives aligned with CNSA 2.0.
Identity and isolation
The platform lives in your tenant, not in ours
SSO with Microsoft Entra ID
The app registration is created and governed by the client's own administrator, in the client's tenant. Your MFA, conditional access, sign-in risk and revocation policies apply in full. Dexon holds no credentials of your tenant.
Hardened local access
Local accounts get a strong password policy — 12 characters or more with complexity, rejecting common passwords and any that contain the username, with a forced change at sign-in — whose minimum length rises to match your own policy; salted, irreversible hashing; a built-in TOTP second factor; an anti-bot challenge at every sign-in; rate-limited sign-in attempts with every failure logged; one session per user; and an inactivity timeout that warns in advance and extends in one click.
Deny by default →
Every screen and every API function requires an explicit permission of the user's profile; what is not granted is neither shown nor executed, and a revoked permission takes effect immediately. Each document adds its own rule — assigned technician, author, access level. Single-use links sent by email open only their own record, and file links expire. Data access can be scoped by company, category or group, evaluated on the server, with a trace of each block.
One client, one database →
In the SaaS model each client receives a dedicated pair of applications and its own database. Isolation does not depend on a tenant discriminator in shared tables. On-premises, Dexon has no standing access.
Integrations with minimum scope →
Microsoft 365 mail over Microsoft Graph with modern app-only authentication, ready for the EWS retirement, with access scoped to the service-desk mailboxes — through RBAC for Applications, with no tenant-wide mail permission — and verifiable by your security team. Outgoing mail signed with the organisation’s certificate and encrypted for each recipient (S/MIME). Single-tenant Teams bot under your own identity, available from November 2026. Signed webhooks.
An audit trail your SIEM can read →
Security events — successful and rejected sign-ins with their cause, functions not granted, password changes — and the platform’s audit tables are streamed to your SIEM as structured CEF or JSON records, over syslog or to a file — ready for Microsoft Sentinel, Splunk, QRadar or ArcSight — with no passwords, tokens or recipient addresses. In the platform, a single query audits each user — sessions, changes, documents opened, remote control and reads of sensitive records — under its own permission, separate from administration; critical records keep every version with its before and after values.
Documents encrypted before they leave →
In Azure Blob Storage, documents are compressed and encrypted by the application — AES-256 with HMAC-SHA512 authentication and a key of each deployment — so neither the file name nor its content is readable in the storage account, and each environment uses its own container with access scoped to it. Documents kept on the server's own disk are sealed with the same envelope, and older files are resealed in the background, each copy verified before it replaces the original.
AI agents under your permissions →
Agents discover the platform’s tools with their schema; every argument is validated, each tool requires the same permission as the screen behind it, and every call — rejected ones included — is audited. Microsoft 365 Copilot, Claude or your own agents connect over MCP under each person’s own Entra ID identity, never a service account.
Validation
Test it yourself
Dexon provides a security validation framework aligned with OWASP Top 10:2025, OWASP API Security Top 10:2023, ASVS 5.0 and WSTG, with a NIST SP 800-115 process and mapping to NIST SP 800-53 Rev. 5 and CSF 2.0 — including an actionable checklist and an active pentest plan. Clients run authorised tests under rules of engagement, with test credentials and a staging environment.
Findings from client-contracted penetration tests are managed with CVSS severity and prioritised remediation. Third-party security questionnaires — SIG, CAIQ, your own — are answered under NDA.
What is certified is the platform's process maturity: PinkVERIFY across 12 ITSM processes.
Ask for the document your security team will want
The full security posture — architecture, cryptographic summary, integration controls and the NIST CSF 2.0 mapping — is available under NDA. Write to security@dexon.us, or bring your questionnaire.