Joe Siegrist and the trouble with the keys

A customer had a problem. Joe Siegrist offered to look at his computer. In March 2010, consultant Marc D Anderson described what happened after he complained about LastPass on Twitter: the company replied almost immediately, and within ten minutes its chief executive had emailed, offering to connect remotely and investigate. Over the following days, Siegrist sent new builds with fixes. Anderson ended up writing a recommendation of the service.

It is a modest episode for a founder’s biography. No launch stage, no ceremonial bell, no photograph of a cheque. A person was having trouble with software, and the person running the company helped repair it. Yet it gets close to the question that followed Siegrist through LastPass: how do you persuade somebody to let your software handle the keys to their life?

A password manager has an awkward introduction to make. Before it can remove a nuisance, it must invite scrutiny. Its users have good reasons to be suspicious. Siegrist’s early answer involved making himself available, sometimes at the level of a single malfunctioning machine. The relationship began with a bug report.

Four developers, one tiresome file

LastPass began in 2008 with four developers who already knew one another’s work. Siegrist had been chief technology officer at eStara, a business working in internet telephony and click-to-call services. Encryption was part of that world. The team brought experience from building an existing cloud business to a problem sitting much closer to home.

They were having trouble managing their own passwords. Their arrangement used an encrypted file, which required a small procession of chores whenever anything changed. Open it, retrieve the information, invent another password, update it, encrypt it again, keep copies in step. “It was a mess to do it right,” Siegrist recalled.

There is a particular embarrassment in being technically capable enough to understand a problem and still finding the solution exhausting. The file could protect information; maintaining the arrangement demanded repeated attention. LastPass grew from that gap between a sound intention and an ordinary working day.

Siegrist’s education included the University of Maryland, where he studied from 1994 to 1998. His later author biography credited him as a named inventor on five software patents. Those credentials help explain his technical background. The encrypted file explains the product’s appeal more economically. Even the people who knew how to do the job wanted fewer steps.

The difficulty of selling a locked box

The company’s proposition put a lot of weight on a distinction that is easy to lose in conversation. Passwords could travel through a cloud service while encryption and decryption happened locally. LastPass’s design aimed to give customers access across devices without giving the service their master password. Convenience and limits on the provider’s access were meant to coexist.

Explaining that arrangement became part of the founder’s job. Security commentator Steve Gibson later described how readily Siegrist answered his technical questions when he was evaluating LastPass. The willingness to explain mattered to Gibson, who wanted to understand the mechanism before recommending it. A reassuring adjective would have been considerably less useful than an answer.

In June 2015, Gibson still spoke of Siegrist as his technical contact, the person who could explain what had happened. That was a consequential connection for a young security product: an audience could hear an independent technically minded user ask questions, and the founder could answer them in public. Trust acquired a working procedure.

Being approachable also creates an obligation. Once a founder becomes the person customers expect to hear from, a quiet inbox carries a meaning of its own. The attention that helps establish a company becomes something its users remember when circumstances change.

A password company with an exit in mind

Siegrist described himself as a technical CEO. He helped with sales and marketing, while keeping his attention on the product and writing code when he could. The title had room in it for both a customer conversation and an implementation detail. That combination is visible in the way he talked about authentication.

By May 2014, LastPass had added support for the fingerprint sensor on Samsung’s Galaxy S5. Siegrist discussed earlier desktop fingerprint work and relationships with AuthenTec and Validity. A sensor on a phone presented another way to make access less laborious. He wanted the company ready when new devices made that possible.

“It’s not a coincidence that we’re named LastPass.”

Joe Siegrist, 2014

The name carried an aspiration beyond storing more passwords. He wanted to make the existing system workable while being ready to help move beyond it. There is a little professional comedy in building a business around a thing you would welcome seeing retired. For Siegrist, new authentication methods were part of the opportunity.

His public explanations often returned to familiar objects. Discussing password reuse in 2014, he compared it with using the same key for all the locks in someone’s life and handing that key around. The analogy made an abstract failure easy to picture. A product that depended on cryptography still needed language that worked outside an engineering meeting.

Virginia was only the starting point

LastPass’s geography widened while Siegrist was running it. In October 2013 the company announced a Paris office, saying that 60 percent of its users were already international. A service built in Virginia was being used well beyond its home market. The office followed the customers.

The person chosen to lead the operation, Thibaut Behaghel, had worked with Siegrist and the team at eStara. An earlier professional connection became useful in another company. It gives this chapter a more human scale than the usual language of international expansion: people who had worked together were doing so again.

The product also had to serve businesses. In 2013 Siegrist argued that organizations needed tools that made good password practices easier to follow, alongside central oversight. Telling employees to behave differently had limits if the daily process remained awkward. The founder’s own tiresome file had its organizational equivalents.

When the company has to explain itself

In May 2011, unusual network traffic forced Siegrist into a different kind of explanation. LastPass had spotted an anomaly and responded to the possibility of an intrusion. He described transfers occurring at an unexpected time between machines that would not normally exchange much data. The uncertainty itself demanded a decision.

Siegrist acknowledged that the response might have been overly alarmed. Users encountered difficulties during the precautions, including problems around password changes and local data. His explanation combined an account of the technical concern with an attempt to distinguish possible exposure from what the company could establish. It was a much less comfortable conversation than describing a feature.

June 2015 brought a confirmed breach. LastPass disclosed that account email addresses, password reminders, salts and authentication hashes had been compromised. The company said its investigation found no evidence that encrypted vault data had been taken or accounts accessed. Its response included additional verification for unfamiliar devices or locations and prompts to change master passwords.

Updates signed by Siegrist and the team described further changes, including hardware security modules and a paid bug bounty program. These episodes belong in his founding story because they tested the very promise on which the company depended. A password business has to explain its failures as carefully as it explains its design.

The sale that prompted more questions

In October 2015, LogMeIn agreed to acquire LastPass for $110 million in cash, with up to $15 million more tied to milestones and retention incentives. For a company founded seven years earlier, it marked a substantial change of ownership. For customers, the announcement opened another discussion about custody.

Four days after the announcement, Siegrist appeared on Security Now with Gibson and Leo Laporte. Laporte challenged his account of customer anxiety, focusing on LogMeIn’s record with other products. Siegrist argued that the acquisition would provide more engineering and testing resources while allowing his team to continue its work. The encounter was cordial, but the questions had teeth.

His acquisition announcement also received a personal update addressing the reaction. He said the team would remain and described the deal as a way to develop the service faster. The need for that reassurance was revealing. Customers had formed expectations around the people running the software. An acquisition changed the relationship even before anyone changed a feature.

Siegrist subsequently served as vice president and general manager of LastPass at LogMeIn. The founder who had once emailed a customer with a proposed fix now had to make a much larger organization feel answerable.

Asterisks, dots, and unfinished work

The next chapter included a surprisingly small object: an asterisk. In February 2016, a post signed by Siegrist explained LastPass’s new logo. The old symbol had become the subject of a trademark dispute. The replacement drew on the dots familiar from password entry fields. Even a business devoted to concealing characters needed to think carefully about which characters it displayed.

In November 2016, he announced free access across multiple devices. Passwords saved on one device could become available on another without that feature requiring a Premium subscription. It was a concrete move toward the practical accessibility that had motivated the company. These were the terms of that announcement, a moment in the product’s history.

Siegrist later left LastPass; by 2023, Laporte described him as having been away for years. His founding tenure remains a story of engineering conducted in conversation with users. The encrypted file, the customer’s faulty installation, the questions after a sale: each brought a different version of the same demand. Make the arrangement understandable. Make it usable. Be there when somebody needs an answer.

The 2010 customer story offers a fitting last image. Before the acquisition figure and the international office, there was a fresh build of some software, sent to somebody whose problem still needed fixing. It is an unglamorous unit of company building. It is also one a customer can recognize.