A crypto project I know (I will not name it, which is itself the point) had their Customer.io account terminated mid-campaign. No breach. No hack. No regulatory order. AUP clause 7.4: “high-risk financial services.” The campaign was for a token launch. The timing was the worst possible moment, which is always when these things happen. They had three days of silence on a list they had spent eighteen months building. The kill switch was in the contract from day one. They had clicked past it during signup and never looked again.
That is not a cautionary tale about Customer.io specifically. It is a cautionary tale about what SaaS actually is, which almost nobody in crypto describes correctly.
SaaS is not infrastructure. It is delegated authority, and the delegation is revocable.
Every managed layer in your stack (email delivery, auth, analytics, LLM inference, monitoring) is a permission slip your vendor holds on your behalf. For most industries, that is an acceptable tradeoff. For crypto builders operating in legal grey zones, under regulatory ambiguity, in markets that mainstream financial services providers have publicly categorized as “high-risk,” that permission slip has a specific expiration condition: the moment keeping you as a customer costs the vendor more than losing you does.
That moment arrives without warning, during the worst possible week, every time.
The security industry has a mature vocabulary for technical threats. CVEs get severity scores. Phishing gets simulation budgets. SQL injection gets a line in the OWASP Top Ten. Platform dependency risk (the probability that a vendor exercises their contractual right to end your company’s operations) gets a checkbox during signup. That asymmetry is the actual security failure, and it belongs on the threat register.
Here is what the typical crypto neobank stack looks like when you audit it honestly:
graph TD
subgraph STACK["The Sovereignty Audit"]
direction TB
E["📧 Email Delivery<br/>(SendGrid / Customer.io)"]
A["🔐 Auth / Identity<br/>(Auth0 / Clerk)"]
AN["📊 Analytics<br/>(Mixpanel / Amplitude)"]
L["🤖 LLM Inference<br/>(OpenAI API)"]
M["📡 Monitoring<br/>(Datadog)"]
end
subgraph AUDIT["Kill Switch Conditions & Blast Radius"]
direction TB
E --> E2["AUP: 'crypto / high-risk financial services'<br/>Blast Radius: 🔴 5/5, comms blackout at launch"]
A --> A2["AUP: 'regulated financial services'<br/>Blast Radius: 🔴 5/5, all users locked out"]
AN --> AN2["AUP: 'financial data / high-risk sectors'<br/>Blast Radius: 🟡 3/5, visibility gone, ops continue"]
L --> L2["AUP: 'financial advice / crypto / high-risk'<br/>Blast Radius: 🟠 4/5, product features collapse"]
M --> M2["AUP: broad 'acceptable use' discretion<br/>Blast Radius: 🟡 3/5, blind ops window"]
end
subgraph TIERS["Sovereignty Tiers"]
T1["TIER 1: OWN OUTRIGHT<br/>Identity, signing keys, anything irreconstructable"]
T2["TIER 2: SELF-HOST WITH HARDENING<br/>Email delivery, auth, internal analytics, sensitive LLM inference"]
T3["TIER 3: ACCEPTABLE DELEGATION<br/>Non-critical-path tools with clear AUP tolerance + documented exit plan"]
end
T1 --- T2 --- T3
style T1 fill:#1c1320,stroke:#ff5277,color:#ff8fa6,stroke-width:1.5px
style T2 fill:#1f1a12,stroke:#ffc24b,color:#ffd98a,stroke-width:1.5px
style T3 fill:#122019,stroke:#46e0c0,color:#8fede0,stroke-width:1.5px
The pattern the diagram forces you to see: the layers founders treat as commodities (email, auth) carry the highest blast radius scores and the vaguest kill conditions. The risk is inverted from how most people think about it. Auth0 going dark does not inconvenience you. It locks every user out of your product simultaneously, during whatever the worst possible moment happens to be.
I want to be direct about the tension here, because collapsing it into “self-host everything” would be dishonest and dangerous.
Misconfigured Postfix is not safer than Customer.io. A self-hosted Keycloak instance with weak key rotation is worse than Auth0 on its worst AUP-enforcement day. Self-hosting multiplies operational debt and demands real security discipline. If you do not have that discipline, outsourcing is not the mistake. Pretending you have sovereignty when you do not is the mistake.
The actual answer is more precise than either extreme: own the critical path, and know exactly what you are delegating, to whom, under what AUP conditions, and what happens to your company the day that delegation disappears.
That produces three tiers. Tier 1 is the short list of things you own outright: identity infrastructure, signing keys, anything that cannot be reconstructed if you lose it. No managed service touches Tier 1. Tier 2 is self-hosted with real hardening: email delivery, auth, internal analytics, LLM inference for anything touching sensitive customer data. You run these. You patch them. You rotate the keys. Tier 3 is the narrow set of tools where SaaS delegation is genuinely acceptable: non-critical-path, with a vendor AUP you have actually read against your use case, and a documented exit plan that is not “figure it out later.”
This is not paranoia. This is architecture.
There is a specific tension in writing this publicly that I want to name rather than smooth over.
Building in public (sharing your stack, your decisions, your reasoning) is part of what I do. It is also in direct tension with operating as a security professional. A blog post naming your auth provider, your monitoring stack, and your email infrastructure is a reconnaissance gift. The resolution I have landed on: share the philosophy and the framework. Never the implementation specifics. The threat model logic, the decision criteria, the tiered framework above are public because they help other builders think more clearly. The actual provider names, the IP ranges, the topology stay private. Transparency about how you think is not the same as handing someone a map of your attack surface.
The lived version of this: On a Tuesday three weeks ago I was doing grappling rounds at 7 AM in Bangkok and thinking about a Keycloak configuration I needed to harden before end of week. Those two things are not as separate as they sound. Both demand that you know exactly what you control and what controls you. In a round, that is position. In a stack, that is sovereignty. You cannot defend what you have not mapped.
The Customer.io story is not rare. It will happen to more crypto builders this year, mid-campaign, mid-audit, mid-raise. The vendors are not villains. They are companies managing their own risk. The mistake is not using them. The mistake is treating a revocable permission slip as if it were infrastructure.
God steers & I row. That means I do not hand the oars to a vendor whose incentives diverge from mine the moment my industry becomes inconvenient. 2 Timothy 1:7 gives you power and a sound mind. Using both means building like the platform can disappear tomorrow, because for crypto builders, it statistically will.
Audit your stack against this framework this week. One tier per layer. If you cannot name the kill switch condition on your auth provider’s AUP, you do not actually know what you are running.