Sign inTalk to specialists

Security Overview

A public, honest description of NEXEFII platform security controls: authentication, per-organization isolation, session security, headers and transport.

Version
2026.3
Last updated
2026-07-23

Scope

This overview covers the NEXEFII application and its directly operated modules, including NEXE Store, Master Control and the Smartbot assistant, to the extent they are part of the same platform.

It does not describe the security posture of third-party systems, of integrations contracted by customers, or of environments outside NEXEFII's direct control. External processors, such as the payment processor, are governed by their own terms and controls.

Authentication and access control

The platform offers multi-factor authentication (MFA) and uses role-based access control (RBAC). The available organization roles are owner, admin, manager, member and viewer, with permissions differentiated by role.

Access decisions are evaluated restrictively (fail-closed): invalid or insufficient configuration results in denial, not in silent grant.

Cross-organization isolation (multi-tenant)

The platform is multi-tenant and data is scoped per organization (tenant). The design intent is that one organization's data is not accessible by another.

This isolation is a core architectural control, applied consistently to the read and write operations of the modules.

Session security

Sessions have an idle timeout (approximately 45 minutes), with prior warning and a countdown before termination, alongside an absolute session lifetime (approximately 24 hours).

There is synchronization across browser tabs and the ability to revoke sessions server-side, allowing access to be centrally ended when necessary.

Cookies, transport and security headers

Authentication cookies are marked HttpOnly and Secure. Session tokens are signed with a single fixed algorithm, and weak configuration is rejected restrictively (fail-closed).

Traffic is protected in transit by TLS/HTTPS. Encryption of data at rest is not asserted here; data is hosted on managed cloud infrastructure and at-rest specifics are deferred to review.

Cross-origin resource sharing (CORS) is restricted to an explicit allowlist of origins. Security response headers are applied.

Prepared controls, not yet enforced

The Content-Security-Policy is currently in report-only mode: it monitors and reports, but is NOT yet enforced as a block. We state this honestly so as not to suggest a protection that is not yet in effect.

CSRF protections are prepared but not yet blanket-enforced. None of these prepared controls should be read as already active in blocking mode.

Auditing and continuous pipeline verification

Sensitive administrative actions are recorded in immutable audit trails, supporting traceability and accountability.

The development pipeline includes automated secret scanning and automated dependency vulnerability scanning, as part of ongoing security hygiene.

Limitations and what we do not claim

No system is perfectly secure. We do not claim absence of incidents, absolute security, unhackability, or any level of protection we cannot honestly support.

At this time we do not claim any compliance certification (for example, SOC 2, ISO 27001, PCI DSS). Any future certification will only be mentioned once actually obtained and verifiable.

Some security details are not disclosed publicly for security reasons.

Responsible disclosure

If you identify a possible security vulnerability, we ask that you report it responsibly, without exploitation beyond what is necessary to demonstrate it, through the security contact: contact@nexefii.com.

We are committed to reviewing reports received in good faith; formal handling and timelines are governed by our responsible disclosure policy.

Last reviewed

Last editorial review recorded on 2026-07-11. This overview is reviewed periodically and may be updated as controls evolve.

Support access posture

NEXEFII does not maintain permanent or standing access to any customer's environment. There is no login with the customer's shared credentials and no operator uses the customer's password. When remote support is required, access occurs only with the customer's explicit authorization.

Support access is designed to be nominative (tied to a named support user), temporary (with an expiration), scoped to the customer's tenant, least-privilege, read-only by default (with write only when necessary and authorized), protected by MFA, tied to a justification or ticket, revocable by the customer, and recorded in an audit trail (start, end, and relevant actions).

A just-in-time (JIT) provisioning mechanism, with temporary time-boxed elevation, is described only as a future improvement and is NOT yet implemented. Until then, access follows the nominative, transitional procedure carried out by the customer itself. Questions about the support access posture may be directed to contact@nexefii.com.