Security you can inspect.
We hold ourselves to the standard we set for clients. Here's how we protect your systems — and how we protect ours.
Six rules we don't bend.
Nothing exposed that needn't be
Management interfaces live on private overlay networks. Outbound-only connections mean no inbound ports for scanners to probe.
One identity, one secret, one vault
Unique strong credentials in a self-hosted password vault with MFA. No shared logins, no passwords in chat or email.
Least privilege
Scoped, read-only API tokens where possible; per-system backup credentials; standing personal keys retired in favour of automation identities.
Assume compromise
Append-only, encrypted, off-site backups and restore drills. If something is hit, history can't be erased.
Patch on a cadence
Scheduled, verified updates with automatic roll-back for critical services and a review of anything pending reboot.
Watch for silence
Alerts catch what breaks loudly; audits catch what fails quietly — dead collectors, stale backups, stopped containers.
The controls protecting technet.co.ke.
- HTTPS everywhere with HSTS, served from a global edge network.
- DNSSEC-signed domain (ECDSA P-256) to prevent DNS spoofing.
- Strict Content-Security-Policy — only our own scripts, styles and fonts run.
- No cookies, no trackers, no third-party scripts or fonts.
- Email authentication: SPF, DKIM, DMARC, MTA-STS and TLS-RPT published.
- Static site: no database or login form on the public site to attack.
- Clickjacking & sniffing protection: frame-ancestors none, nosniff, strict referrer policy.
- Published security.txt so researchers know where to report.
Found something? Tell us.
If you believe you've found a vulnerability in any TECHNET service, email admin@technet.co.ke with the details. Please don't access other people's data, degrade service, or publicly disclose before we've had a reasonable chance to fix it. We'll acknowledge your report promptly and keep you updated.
Our machine-readable policy is at /.well-known/security.txt.
Defence in depth