Transcript.

Erik: Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host, Erik Walenza.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Erik Walenza, CEO of IoT ONE. And our guest today is Ellen Boehm, Director of IoT Product Management at Keyfactor. Keyfactor makes it easy to apply cryptography in the right way at the right time at global scale. In this talk, we discussed how product engineers can design cybersecurity into parts and components at the beginning of the design cycle, and then maintain it throughout the product's lifecycle. We also explored the differences between PKI deployment for IoT devices and for typical enterprise applications.

If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Thank you. Ellen, thank you for joining us today.

Ellen: Yeah, thanks, Erik. It's great to be here.

Erik: I'm really excited about our conversation, because this is a topic that on the one hand is really critical to having functional market around IoT devices, and on the other hand, it's a topic that I know extremely little about, and that I think most people that are even IoT product managers probably know very little about. So I'm going to ask a lot of very ignorant questions, and then just stay in advance, appreciate your, your patience and helping to walk me and then also our listeners through this.

Ellen: Yeah, definitely. I mean, it's an evolving space, and I think we all learn every year as things change.

Erik: So before we get into the topic of what your company Keyfactor does, we'd love to just understand a little bit more of your background and how you ended up here. So I know you started your career as a technologist with GE, was your career always around the topic of securing devices securing systems or what led you now to Keyfactor?

Hellen: So my background again, has been in product development and engineering for General Electric. And I got into the smart connected space, firstly, by working on smart street lighting. So we made products that were created a mesh network of streetlights, and were able to detect outages of the lighting, and provide capabilities for municipalities to dim lighting when it was certain hours of the day and get into security and keys and certificates.

And I remember being in the lab with the team and trying to figure out well, what is this key? And can we put the same key on every device? And if so then what if it gets hacked, then all the streetlights can be turned off and on? So that was a good 10 years ago or so. But it's the security around certificates and keys has definitely evolved. I think there's been a lot more knowledge sharing as more IoT designers across industries are starting to get more into this space and learn that using certificates and keys in the right way is a really great thing to do in terms of protecting your products and what they're allowed to connect to.

I've been with Keyfactor now for two years, working on the other side of it as a product person that knows the history of how you develop new products and what you have to go through in terms of getting them into manufacturing, and then also how you keep track of them over the lifetime of their devices. So I've get to see a little bit about throughout this process.

Erik: And so you're Senior Director of IoT Product Management. For Keyfactor, does that mean that you're leading product management for Keyfactor’s internal products or supporting your customers in developing products using your technologies?

Ellen: The answer is both. So a Keyfactor, yeah, I'm responsible for what is the product strategy around IoT. A big portion of Keyfactor business actually supports the enterprise public key Infrastructure and enterprise certificate management and automation. Keyfactor has been around for about 20 years. We started as a consultancy business, helping enterprises get their certificates within their enterprise under control.

And recently, in the past five years or so, we've shifted to also take that technology and apply it to IoT. And so that's where I've come in to help to expand around what the offering is and make sure we can meet the use cases of the IoT customers. They're slightly different than just an enterprise device that is constantly connected to the internet, for example. So I am here on behalf of our customers to understand and know how they're implementing keys and certs in the products, and how we need to make sure that our platform on the back end can support that and can scale up to the volumes that we talked about when we have lots of connected things.

Erik: But as a starting point, I think it'd be it would be useful for me and probably for some of our listeners just to understand the 101 of, so when we talk about keys and certification, what are we actually talking about here?

Ellen: So digital certificates is rapidly increasing in its usage in IoT, because it is a way to have a unique credential for each device that you produce that is bound cryptographically to a unique key. And then that certificate is used for authentication, for proving integrity of the device in the firmware that it's running, and for being able to create secure connections over which then you can send data.

But if you're a medical device like a pacemaker, and you need to connect to a patient's iPhone, and then that iPhone needs to send data up to the cloud, how are you securing those connections between each of those endpoints and then an endpoint that is very remote? So we do that by using certificates and creating TLS connections, and so secure channels over which you can submit data and transfer information and then decrypt data by only authorized other endpoints.

PKI Public Key Infrastructure is an offering that Keyfactor has, and we help our clients, both on the enterprise and the [inaudible 07:14] side, either use the infrastructure and add some additional software on top of that, or we do a completely cloud hosted offering where we can stand up a PKI for you, which is basically an offline route dedicated to your company from which all the certificates that you need to issue to each of your devices is just generated from. And so PKI is really a framework, which is a hardware, it’s software, it’s policies and procedures, that allows us as operators to create these certs and manage them, and then store them and then revoke them eventually when you don't want a device to connect into your system anymore.

Erik: So hardware, software, and then also services around the structure of the system, so Keyfactors, certainly on the service side, now also, on the software side, do you get involved in the hardware, or is this more working with the OEMs to determine what hardware they need or based on the hardware that they have, how they can deploy secure solutions on that hardware?

Ellen: So, maybe two pieces. So there is hardware, [inaudible 08:25], modules, and that is where we will store the offline root key. And then we have HSMs for issuing certificate authorities and store keys there that can also be in the cloud. So that's on the infrastructure side. That is what we can host or we can work with the internal IT organization of the IoT manufacturer. If there's infrastructure you want already leverage, that's fine, too.

[inaudible 08:52] side, that is another key piece that we're hardware agnostic in that we're a software platform that is meant to integrate into your devices. So let's say you make something and you've got an NXP or you've got Xilinx or you've got some kind of existing microchip hardware that we want to then create a key and store inside one of those maybe a TPM or secure element, we have  [inaudible 09:29] an agent and that of hardware, or a set of software tools that we can integrate into that.

Depending on if a company needs some help, doesn't have a ton of background and experience with certificate and key management, that is where we can come in and partner with you to make sure that within the hardware platform that you have created, that you will have the capability to create keys, you will have a place to store that key, you will have a way to access that key and maybe  [inaudible 10:02] that are going to be living in the field for 10-15 years or so.

Especially big industrial assets that have a lot of value in them, we want to make sure that they can be updated, because cryptography that we put in our devices today is not going to be as strong in 5 years from now and in 10 years from now. And that is just how do you respond to that? How do you go and touch all of your devices so that you can swap out those routes maybe, or swap out the certificates and update that crypto to something that is stronger and cannot be compromised?

Erik: What does this mean as we start to deploy really billions of devices that have very limited compute power, and in some of the challenges that might be involved there? But before we get deeper into that, let's take a step back, and talk a little bit more just from the business perspective of who Keyfactor is working with, and a little bit of the problems that they're solving. Because I think, myself and a lot of people have a general sense of, okay, there's cybersecurity problems, and there's privacy related issues.

But of course, under each of these buckets of cyber security and privacy, there are real specific issues that need to be addressed, and thought through that maybe many people are not so accustomed to thinking through. So let's start though first with who you're actually working with? Who would be a typical customer of Keyfactor?

Ellen: So on the IoT side of the house, our typical customers are in the medical device space, they're in the connected vehicle space, they're in industrial controls, for example. And I think we've had more conversations with those industries because there have been guidelines released by the FDA, for example, saying that when it comes to securing your devices, there's some recommendations around cryptography and the ability to update that crypto.

And so we basically can offer a solution that helps the customer to meet those requirements when it comes to creating an asymmetric certificate and then putting it on the device and then updating it. Again, same thing in the vehicle space: we're hearing more and more from the leading automotive OEMs, their suppliers, about using PKI within the vehicle. And that's for in-vehicle communications for infotainment systems, the ECUs, to the wireless, all of that is there different endpoints within the car that they want to use certificate based authentication.

And then additionally, in the connected vehicle space, when it comes to autonomous, so you've got a vehicle, and it needs to communicate with another vehicle; it might not even be same manufacturer? But what is this the standard way on which they can authenticate to something and then have that be a framework for which to communicate and trust that the communications going across them have not been intercepted and changed? Because in both the medical, and the vehicle space, we're talking about critical things that could impact human life.

So when it comes to security and needing to make sure that we're not compromising your messages that we're sending to these devices to be able to change the rate of a pacemaker or change the amount of medicine that's this distributed to a patient, that's really, really important that we don't mess with that and on the car that we don't allow vehicles to stop working or operating or have a crash or something go wrong.

So that's kind of I think, why we've seen those types of industries leading is that there's critical actions could impact human life, critical infrastructure, things like that are where we've had some of the early conversations. Although, I must say that using certificates and keys is the recommended method for any industry, whether you're making connected refrigerators or something that's maybe not immediately can harm people category, it's still really important to think about securing your devices.

Because that ties back to, if you have a breach of your fleet, and someone is able to take control of your devices and then impersonate you, what happens to your brand? What happens to if you have to have a warranty recall, and all of your devices now need to come back and be reflashed or updated? Or there's a lot of things that we have to think about when it comes to trigger events that could cause us to say, how could we have implemented a better security posture from the beginning? So that's what we try to talk about and think about what could occur and then how do we prevent that from the beginning when we're doing that design process.

Erik: If we dive into the automotive example, if we look at a automotive value chain, you've got your OEMs, your ford, you've got your tier ones that are maybe providing the integrated engine, and then your tier twos are providing components into that, would you be working with the OEMs? Are you working with a tier one, the tier twos, is it all of them? Who would be in this situation? Who would be the ones that are actually deploying this solution on the hardware?

Ellen: So we work with both the OEMs and tier one suppliers. We have a current project going right now which is working on engine control units within the vehicle. And the automotive OEM has the vendor that they've been working with. And so it's kind of a three way partnership there and that we're understanding, where do we need to create that certificate? And where do we need to store it? And then what is it allowed to talk to?

Because if you if we're designing pieces in a black box, it definitely makes it harder in the end to have it all come together. So it depends on how the OEM, I think, has developed what is the design process? Typically, how have they gone about the development and integrating the crypto into their product as they go along? Ideally right at the beginning of the design process, when you're starting a new project, you can have a fresh sheet of paper and you can say, okay, what is the ideal state I want at the end and then work backwards?

I think in many cases, we were creating the product, and it's designed to do certain features and functionality. And then sometimes security is an afterthought. And I think that's starting to change more as people are coming to the realization that that's more and more important, as you said, many things are now connected to the internet. Hackers are becoming more aware of how to be able to attack enterprises, and be able to take advantage of that impersonation, man in the middle attacks, things like that.

So it's becoming more visible and so I think security is coming up earlier and earlier in the conversation of the product development, which allows us time to actually go through cycles and figure out well, what is the best way to do this? Where exactly do you need to have the key and certificate creation? And what is the best crypto that fits within your hardware? Because there are different types of keys. There's RSA Certificates. There's ECC certificates, which we see commonly used in IoT devices that are more constrained, don't have as much processing power, and need a bit smaller capability. But they still want that asymmetric certificate.

But I think the key is early on getting into the discussion, having your partners there with you, and then brainstorming around what is our overall security architecture? Where do we want to put our trust boundary of what this device is allowed to talk to within the system where you want to have those checks and balances is really important.

Erik: We had a previous speaker who was doing security solutions for enterprise software. And he mentioned that they did a study with their customers that showed it was something like 17 times as much effort and expense to fix an issue after the product had been released to the market than it would have been just to properly engineer that into the product. And I assume you probably have a similar dynamic where you're probably occasionally called into products that have been released. And then there's some security issue and they say, okay, we've got to fix this come help us.

So you mentioned already it's important to be involved upfront. Where would you get involved? And then who are the stakeholders that you'd be working with from the initial discussions, and then as the product is moving towards the market, whether maybe there's other stakeholders that might be involved in this down the line?

Ellen: And just quickly, to your point about the cost of a recall. We actually had a customer that came and it's to the order of millions of dollars. If you have to physically have a maintenance person go out to each of your devices that is installed in-field with your end customers, like, let's say you're making a connected thermostat, and every single thermostat has a key in it, or maybe something's hard coded, or you don't have the ability to connect to it and update it, you're either going to then rip and replace and put a brand new one, or have somebody go out: it's just the cost is astronomical. So yes, on that.

But in terms of stakeholders, I'd say, early on, we work a lot with the software engineers. Typically there's a security architect. There is a firmware engineer. It's kind of the design and development team that is looking at how they currently placed certificates, and how they, within the current firmware, create that unique key. And so those are the initial stakeholders that we prove out the basic MVP and make sure that a solution like Keyfactor is helpful one and can meet the needs of scalability or offline management of keys and things like that.

So those are the early discussions where we offer demo environments, sort of like a proof of concept environment to test out and it's essentially a PKI in the cloud that you can pretend is your production test environment and go through and figure it out hands on. And then after we've done that, then we would secondly shift to incorporate the manufacturing team. So you have to make sure that this key generation process fits within your current production.

So likely, there is a test workstation or firmware flashing station at the end of the line or a QA station. So we then work to make sure that we're doing code signing of the firmware using the PKI and that we release code to production in a secure manner. So that involves the manufacturing teams.

And I think that the third category would be then the operations team. So once the product is packaged up and it goes out to then be commissioned, there's likely a commissioning team, this needs to be assigned to run an end facility, and then the operations team likely is responsible for long term maintenance or tracking the performance of the device. Do we need to send any firmware updates, fixed bugs, feature updates, that sort of thing? So those are kind like the three big categories, like initial designers, manufacturing, and then operations.

Erik: And this would be budgeted into the product development costs, is that the way that this would typically be budgeted?

Ellen: So product development cost, there's a couple different ways that I've seen our clients do it. If there is an overall product security group within your company, there's oftentimes some champions that say we're going to use public key infrastructure as the backbone of our security for our products, and we're going to create this PKI. Either then they decide to host it and manage it on their own, or they have us come in and do that in the cloud. But then that team helps new product groups learn how to leverage the technology, which is a great way, I think, to scale up within your company.

Because if you have a new product that can spearhead this and learn the best way for your company about how to integrate, then you can take those learnings and pass that on to the next new product group that's developing something for 2022, for example. And as you have more groups leverage that, you would be able to spread the cost of that investment across multiple groups. So you get some economy of scale there as well. So that's one model that I've seen work pretty successfully at some of our customers.

Erik: So there are economies of scale that you can use this across different product groups. Are there also incremental costs per device? And the reason I'm asking is that the categories you've mentioned, so far automotive healthcare, we're talking about fairly high value devices. But then of course, they're starting to be more devices that are low unit value, so sensors that might be deployed in in fields and so forth. And maybe they're not a high priority right now, but I think there are also security concerns there.

Is there a rationale for why it might not make sense financially to deploy secure solutions on them? Are we looking at it as long as there's a high enough volume of units, then you can spread the cost across the units in the field and still make the case for deploying solutions on devices that are individually quite low unit cost?

Ellen: And the way that our product offering works is that we do have an annual subscription for the use of the certificate automation, and/or the public key infrastructure. Because we own an offline root for you, we host it, we maintain it, we update the Certificate Revocation lists, we make sure that everything is up to date, and all of that. So that's more what the annual license is around is infrastructure, maintenance, and things like that. Also, just you get the benefits of the updated software capability and automation that our development team is constantly improving the capabilities and functionality and features on that.

We do have a small per device fee that decreases as more products leverage the platform. And so we do this because we want to be able to start with one or two product groups being able to leverage the platform. There's a certain quantity of devices included for free, because we know that when you get working, you're not all of a sudden making tens of thousands of devices that likely ramps up like you were mentioning.

So we want to be able to work with customers to understand what is that right device price model for your business. And we're flexible in being able to have conversations around what makes sense to you because we want this to be something that you can continue to see value with over time. So I would say that, again, if you're talking about millions of devices, it's going to be a pretty small fee per device. And we've priced it that way because we don't want it to be a barrier. We want it to be seen as this is an investment in my product for the long term from a security standpoint. Because if it is hacked, then there's just a lot more negative repercussions around updating and cleaning up that mess or trying to recover any negative brand image. So that's how we've kind of come to that pricing structure.

Erik: Let's get a little bit more into the technology. Are there any topics on the business that you think we should cover that we haven't touched on yet?

Ellen: The only thing I would maybe say was his partner approach. Keyfactor, again, is the software platform and a public key infrastructure platform. We have partners in many places around partners that are traditional certificate authorities, or public facing certificate authorities, we can connect into that.

So if you in your enterprise, or your IOT space are already using a certificate authority to create certificates for you, but you don't have an automation capability around that you don't have a way to update over time, other than maybe manually, we can connect into that. So we have partnerships with certain key players. Now, that's on the CI side.

Also, on the crypto side for when it comes to IoT, we have partners that are cryptographic library providers, and they provide the algorithms and the crypto engines to be able to do the encryption. And so we've got partners in that have crypto that specific for medical and partners that have crypto that specific optimized for embedded devices and runs, it's written in C.

So I think partners are also really important in this space is to likely know that when it comes to IoT security, there's obviously multiple layers of where you need to protect data and protect, do encryption. And you're likely going to have to find a vendor who has a lot of capabilities, but also has partnerships because they're not going to be able to do everything. And so that's one thing I wanted to make sure that people think about when you're looking to embark on this journey.

Erik: So let's get a little bit deeper into the technology here, so we've already touched on it from a couple angles. But is blockchain at all interesting here? So, on the one hand, still relatively skeptical around the applications of the blockchain beyond financial speculation, but at the other hand, actively looking for relevant use cases? You're dealing with cryptography, so it's just a cousin here. But is there any relevance to your business?

Ellen: Yeah, again, I'm not very much a blockchain expert. But I think there's likely a place where blockchain and then public key infrastructure are very tightly aligned, and can work together. So blockchain is responsible for maintaining the connections and the relationships between disparate things. And tracking those relationships, Public Key Infrastructure is the way to create a dedicated root of trust from which then all devices have that built into them, and all things have that built into them. So it could likely be something that works in concert together, where you have identities that are created using a PKI, and are certificate base, but then the connections and those relationships between those end devices are our tracks using Blockchain technologies. So that's my two cents on it about how things might work in the future.

Erik: But what do you see as the state right now? Are we moving into a state where we're can expect greater security or the opposite? Is that going in the direction where there's more programming power, easier to find hacks? And then maybe you can share a little bit about the technologies that you're really paying attention to, whether there are technologies that are directly in your tech stack, or technologies that are somehow relevant that are moving us into either a more or less secure state?

Ellen: I think there's a lot there. So I think, from my perspective, we have learned a lot about cryptography and TLS SSL from the enterprise. And we know very well how to secure banking websites and online transactions and things like that. And what we're doing now is taking that learning and applying it to IoT.

It's not like we're starting from scratch there. There's many analysts and people that recommend this as a super robust way to do certificate policy and practice management and things like that. So definitely not, it's still at the very early stages of being more widely adopted. I think we're going to just see this continue to grow as we make it easier and like you said, as more devices have processing power to be able to generate a certificate and store certificate.

That is typically the current restriction that I hear on some very small devices as well, I'm running batteries only, and so I've got to prioritize the functionality to things that help make my device run as opposed to secure it. So I think that's why we're seeing more and more people start to invest in some infrastructure and a methodology like PKI because it has been proven, and it is a really solid way to protect your data and do secure authentication at different endpoints within the system.

The other thing I would say for IoT is the IoT devices, when we're talking millions of things, anything that's built into the device needs to be very scalable. And so you have to think about having a public key infrastructure that is very robust and can grow up to those types of quantities, one in production, and then two in the lifecycle piece of it. So if you need to then go and swap out 500 million certificates on your devices that are out in the world, how quickly can you do that, and how reliably can you do that?

That's something that Keyfactor, we actually have a study on our website that that talks about how we've gone and actually done that for our customer and swapped out all the certificates and routes within a period of a day or two of that type of volume. So, again, we're not starting from scratch here, but we're definitely still in the early phases of having more of a mass adoption of PKI within IoT.

Erik: I mean, we always think about IoT as a system and there are certain parts of the system that behave very similarly to other more mature systems that already have mature solutions that, you mentioned, baking, and so forth. And then there's the component, which is maybe the device itself, which is somewhat new and challenging, but a lot can be repurposed from your existing businesses. And why don't we look at one or two examples and do an end-to-end walkthrough from first discussion through implementation? Is there one that comes to mind?

Ellen: Yeah. So I mentioned a little bit of the medical devices earlier, so maybe we'll start with that one. So we have a customer that we have been working with, they have a variety of different products. This one use case I'll talk about is one of the earlier products that they implemented a PKI solution for, and it was with a pacemaker.

And so the pacemaker is, again, a very constrained device, and it's implanted in the body and we actually worked with them to create a certificate that was optimized for that space to work within the restrictions that they had. But again, it was created from the PKI that was for them and it was able to have a unique identity for each thing that they were making. Then they also had an application that would run on the patient's iPhone. So, if you had this pacemaker, you could go to your app store, you could download the application that would run this, and then you'd be able to send any data for how that pacemaker was working to the phone, and then that phone was an intermediary that would then send data back to the cloud.

So the super important piece there was that this medical manufacturer wanted to make sure that while this phone was completely out of their control, and would be operating on the cellular network or a WiFi network of the patient's home, who knows what's encrypted or not encrypted. So they basically said, okay, that is going to be an untrusted thing. But we need to encrypt the data that comes from the pacemaker that goes to the phone, and then from the phone through that untrusted network to the cloud and then we only are going to decrypt it in our cloud back end based on certificate based authentication.

So you can relate that to almost anything that has an IoT, maybe edge gateway, and then cloud back end. So I think that's why it's important when you're designing your architecture for your overall IoT system to figure out where you want that trusted boundary to be, who you want to be able to allow to decrypt, and then encrypt and then using authentication failed to do that.

Erik: So a lot of maybe existing systems are from a business model perspective relatively simple, so the OEM owns the system, the user links the system to their mobile phone. But I think more and more, we're starting to see a bit more innovation on the business model side, so maybe insurance company might have an interest in having selective access to this data, a hospital provider might be valuable to be able to provide them real time access to the data, and so forth. Is that something where you would be actively involved in supporting the architecture discussions around that? Or is it implied that your solution would operate in the backend and it doesn't so much matter who's getting access, your solution would just be part of the infrastructure that ensures that whoever should have access has the appropriate mechanism to gain?

Ellen: Yeah, I would say depends. So we're typically more on the infrastructure and an application side for a Fortune 500 company, whether that is an enterprise business, or it's an IoT business. But we are hearing more about this where they do have partners that also want to be able to maybe place a certificate on these devices to be able to connect to certain pieces and have information. So I do see more of that coming up where it's dual certificate, it’s not so much shared access, but shared Intel into how things are operating.

But I think as this evolves, and people start to think more about how you work with your partners, your vendors, especially when it comes to IoT, and the complex supply chain that we have of you might have a design house, you might use a contract manufacturer. And so if you have that within your model, how do you then still ensure that your device has the right security around it as it's moving from these different places that before it gets installed at your end customer? So I think we're starting to talk more about that, although we don't have any full blown implemented use cases we can talk about today. But I think we're likely going to see more of that in the future.

Erik: I mean, I think a lot of pilot projects, and in that case, they're not yet so concerned around how to secure systems. They're just trying to establish value, but I think we'll probably see more instances of this in the coming years.

Ellen: Yeah, I totally agree.

Erik: Any other questions that I should have asked you, anything, either on the technology side, the business side, or best practices around implementation that we haven't covered?

Ellen: I would just say to reiterate what I want OEMs and manufacturers of IoT devices to remember is that security it is not just something that you can just buy, and then it works off the shelf. We've got to put some time into designing and architecting it and we'll get it right. And every business is slightly different. But there is general practices that we can apply that work across medical to control systems to consumer.

But there's three things you really just have to remember that devices need to authenticate. And that means that only legitimate devices can connect to your system. And we do that using certificate based authentication. And then the encryption part, so encrypt your data at rest and data in transit, just like that medical device example and then verify. So to using digital signatures, verify that let's say, you're pushing an OTA of new firmware, don't allow your device to install that firmware and start and boot up and start running it until you've verified that signature, because the signature was built in when the device was produced. So, just simple things like that will really help improve your security posture. And I think that's at least a place to start when you're trying to figure this out, and how to start to build it into your organization.

Erik: What's the best way for people to learn more about what Keyfactor does? I mean, I will certainly put the website in the show notes. Is it just going to your website? Is that the best approach?

Ellen: Yeah, our website has a ton of information. You can see our product solutions. There's partner pages. There's some on demand videos of demos and things that we've done and our marketing group is constantly updating that. We've got a bright talk channel. So just tons of content you can read there and a chat. If you wanted to reach us specifically, just type in there and we'd be happy to get somebody on the phone. So again, just look forward to talking with more people about this as you're trying to figure out how to go about this journey and your IoT security.

Erik: Thank you, Ellen.

Ellen: Alright. You're welcome.

Erik: Thanks for tuning in to another edition of the industrial IoT spotlight. Don't forget to follow us on Twitter at IotoneHQ, and to check out our database of case studies on IoTONE.com. If you have unique insight or a project deployment story to share, we'd love to feature you on a future edition. Write us at erik.walenza@IoTone.com.