Enterprise Security & SSO
Security Built for
Regulated Data.
Not Bolted On.
DNXT Publisher Suite is engineered from the ground up for pharma's most sensitive data environments — with database-level tenant isolation, Azure AD and Okta SSO, immutable 21 CFR Part 11 audit trails, and GxP/CSV-ready architecture that passes enterprise IT security reviews on first submission.
& Okta
CSV Ready
Who This Is Built For
DNXT's enterprise security architecture solves the specific compliance, procurement, and operational challenges faced by three distinct functions in regulated life sciences organizations.
Director of IT Security / CIO
Every vendor procurement review turns into a six-month ordeal when the platform can't demonstrate database-level tenant isolation, lacks a documented CSRF/XSS mitigation policy, or runs SSO through a brittle SAML integration that requires professional services to reconfigure whenever the company switches identity providers. Competing platforms fail security questionnaires because their multi-tenancy is implemented with application-layer row filters — a configuration that an auditor immediately flags as insufficient for HIPAA and GxP data environments. Justifying approval to the CISO means producing evidence that isn't in anyone's documentation.
- DNXT passes enterprise security reviews that eliminate procurement delays lasting 3–6 months
- Database-level tenant isolation satisfies InfoSec's requirement for cryptographic-strength data segregation
- Dynamic SSO configuration means no redeployment when the company migrates from Okta to Azure AD
- Full security questionnaire documentation is provided — no custom discovery required
VP Quality / CSV Lead
Computer System Validation for a regulatory publishing platform typically takes 4–6 months and $200K+ in consulting fees when the vendor hasn't pre-built the IQ/OQ/PQ documentation framework against GAMP 5. Most platforms deliver a system that someone competent built to be useful — but not one built to be validated. That means your CSV team is reverse-engineering what the system does, writing risk assessments from scratch, and trying to map application behaviors to 21 CFR Part 11 requirements that the development team never thought about. And if the audit trail doesn't capture electronic signature events with cryptographically bound timestamps, you're starting that validation effort over.
- GAMP 5-aligned architecture with pre-built IQ/OQ/PQ documentation templates cuts validation time by months
- 21 CFR Part 11 audit trail captures every document action with user, timestamp, IP, and action type — immutably
- Electronic signature events are cryptographically bound and tamper-evident
- Eliminates reliance on external CSV consultants for standard compliance scenarios
VP Regulatory Operations
FDA inspections don't give you time to reconstruct who approved what and when. If your regulatory publishing platform can't produce a complete, time-ordered, user-attributed record of every document action — every check-in, approval, submission, and modification — inspectors will ask questions your team can't answer from memory. Worse, most platforms store audit logs in mutable database tables: a sophisticated attacker, a compromised admin account, or even a misconfigured database migration can silently alter historical records. That's not a hypothetical risk in an FDA 483 context; it's an observation waiting to happen.
- Single platform you can reference in an FDA inspection — every document action traceable to user, time, and IP
- Immutable audit records stored outside of application-layer reach — cannot be altered by admin accounts
- RBAC ensures that only credentialed users can approve, submit, or modify regulated documents
- Compliance officers can generate a complete audit report for any document or submission in under two minutes
How It Works
From the moment a user attempts to authenticate to the moment a document action is permanently recorded, every layer of DNXT's security architecture operates deterministically — with no configuration gaps and no assumptions about trust.
User Authentication via Dynamically Configured SSO Provider
When a user navigates to DNXT, the platform resolves the tenant context from the subdomain or organization token, then loads the identity provider configuration stored for that tenant — Azure AD, Okta, LDAP, or API key — without requiring any code change or redeployment. The authentication handshake is executed against that provider using SAML 2.0 or OIDC as appropriate, and the provider's signed assertion is verified server-side before any session is established. This dynamic configuration architecture means a company can migrate from Okta to Azure AD — or support multiple IdPs simultaneously for different user classes — in a matter of minutes through the admin console.
Tenant Context is Cryptographically Bound to Every Session Token
Once authentication succeeds, DNXT issues a session token that encodes the tenant identifier as a signed, tamper-evident claim — not a cookie value that can be manually modified. Every subsequent API request presents this token, and the server validates the tenant claim before resolving any database connection. This means that even a fully authenticated user from Tenant A cannot issue a request that touches Tenant B's data layer, because the token itself cannot be forged to carry a different tenant claim without the signing key. Session expiry, rotation, and revocation are all enforced server-side.
Database-Layer Tenant Isolation Routes Queries to Physically Separate Schemas
DNXT's multi-tenancy is not implemented with WHERE clauses or application-layer row filters — a pattern that fails enterprise security reviews because a single ORM misconfiguration or query injection could bypass the filter entirely. Instead, each tenant is provisioned with a separate database schema, and the connection pool is dynamically resolved to the correct schema based on the cryptographically validated tenant context from the session token. This approach means that even a catastrophic application bug cannot result in cross-tenant data exposure, because the underlying database connection never has visibility into another tenant's schema. Data at rest within each schema is encrypted using AES-256 with tenant-specific key material.
Role-Based Access Control Evaluated Before Every Resource Operation
Every API endpoint in DNXT is decorated with a required permission scope, and the RBAC engine evaluates the authenticated user's role against that scope before the underlying business logic executes — not after. Roles are defined at both the platform level (e.g., Submission Author, Regulatory Approver, Read-Only Reviewer) and the document level, allowing fine-grained access without requiring separate deployment environments. When a user's role is modified — for example, when they change teams or leave the organization — the change propagates to active sessions within the session token's TTL, and immediate revocation can be triggered via the admin console without redeploying the application.
CSRF and XSS Mitigations Applied at the Framework Layer, Not the Application Layer
CSRF tokens are issued per-session and per-request using the synchronizer token pattern, validated server-side before any state-changing operation is processed. Content Security Policy headers are enforced at the response layer to prevent XSS payloads from executing in the browser context, with a strict CSP directive that disallows inline scripts and restricts external resource loading to whitelisted origins. Input sanitization is applied to all user-supplied data before persistence, using a context-aware encoding library that handles HTML, URL, and JavaScript contexts separately — preventing the class of second-order injection vulnerabilities that simpler sanitization approaches miss.
Every User Action Written to an Immutable, Append-Only Audit Log
Every document action — view, edit, approve, submit, download, delete, permission change — is written synchronously to an append-only audit log that sits outside the primary application database and is inaccessible to application-layer write operations. Each log entry captures the user identity, tenant, timestamp (UTC with millisecond precision), source IP address, action type, target object, and a cryptographic hash of the previous log entry — forming a tamper-evident chain that can be algorithmically verified. This architecture directly satisfies 21 CFR Part 11 §11.10(e), which requires accurate and complete audit trails of document operations, and the immutability guarantee means that a compromised admin account cannot retroactively alter the historical record.
GxP/CSV Documentation Package Delivered Alongside the Platform
DNXT ships with a pre-built Computer System Validation documentation package aligned to GAMP 5 Category 4 software classification — including the User Requirements Specification, Functional Specification, Risk Assessment, and IQ/OQ/PQ test script templates. This package is maintained and versioned in parallel with each platform release, so your CSV team is validating against documentation that matches the deployed software, not a prior version. The result is that a qualified QA team can complete system validation for a standard deployment in weeks rather than months, without engaging external CSV consultants for every configuration scenario.
Enterprise Security, Every Layer
Six interlocking security capabilities designed specifically for GxP-regulated environments — each one independently meaningful, collectively comprehensive.
Azure AD & Okta SSO
DNXT supports SAML 2.0 and OIDC-based SSO with Azure Active Directory and Okta through a dynamically configurable provider model — meaning an organization can change, add, or switch identity providers through the admin console without any code deployment or vendor involvement. This matters in regulatory environments because IdP migrations are common during M&A activity, and a platform that requires redeployment to switch providers creates an unplanned validation event. Provisioning flows are supported via SCIM 2.0, so user onboarding and deprovisioning are automated from the identity provider's directory — eliminating the risk of orphaned accounts that retain access to regulated systems after an employee departs.
LDAP / Active Directory Integration
For organizations that operate on-premise Active Directory infrastructure or hybrid environments where cloud IdP migration is not yet complete, DNXT provides native LDAP integration with support for both simple bind and SASL authentication mechanisms. Group membership in AD is synchronized to DNXT roles on a configurable schedule, ensuring that organizational restructuring — such as a regulatory team reassignment — is reflected in platform permissions within hours, not weeks. This capability is critical for CROs managing multiple sponsor clients under separate AD forests: DNXT can maintain distinct directory integrations per tenant, ensuring that cross-client access is architecturally impossible even when the underlying organizational structure is complex.
Role-Based Access Control (RBAC)
DNXT's RBAC model is built around the principle of least-privilege access, with predefined roles for common regulatory functions — Submission Author, Document Approver, Regulatory Reviewer, Read-Only Auditor, System Administrator — and a custom role builder for organizations with non-standard workflows. Permissions are evaluated at the API layer before business logic executes, preventing any pathway to data access that bypasses the authorization check. For 21 CFR Part 11 compliance, electronic signature permissions are separately governed: a user cannot electronically approve a document unless explicitly assigned the Approver role for that document type, ensuring that approval authority is always deliberate and documented.
Multi-Tenant Database Isolation
Unlike platforms that implement multi-tenancy through row-level security policies or application-layer WHERE clauses — both of which can be bypassed by query injection or ORM misconfiguration — DNXT isolates each tenant at the database schema level, with separate connection pools resolved from cryptographically validated session context. This means that a data breach affecting one tenant's credentials cannot expose another tenant's data, because the attacker's session token physically cannot resolve a connection to a different schema. AES-256 encryption at rest with tenant-specific key material means that even database-level compromise of one tenant's storage cannot be leveraged to decrypt another tenant's data, satisfying the most stringent enterprise security requirements for co-hosted regulated data.
21 CFR Part 11 Compliance
DNXT's 21 CFR Part 11 implementation addresses both the electronic records requirements of §11.10 and the electronic signature requirements of §11.50 and §11.70. Audit trails are append-only, tamper-evident, and stored independently from the application database — satisfying §11.10(e) without reliance on application-layer access controls. Electronic signatures are cryptographically linked to the specific document version being signed and cannot be detached or reapplied to a different version. The platform supports multi-factor authentication for signature events where organizational policy requires it, and signature manifests include the meaning of the signature (approval, review, authorship) as required by §11.50(a)(2). All of this is delivered as a standard platform capability — not a paid add-on or custom implementation.
Complete, Immutable Audit Trail
The DNXT audit trail captures every user-initiated and system-initiated action — document creation, modification, approval, submission, download, permission change, and login event — with user identity, source IP address, UTC timestamp with millisecond resolution, and action-specific metadata. Log entries are chained using cryptographic hashes, forming a verifiable sequence where any retroactive modification to a historical record is algorithmically detectable. For FDA inspection scenarios, compliance officers can generate a formatted audit report for any document, submission, or user account in under two minutes, covering the complete lifecycle of the object from creation to current state — without depending on a DBA to construct a custom query against raw database tables.
DNXT vs The Alternative
Competing platforms were not designed for GxP-regulated environments from the start. Here's what that means in practice when your security team runs a procurement review.
| Security Capability | Veeva Vault RIM | LORENZ docuBridge / EXTEDO | DNXT Publisher Suite |
|---|---|---|---|
| SSO Provider Configuration | ⚠ Partial — Vault supports SSO but IdP changes require Veeva professional services engagement and can take 4–8 weeks to configure and re-validate in a managed environment. | ✗ Limited — EXTEDO and LORENZ are primarily desktop-installed or on-premise tools with minimal cloud SSO capability; Azure AD/Okta integration is either absent or requires third-party middleware. | ✓ Dynamic — Tenant admins configure and switch SSO providers (Azure AD, Okta, LDAP) through the console with zero downtime and no redeployment. |
| Multi-Tenant Data Isolation | ⚠ Application-layer — Veeva Vault implements tenant separation at the application layer. Vault's shared infrastructure model means tenant data co-exists in shared storage with access governed by application logic, not physical schema separation — a pattern that fails strict enterprise InfoSec requirements at some organizations. | ✗ Not applicable — On-premise deployments are inherently single-tenant, which avoids the problem but also prevents cloud delivery and creates a separate set of infrastructure management risks. | ✓ Database-layer — Physically separate schemas with isolated connection pools per tenant. Cross-tenant data exposure is architecturally impossible, not just application-policy enforced. |
| 21 CFR Part 11 Audit Trail | ⚠ Configurable — Vault provides audit trail functionality, but completeness depends on configuration, and audit data is stored in the same Vault database that administrators can access. Immutability guarantees depend on Veeva's managed infrastructure commitments, not a verifiable cryptographic chain. | ⚠ Document-level only — LORENZ and EXTEDO audit trails typically capture document submission events but not granular intra-application user actions (e.g., individual file views, permission changes, failed authentication attempts) needed for a thorough FDA Part 11 audit. | ✓ Immutable chain — Cryptographically chained, append-only log outside application database reach. Every action captured — including views, failed logins, and admin changes — with tamper detection. |
| GxP/CSV Validation Package | ⚠ Available at cost — Veeva offers CSV support but it is typically delivered as a professional services engagement billed separately, and documentation must be customized to each Vault configuration — which varies between customers. | ✗ Customer-authored — Validation documentation is largely the customer's responsibility. LORENZ and EXTEDO do not ship a GAMP 5-aligned IQ/OQ/PQ package; customers must engage CSV consultants to produce validation
|
