Most MSPs buy their security stack off the shelf. We built ours, and we've been publishing the architecture as Independent Stream research through the IETF. All five are in active production use internally — the public drafts are the simplified version of what's actually running.

1. Invariant-Closed System Design (ICSD) — draft-dpa-icsd

The core principle behind everything we build for compliance-critical clients: instead of detecting and remediating invalid or non-compliant states after they happen, ICSD constrains the system so invalid states can't be represented at all. For payroll, tax, financial reporting, and regulated infrastructure, this means compliance isn't a checklist bolted on afterward — it's structurally guaranteed by the data model itself.

2. Universal Zero-Port Interconnect Framework (UZPIF) — draft-dpa-uzpif-framework

A post-port networking model. Endpoints never open a publicly reachable listening port — instead they establish outbound, identity-bound sessions to Rendezvous Nodes. No open port means no port for an attacker or a scanner to find in the first place. This is the foundation of the "reduced attack surface" work we roll into managed infrastructure.

3. Universal Zero-Port Transport Protocol (UZP) — draft-dpa-uzp-transport

The transport layer under UZPIF. Identity-addressed, encrypted by default, with a handshake built on modern and post-quantum-capable primitives. Rendezvous Nodes stitch flows together but never terminate the end-to-end encryption or hold long-term secrets — so no single intermediary is a point of compromise.

4. TLS-DPA — draft-dpa-tls-dpa

A TLS 1.3-inspired handshake generalized to work where IP:port semantics don't apply. Authentication binds to Service Identities instead of network coordinates, metadata exposure to intermediaries is reduced, and it includes a hybrid-KEM post-quantum transition path — so clients aren't stuck re-architecting when PQC becomes mandatory.

5. Outbound Indexing — draft-dpa-uzpif-outbound-indexing

An opt-in alternative to traditional inbound crawling (the Robots Exclusion Protocol model). Servers proactively initiate authenticated outbound connections to trusted indexers — search engines or AI systems — with explicit consent grants for indexing and content usage. Less unsolicited crawling, better signal quality, and consent baked in at the protocol level rather than an honor-system text file.

Why this matters if you're evaluating us as an MSP: the same GDPR/compliance discipline we bring to backup audits (see our earlier post) is the same discipline behind this stack — invalid or non-compliant states get engineered out, not caught after the fact. Happy to go deeper on any of these in the comments.

We recently took over IT support for a UK insolvency firm — one of the highest-risk industries for data handling, since they're sitting on financial records, creditor data, and sensitive case files for companies going under.

The single biggest gap we find when auditing a new client's setup isn't lack of backups. It's this:

Backups exist, but nobody has ever tested a restore.

A backup you haven't restored isn't a backup — it's a hope. Here's the checklist we run on every new MSP client in week one:

1. 3-2-1 rule minimum — 3 copies of data, 2 different media types, 1 off-site (ideally a different cloud region/provider than your primary host).

2. Restore drills quarterly — pick a random file or VM snapshot and actually restore it. If your team has never done this, you don't have a backup strategy, you have a backup folder.

3. Access logging on the backup store itself — who can delete backups? If the answer is "the same admin account that runs production," that's a single point of failure a ransomware attack will exploit.

4. Retention aligned to legal requirement, not convenience — insolvency/financial data often needs 6+ years retention. Most default SaaS backup tools cap at 30-90 days.

5. Documented RTO/RPO — if you can't tell a regulator or insurer your Recovery Time Objective and Recovery Point Objective in minutes, you don't have a disaster recovery plan, you have an assumption.

On the custom software side, we also just wrapped a from-scratch build: live competition scoring software for gymnastics events, handling real-time score aggregation across multiple judging panels. Different world from MSP work, but same underlying principle — the system has to be correct and available under pressure, because there's no "we'll fix it after the event."

Happy to answer questions on GDPR/backup audits or bespoke builds in the comments.