Platform Security & Trust Architecture

QC NetCore is engineered as mission-critical infrastructure for Internet Service Providers. Our security posture combines cloud-native authentication, database-level tenant isolation, encrypted transport, and strict separation between public demonstration environments and live production tenants.

Access to the QC NetCore operator console is protected by token-based authentication (Supabase Auth with JWT session validation via Next.js Middleware) and Role-Based Access Control (`admin`, `operator`, `technician`, `billing`).

At the persistence layer, PostgreSQL Row-Level Security (RLS) policies verify the user's `organization_id` on every `SELECT`, `INSERT`, `UPDATE`, and `DELETE` operation.

Provisioning communications between QC NetCore and tenant MikroTik routers are designed to use encrypted VPN tunnels (such as WireGuard), restricted API service ports, and dedicated least-privilege RouterOS API credentials rather than exposing unencrypted management interfaces to the public internet.

ISP Operators are strongly advised to disable unused RouterOS services (such as public Telnet, FTP, and unencrypted HTTP) and rotate RADIUS shared secrets regularly.

QC NetCore never prompts for, transmits, or stores customer M-Pesa PINs on our servers. During an M-Pesa STK Push transaction, PIN entry occurs exclusively on the subscriber's own mobile device via Safaricom's SIM Toolkit prompt. QC NetCore records only the resulting transaction reference, amount, payer phone number, and settlement status for accounting and session provisioning.

All interactive evaluations performed in Demo Mode (including the Captive Portal Customizer and Free Tools) run in an isolated client-side sandbox backed by browser `localStorage` and read-only demonstration fixtures. Public demo interactions cannot read or modify any live ISP tenant data.