Kevin Fox and the Art of Moving the Lock

A coffee shop is an agreeable place to borrow a table and a less agreeable place to borrow trust. Kevin Fox used the setting in a 2018 explanation of mobile security: someone opens a corporate app on a personal phone, joins public Wi-Fi and exchanges sensitive information with the company’s systems. The coffee is optional. The security problem comes with the connection.

Fox’s attention falls on the journey between the application and the service it needs to reach. Who is using the app? Is the app intact? What condition is the device in? Can the information travel safely? Those questions give a better introduction to Blue Cedar’s co-founder and CEO than a list of executive titles. They show the particular piece of the world he has spent his career trying to make work.

His company puts security controls inside mobile applications, including apps already built by somebody else. The choice of location matters. A business can have a legitimate interest in the information an app handles while having very little authority over the phone carrying it. Contractors, partners and employees arrive with their own hardware. The organization’s responsibilities arrive with them.

Before the app, the network

Fox came to this problem by way of the machinery underneath it. His public career record includes architecture for IP and MPLS routing systems at Fujitsu and Equipe Communications. These are systems concerned with moving traffic through networks. At Cisco, he worked as a technical lead in the Network Security Group and the Endpoint Security Group, bringing the connection and its defenses into the same professional picture.

By the time he was vice president of engineering at Mocana, the work included designing and implementing Atlas Gateway, along with mobile app and endpoint security software. The names change across his résumé, but the technical subjects sit close together: routing, protected connections, the software at either end. His biography also credits him with multiple patents in VPN security.

In 2016, Blue Cedar spun out of Mocana with the Atlas technology. Fox became a co-founder and CTO. This was a new company carrying an existing body of work, a useful complication in the usual startup story. The technology had already been designed, deployed and used before the new business put its own name over the door.

Blue Cedar’s July 2016 funding announcement described more than 150 Atlas customers and over a million users of apps secured by the platform. Those were figures for the technology at that point in its history. The company raised $10 million in that round, with backing from AITV, Benhamou Global Ventures, Grayhawk Capital and Generation Ventures. Fox’s engineering work now had a separate corporate home.

A new phone meets an old app

A more intimate demonstration arrived in December 2017. The iPhone X had introduced Face ID, and Blue Cedar announced a way for protected enterprise apps to use it. The interesting detail was the age of the software: the capability could reach apps that had been built before the new phone existed.

Fox, then CTO, emphasized that developers would not have to change their code to add the capability. That small phrase carries much of the product’s argument. An organization may have the application it needs and still face a separate project whenever it wants to add a security feature. Returning to the original development team can turn an apparently modest improvement into another round of work.

“without the need for any code changes by developers”

Kevin Fox, on Face ID integration · December 2017

Blue Cedar used code injection to add the capability through Apple’s interfaces. On the user’s side, the result was familiar: look at the screen and unlock the app. Beneath that brief interaction sat the business of adapting older software to a newer security mechanism. It was a compact example of the gap Fox’s company wanted to close.

The key deserves a question

Fox’s writing in 2018 followed mobile information into several less glamorous places. He considered stored database rows, log files, cookies and the keys used to encrypt them. This is where a security discussion tends to lose the dinner table. It is also where the actual decisions live.

In an essay about insecure data storage, he used a financial-services application holding transaction information on a device as an example. Protecting that information required attention to both encryption and control. If the enterprise could not manage the phone, it still needed a way to govern the sensitive material its application left there. Encrypting a file was one part of that arrangement; deciding who held the key was another.

His June essay asked readers to consider the consequences of a lost device. The question was concrete: would the organization retain access to the encryption key? A feature list can say that data is encrypted. Fox’s example asks what happens to that promise after the phone goes missing. It is a useful way to test an abstract claim against an ordinary mishap.

Another article set out four questions for mobile security teams. They concerned the work of testing security features, controlling when and where apps run, detecting altered versions and protecting data when a device is offline. Together they describe an application with responsibilities of its own. It must check conditions, enforce rules and cope with occasions when the network is unavailable.

The policy work also had a calendar. In May 2018, Blue Cedar introduced dynamic controls that let an administrator warn users to update an operating system before a deadline, then block access after that date. Fox described the release as giving customers control over the conditions in which their applications executed. A warning could arrive inside the app where the decision mattered.

That approach allowed more choices than admitting everyone or shutting everyone out immediately. An organization could notify people about an old app version, an approaching update deadline or a scheduled service interruption. Those messages could be delivered without another source-code modification. A security rule had become something a team could administer over time, with room for users to act before access changed.

The coffee-shop problem, revisited

In July 2018, Fox returned to information in transit. A successful login, he explained, did not settle every question about the communications that followed. He described Blue Cedar’s combination of access checks and app-specific secure connections, or microtunnels. Before communicating with a protected backend, an app would authenticate the user and check relevant conditions of the app and device.

The architectural detail is that the protected connection belongs to the app. A personal phone can carry many unrelated activities; a corporate application has a particular destination and particular information to protect. Drawing the boundary around that exchange gives the organization a more specific place to apply its rules. The coffee shop can remain a coffee shop.

His interest in mobile computing also extended beyond the hazards. In May 2018, he argued for processing some information near where it is created. A camera could examine its stream locally and report motion instead of sending everything onward. A shop could use local information to spot a growing checkout queue. The security work accompanied a practical reason for wanting the mobile software in the first place.

A project with a flight line

Fox’s engineering role is visible in federal research records as well as company biographies. In 2019, he was named principal investigator on a $50,000 Air Force Phase I SBIR award to Blue Cedar. The project addressed keeping mobile applications secured as operating systems, app frameworks and security technologies changed. Change itself was part of the assignment.

A subsequent Phase II BESPIN award to Blue Cedar totaled $1,704,995 and began on June 22, 2022. Fox was again named principal investigator. The project concerned integrating BlackBerry security controls into Air Force applications, including software for which the Air Force did not own the source code. That limitation made the compiled application an especially consequential place to work.

The project description follows a binary through analysis, integration and signing before distribution. The amount belongs to the company’s research award. What makes it relevant to Fox’s story is his named technical responsibility and the problem’s continuity with his earlier work: apply security to software without requiring access to everything that originally produced it.

The work after the work

By 2022, Blue Cedar was also describing the sequences around that integration. A mobile app needs to be imported, enhanced, signed, tested and distributed. An update can send it around the circuit again. A change to a security library can do the same. Finishing the application leaves a surprising amount of application work.

The company’s workflow builder lets teams arrange those activities into a reusable sequence, including integrations for BlackBerry Dynamics and Microsoft Intune. The attraction is straightforward: after agreeing on the steps, an organization can run them again when the app or its dependencies change. The process becomes part of the product, rather than an exercise that starts from memory each time.

Fox now leads Blue Cedar as CEO after serving as CTO. His career offers a way to read that progression through the work: first the routes that carry information, then the defenses around connections, then controls inside the software people actually open. Each setting asks where useful access should meet an enforceable rule.

Back at the borrowed table, the person with the phone has a simpler ambition: open the application and get something done. Fox’s professional history sits behind that ordinary moment. The network, the key and the app all have jobs to do before the user can return to theirs.