This is a post I’ve been waiting almost two years to write, and it tells the story of how BastionZero was born and became the successful zero-trust startup it is today. BastionZero is a pandemic baby. We started out as a blockchain company and then pivoted into infrastructure cybersecurity right after COVID hit, calling on everything we knew about resilience and bringing a needed product to market.
The story is this.
The Beginning
It was March 2020. We were a group of cryptographers and blockchain engineers building Arwen, a platform for high-value trades of Bitcoin to Ethereum, US dollars, and other cryptocurrencies, and going to market via partnerships with other blockchain companies. Behind Arwen was a protocol we designed that uses multiple parties to co-sign on every trade (“multisigs”), to reduce the risk that one party could steal funds from another party.
But for months, I’d been privately fantasizing about finding a way to make our technology more generic. The blockchain market was so young and idiosyncratic, and every partnership came with its own idiosyncratic build requirements. There weren’t that many blockchain companies in existence back then. So things were not repeatable. I wanted repeatable sales. Or rather, I wanted to build a product that lots of people wanted.
Actually, what I really wanted to do was to pivot our startup out of the confines of the blockchain industry and build something that we could sell to any tech company, not just to other blockchain companies. But this was my own private fantasy.
Then, at 6 am on March 9, I got a call from our building manager that there had been a case of COVID in our building in downtown Boston. Within the space of one week, I had transitioned from a CEO who insisted on everyone coming into the office to work (so we could “collaborate”), to an enthusiastic champion of remote work.
A week went by and our investors started calling emergency meetings with all of their portfolio companies. Soon enough, our customers were calling meetings with us.
By mid-April we basically had no more customers.
.png)
The Pivot
So, there we were. We had $3m in the bank from a very recent fundraise, and no business.
It was April 2020. Everyone was pivoting; the world was changing. We had to pivot and demonstrate reslience too. But how?
I remember slicing through sourdough bread (really!) and thinking about what to do next. I envisioned a company that could sell in any vertical, not just to other blockchain companies. And how we could spend all our time talking to engineers rather than to financial services folks.
And when I finally put a voice to all these thoughts with my cofounder Ethan Heilman and a few of our advisors, it turned out that we were all thinking the same thing.
We kept talking and that April, we realized something very important. We were building a cloud-based platform to support the secure movement of millions of dollars in Bitcoin.
Our engineers needed access to the platform’s backend so that they could respond to incidents, look at logs, and fix things when they break. But what happened if an adversary used this remote access as a vector to infiltrate our cloud? How could we make sure that this remote access did not become a vector for attack, especially when blockchain companies are known to be constant targets?
Clearly, every blockchain company has a problem with remote access. But in fact, every tech company has a problem with remote access. There it was, our startup pivot.
We started doing some research, talking to engineering teams, and surveying the market.
And every minute of it sucked.
Startup Resilience and The Trough of Sorrow
My advice to other founders is as follows: If you’re going to tell your investors that you are planning a pivot to a new business, I suggest that you come to them with a business plan. Bonus points if you bring some proof points from the market, or maybe even a potential customer or two that has agreed to start working with you.
Yes, you should definitely do that. Sadly, however, this is not what we did.
What we did was say: Hey, we’re going to pivot here, out of blockchain and into cloud cybersecurity and remote access. So we’re going to need 3-4 months to figure out what exactly our product and business will be. So can you please give us some space until then?
So there we were, in this extremely high pressure situation at the start of a pandemic, talking to other engineering teams. We weren’t really staffed to do this. We didn’t have any product, sales, or marketing people. We had a group of talented engineers doing work they had no business doing. Like designing user interfaces and running customer discovery calls.
It all felt very uncertain. Nevertheless, we explored the market for VPNs, bastions, PAMs, and secure remote access.
We learned about zero trust. And we were confused about what it would mean to be a zero trust startup.
Today, zero trust means: Don’t trust your users with long-lived credentials. Do ask your users to authenticate each time they want to access a new resource.
Today, zero trust doesn’t mean you are trusting zero things. In fact, you are trusting one big thing — the authentication system. In other words, the security of zero-trust systems is completely tied to the security of the system that is being used to authenticate users. In most cases, this authentication system is usually an SSO provider, or a certificate authority, or both. And so the authentication system is a single point of compromise.
On one hand, we were surprised that this was the state of the art.
We had just come out of the blockchain world, where “centralization” is a bad word. Single points of compromise were something to be feared, and for good reason. Blockchain companies that have single points of compromise very quickly get hacked. That was the whole point of the protocol behind Arwen.
On the other hand, we thought “Well, this makes sense, because our threat model is probably too aggressive and most of this industry isn’t ready to care about it yet.”
The Bet: A New Type of Zero Trust Startup
Nevertheless, we had this idea. We would build a protocol that would provide zero-trust remote access, without basing it on an authentication system that would be a single point of compromise.
We could do this using two cryptographic techniques from the blockchain world — multisigs (requiring multiple independent parties to sign off on an action) and ephemeral self-custody (having users store their own short-lived secret keys). Even in 2020, this was tablestakes in the blockchain world. But these ideas were revolutionary for a cloud security company.
At first, we were pretty sure no one would care. But then we realized something.
Most DevOps teams would love to have their remote access tool operate as aSaaS service. That way, they don’t have to patch or maintain it. However, giving a third-party SaaS root access into all of your infrastructure is pretty terrifying. What if the SaaS gets hacked?
This is where our cryptography could help — we could offer zero-trust remote access in a SaaS, while eliminating the risk that a compromise of our SaaS would lead to a compromise of our customers' infrastructure.
How?
FIrst, we would use multisigs. We would have both our SaaS, and another independent root-of-trust (the customer’s SSO provider) sign off on a connection. That way, if only one of them was hacked, the attacker could not connect to infrastructure targets, and security would be maintained.
Second, we would use self-custody. The user would hold her own ephemeral secret key that she chose freshly each time she logged into the service; that key would be certified by both our SaaS and the customer’s SSO provider. The secret key would be used to sign every message the user sent to an infrastructure target. That way, we could send those messages through our SaaS for a policy check, for monitoring and for logging, without creating risks that our SaaS could alter the message. In other words, even if our SaaS is hacked, it can’t alter or inject messages sent to our customers' infrastructure targets, because it doesn’t know the secret signing key. Finally, the secret key is short-lived, so if the attacker steals it, there isn’t much she can do with it.
So that was the plan. We told our investors we were going for it. Imagine me on a Zoom call with every single shareholder in the company, telling them about a semi-complete plan that none of us were sure would really work. But it was the best we could come up with in the space of three months. At the end of the call, there was a consensus that we could go ahead. Huge sigh of relief and a sense of resilience.
In August 2020, we started building and demoing BastionZero.
One amazing thing happened, which is that Mike Milano, who had been consulting for us since May 2020, decided to join our team full time. Mike had been a CTO at Cisco and SVP of Product and Engineering at iboss. His recent roles provided him with visibility into the issues customers were facing, trying to roll out zero-trust technologies. Mike had spent years building cloud security and zero-trust products, and he immediately understood the value of our security model.
But we were still a team of all engineers. And we still didn’t really know what we were doing when it came to sales and marketing as a zero-trust startup. We tried to explain to companies that had not yet transitioned to a zero-trust security posture, that actually we didn’t think the traditional notion of “zero-trust” was going to be good enough for them. They liked the idea of a replacement for their VPNs, SSH keys, and bastion hosts, but they didn’t really understand why our security model was important.
Prospects just weren’t getting it. It was the last three months of 2020. It was dark, cold and the world felt very unstable.
Light at the End of the Startup Pivot Tunnel
Then, in December 2020, SolarWinds happened. An SSO system was hacked as a way to get access to a victim organization’s entire infrastructure. The types of hacks we had only seen happen in the blockchain space were now happening in the infrastructure space. Ransomware attacks kept on happening, often using remote access (VPN, SSH, RDP) as their main vector for infiltrating their victims.
Cloud security and DevOps teams started to understand what we were talking about.
By April 2021, one year after we started our pivot, we had several teams using our product in production. We started growing. We finally added sales and marketing folks to our team of engineers. Our team is now 15 people, which still seems incredible to me.
Coming Full Circle
In late 2021, something else changed. Engineering teams that had previously been in a hiring freeze all started growing. Onboarding and offboarding engineers became a common chore for DevOps and cloud security teams. And doing that the old way (manually, with SSH keys or IAM roles) became more and more problematic. People wanted an easier way. BastionZero provided that easier way.
We started to find a niche with fast growing engineering teams that care about security.
And guess what industry has lots of fast growing engineering teams that really care about security? That would be the b̶l̶o̶c̶k̶c̶h̶a̶i̶n̶ ̶i̶n̶d̶u̶s̶t̶r̶y̶ web3. And so, while we work with other verticals too, we seem to have come full circle.
But this is only the beginning of our journey. In the cloud security industry, “zero-trust” still basically means “put all your trust in your authentication system”, which is a single point of compromise. We’re ready to change all that and introduce the world to a true zero trust access. Follow us and watch how we do it.
See BastionZero in Action
BastionZero connects teams to resources and requires no additional infrastructure to deploy or manage. It is the first—and only—cloud-native solution for trustless access providing multi-root authentication while maintaining zero entitlements to your systems.
With BastionZero, you can reclaim your architecture from over-privileged third parties and ensure that the right people have access to the right resources at just the right time—every time.
Schedule a demo now to see how you can trust less and access more with BastionZero.
