HID Connects Podcast Season 2 Episode 4 — Physical Security: What Is “Open” & Why Does It Matter?
Welcome to HID Connects!
HID Connects is a podcast designed to bring you the latest news and trends in the security space. Our goal is to not only equip you with information and best practices, but also open new conversations on topics shaping our industry.
Joining us for this episode is Will Brown, HID’s senior director of product security and data privacy, Damon Dageenakis, senior director of Access control devices and, Steve Lucas, VP of sales and marketing at Mercury. We’ll be “opening” the floor to our experts to discuss “Physical Security: What Is “Open” and Why Does It Matter?”.
Take a minute to listen below. And while you’re at it, be sure to subscribe to receive future episodes.
Here is a transcript if you’d like to read along:
Matt Winn
Hello, everyone. Good morning. Good afternoon. Good evening. Whatever time it is, and wherever in the world you may be, my name is Matt Winn, your podcast host and resident secure identities nerd. Welcome back to HID Connects. For some time now, the industry has been debating the merits of “open architecture.” And in today's episode, we're going to take this discussion into podcast format to help provide a common definition of this term, figure out why it's important now and into the future, and frankly, just do our best to offer you some form of perspective of open versus proprietary architecture.
To help us better peek under the hood of open architecture, we've got a packed panel of experts, all of whom are joining me live in the studio. First, we have Will Brown, HID’s Senior Director of Product Security and Data Privacy. Also joining us is Damon Dageenakis, Senior Director of Access Control Devices. And last but most certainly not least, Steve Lucas, VP of Sales and Marketing at Mercury.
Gentlemen, thank you for coming all this way to join us for today's podcast in our Austin headquarters. Let's start with introductions. Will, we'll begin with you. Do you mind telling us about where you are from, a little bit about yourself and what you do at HID, please?
Will Brown
Sure. Absolutely. Yes. I'm the head of product security and privacy for all of HID. And that role basically means I help the product development teams understand what they should be doing to ensure security and privacy by design in their products. Obviously, working with the Mercury team in their panel designs and helping them understand the kind of threats that panels face and how we can best put controls in those panels to help make them more secure.
Matt Winn
Very good. Very smart man with a very important job. Damon, same to you. Thanks for joining us and bringing your insights to the panel. Just a quick introduction of yourself, who you are and what you do, please.
Damon Dageenakis
Yeah, thanks Matt. Damon Dageenakis, I've been working at HID and in physical access for many years. Today and for several years I've been working in the controller space. I work in the product management group and I support bringing new products to market and working with our development teams and with our sales folks and customers, too.
Matt Winn
Very good and busy man indeed. Thanks Damon. And Steve, welcome to the podcast to you as well. Same for you. Quick intro. What do you do around here?
Steve Lucas
Thanks, Matt. Thanks for having us. So, Steve Lucas, VP of Sales of both Mercury and HID products for our OEM business, focused a lot in North America. Our team looks after the big corporate relationships that we drive our products through. Been in this industry for quite a while. I was part of the original Mercury pre-acquisition, so I like to joke that Mercury runs in my blood.
Matt Winn
One of my favorite product categories that we have here at HID. Very cool. A lot of brainpower at this table. Thanks again, gentlemen. Okay, so now that you know who our guests are, let's get into today's burning question, which is: in physical security, what is open architecture and why does it matter?
Okay, Steve, we're going to start with you. Let's start with the basic definition as basic as it can possibly be. Now, this is a big, big topic. What does it mean to be open? What is open architecture? What's your take?
Steve Lucas
Yeah, certainly. So, open is such a broad term that quite frankly, I think it's overused in our industry. It means a lot of different things to a lot of different people. There's open source, from the developer world where they just give up and offer access to the software in a development environment they're in, there are open distribution products available everywhere, or neither of those things. Open for us, if we've done a good job, I believe, of defining openness is what it means to the actual end customer.
And openness can also correlate to choice and freedom of choice. And so from our view, an open message to a customer is that they standardize on our products from an infrastructure perspective, from the controllers through to the door. Then we provide that customer with choice both today and in the future should their needs change When it comes to software, platforms will be driving that product in the field, as well as underlying technology that connects into the controller itself. So it's an open platform that gives the customer choice both northbound and southbound within their system.
Matt Winn
Very good. And Damon, you live and breathe in this product line. What does open architecture mean to you?
Damon Dageenakis
I would just add to what Steve was mentioning. Open has many, many meanings but open doesn’t mean anything if you have no community that you can work with.
So, you could have a pure open technology play. But if you have no partners to work with, no community that exercises that technology, then it’s not much of a solution and it’s not going to bring very much value to people. So, to me, open is building technologies which are interoperable and many of our partners can work with you and help you grow. But also creating with that technology a group of partners that we go to market with, like Steve said, both on the systems side as well as down on the device side. And because we have such a wide breadth of those partnerships, regardless of how the technology actually works, it provides those customers or end customers options and creates a very strong, secure and high functioning environment.
Matt Winn
Many minds are better than one. And Will, Damon just touched on the idea of secure, from your lens of product security. What does open mean to you in that regard?
Will Brown
Well, in this case, I think what's best is what they mentioned both about the interoperability, the ability to future proof it and things like that. You know, we love to talk about our products and all of our products, but that may not be the best solution for your installation.
And maybe, maybe you need a more high tech something or maybe a less secure product available to you. Right? You really should be looking at your installation, your system, and understanding what the security requirements are for your system and build a system that's appropriate for you. By having this more open architecture, you allow our end user installers to figure out what's best for their use case and put the right architecture around that.
Matt Winn
Very good. So, choice for unique needs, Very important. All right, let's flip the question around and Steve, I'll come back to you. Is there any such thing as closed architecture and what would we call that and what would that mean?
Steve Lucas
So, I guess to do the opposite of what I described earlier, closed architecture would mean no choice or limited choices, at least. In our world, at least in North America, there's the open world of access control providers that participate in either the Mercury way or other systems and components that work within the open world. And then there's the other section, which is … we call it proprietary. But really what that means is from an end-to-end solution from the software through to the controller and in some cases all the way down to the reader and the credential, it's 100% proprietary to the manufacturer that's delivering that solution.
It's two distinct choices from an end-customer perspective. You've got one that's open and you can choose many different products in many different things. And then of course, the other one is closed and potentially locks you in for a very long time to two of the systems that you select initially.
Matt Winn
Gotcha. Important commercially. Will, going back to your expertise in product security, same question, different lens. Let's talk about closed architecture. What does that mean from your point of view?
Will Brown
I think what you just mentioned, right, that you're locked into that technology. Well, let's say the vendor itself has a vulnerability, but they're slow at patching. That means your system is now slow at patching as well. Right. If there's new technologies that you want to adopt, you know, you have new risks, new threats out there. And you need to adapt your system to address those issues. Well, if you're locked into that system, you can't adapt, right? And you're stuck with what you have.
Steve Lucas
And if I can add to that, that's an excellent point. When you look at an open ecosystem of partners that Damon mentioned, you really do get strength in numbers. So, when it comes to product security, when it comes to product reliability or just advancing and evolving the product to the next thing, you've got a community of dozens of OEM partners that help drive you forward, whereas in a proprietary world, you're maybe beholden either to their product cycle or to one manufacturer’s view. You have a much faster pace of innovation, much faster pace of dealing with problems as they arise.
Will Brown
And to add on to that, I think we run into this with open source software all the time. People like to say that open source software is more secure because there's more eyes on it. Well, that's only true if there actually are more eyes on and there's a lot of open source products out. There are projects out there where good ideas begin, but there's not enough developers looking at it, right? So, you can't just say, "It's open source, it's more secure.”
If you actually are working with partners and you are working with, more people actually looking at the architecture, you are getting those ideas that you need to make it more secure.
Damon Dageenakis
And from the product side, we really benefit from having all these unique perspectives because with all those customers that we have, they serve many markets, they have different ways that they create applications and go to market. We have a lot of partners in the host space that are cloud first or cloud only. We have others that are more hybrid and some that are just on prem and we get to work with each of those individual perspectives and design systems that work for all of them. On the closed side of things, maybe they do have a cloud solution and they have an on prem solution, but they have the markets they sell to and it is just less in numbers.
We really feel like we have a great advantage in Mercury because we get so many perspectives and sometimes it's a little difficult to deal with because there is so much coming into us. We have to prioritize and work with our partners as best as we can to try to deliver those solutions. But getting all that, like Steve said, accelerates our innovation and supporting all those customers is really a big piece of our foundation and why we believe our product is very feature rich and has been built that way for over 25, 30 years.
Matt Winn
And Steve, I heard you chuckling emphatically. And anything you want to add to that?
Steve Lucas
No, David's hitting on two key points, and I'm guilty of this. I'm causing the problem. We've got all of these great partners that are taking us into a number of markets, in a number of verticals, and we're not short on feedback and where to take and what we should do next. And Damon is the focal point for that. So, he's the brunt of all the requests from the partner community. That's sometimes driven by me in the team. I guess maybe I should apologize here while we're on the podcast.
Matt Winn
You gotta start somewhere, right? Makes sense. So, Damon, with that, let's go back to you. We talked about collaboration in lots of different pieces of input, people having different needs that are being met with an open architecture. But how do we have commonality? Where is there consistency and where do standards play into this? Let's talk about open architecture as it relates to industry standards.
Damon Dageenakis
Sure. So open architecture with industry standards allows us to more easily adopt a variety of vendors. I'm thinking specifically around some of the downstream products we interface with. So OSDP is an industry standard that we follow on our readers. Wiegand was more of a legacy one-way communication between a reader and a controller. OSDP is bi-directional and has security built into it, so we use OSDP to communicate to a variety of readers. We communicate with HID readers using that secure protocol. We communicate with other third-party readers and our Mercury product is designed around choice and having what we believe is a great, great system with Mercury panels and HID readers.
But you also have the choice to buy other people's panels and other manufacturers' readers. So, it allows us to adopt many different types of devices much more quickly versus having, you know, individual integrations with different types of devices and their more proprietary protocols.
Matt Winn
Very good. Will anything you want to add to the standard conversation? No? Okay. And from a customer perspective, Steve, what are your thoughts and how do you talk to customers about standards and their importance?
Steve Lucas
Yeah, look, I mean, our industry is probably a little bit behind when it comes to standardization. I was in the building automation world prior to the access control space, and they were much further along in terms of protocols with back net lawn and other things and how they standardize the communication between devices. For us in the security world and for HID and Mercury to be such big proponents of driving these open standards, we're really helping to nudge not just the customer community forward, but the industry at large in terms of adoption of OSDP. There are a number of standards we're using to add and create communication paths into our product.
Matt Winn
Very good. Let's shift gears just a little bit. At the crux of what we do, we are trying to offer levels of security to help protect people that the security technology is trying to protect, right? So, let's talk a little bit more about security policies in general. Will, you've got a big job, right? You work for a security company ensuring security policy. Just give us your elevator pitch on what your role is about and what HID's posture is on that. And then anything around Mercury as well. We'd love to hear more about that.
Will Brown
Yeah, absolutely. I was brought in to develop HID’s Security and Privacy by Design program. And what that basically means is, we're not looking at security at the end, right? We're not looking at security at the products already out in the field. We're trying to make sure that our development teams are considering security and privacy throughout the entire design cycle and that they're doing things like threat modeling their products and understanding how they function in the field, the threats that are opposed against them, and then how we can set controls against those threats to prevent those attacks.
And then we also do things like we have a minimum baseline set of requirements, the checklist you can imagine and you make sure you've got good, solid passwords, excellent storage and things like that, and then testing and things like that. We set this kind of policy that says, you know, here's what we expect. Every single product that I need to go through. Now, the challenge we run into, each idea is, you know, when everyone thinks of HID, they think of the access control readers, the cards and things like that. But, you know, we make these passive IDT tags, right? You know we make passport systems, right? Like the scale you can imagine with HID is insane.
So, trying to come up with a system that is one policy that applies to all practice is really, really difficult. So that's where we dive more into working with the product teams directly and understanding like, all right, Mercury panels, here's what we expect you to do. How do we do this for your panels? Let's work with your threat model, understand what your risks are.
You know which of these controls make sense for your product, for your customers, for your end users, and make sure that we have the right set of controls in there. Maybe some of these don't apply to you because you're not, you know, you're not building passport systems that are kind of scratched out, but these other ones do apply to you. We want to make sure that these ones are in there.
Matt Winn
Good. Damon, Will called out product teams. Any thoughts on that topic?
Damon Dageenakis
I'd say that all the artifacts, all the work, all the policy, that Will and the teams he works with have brought in have really accelerated what we do from a security standpoint for Mercury controllers.
We have our controllers on a continuum. They've been manufactured since the nineties. As we evolve that product over time, the next iteration of controllers, we have another iteration of controllers, a new generation coming out this year, we look not only at what we've done in the past as far as, all the components we put on board, all the application code that we run, etc. But now we have to pull in additional things that maybe weren't at the forefront of our designs ten years ago or something when we're doing that. So, a lot of the elements that we incorporate onto the boards, for example, we have secure elements, secure different types of devices that store secrets. That's really important and a big important part of the policy. As we develop new boards, maybe a board of ten years ago didn't have this type of hardened crypto hardware. Now that's something that's really as policy, something we have designed into the product. Same goes for things that we do in firmware and even up in our software, our drivers in our interfaces that we write. We have to ensure that we protect privacy and we protect the secrets throughout the whole system and that that drives what seemingly is a lot of extra work that we were doing maybe as a side job previously. Now it's really at the forefront, but it's been a great add and something that really allows us to stand even more behind our product as being something we're really proud of and we think is really going to keep people safe.
Matt Winn
Very good. Steve, anything you want to add to this?
Steve Lucas
Sure. I'll add from a customer perspective. The process and policies that we have in place, I mean, they're critically important to the product today and into the future. You know, when you look at Mercury, we're essentially an ingredient brand to our partner solutions, right? We're just one part of what they do, and we work with some of the biggest and best manufacturers around the world. Well, each of those biggest and best manufacturers have their own policy and standards that they need to adhere to from cyber and all the good things that come with that. By adopting and adhering to these policies, it only makes the product stronger and more secure, but it also allows us to more easily fit into their way of doing things in terms of delivering a fully cyber compliant product to the market.
Damon Dageenakis
And we have partners that are, at least over the past years, more advanced in this area. And we have partners that are less advanced in this area. So, stepping up our game is really helping to normalize that, maybe bring up some of our partners that aren't quite as skilled in this area and try to elevate our game up to some of our more expert partners and even end users. On the product side, we see a lot of questionnaires coming in. Cybersecurity questionnaires, they come in all the time from all different types of customers from end users all the way through our big OEM partners. Being able to go through and answer basically how we protect data, how we secure our secrets and all the other relevant security items. You know, these checklists take our security experts a long time to go through.
Now, we're much more proactive with that. So, we have that information at our fingertips ready to go. And much of the time, there's still things that we're continuing to grow and do better at. But our product and our whole policy and procedures over the past couple of years has grown significantly to where, again, we feel much more comfortable in the position we're at and providing solutions to our customers that meet security standards that are in the industry and even in neighboring industries.
Matt Winn
Will, bonus question for you. That's a lot to stay on top of. How do you do that?
Will Brown
Well, I rely on the product teams themselves a lot. I do work with Damon and his team to understand the challenges they're seeing. Like, “We're throwing this policy out — you're right. We're throwing these requirements and expect you guys to follow this.” And if you're having challenges, you have questions or your teams are coming to us and we're going down to help them with you guys. We do have tools and stuff in place that we are able to track people's progress in each of these activities. And, you know, when we do see some lagging behind, we're able to go down and talk to them like, “Guys, what's going on? Why is your threat model late?” We do have teams, we have staff at HID. And part of my team are security experts, or tooling experts, or governance experts or compliance experts and understand and work directly with these teams, understand their challenges.
Matt Winn
Good.
Steve Lucas
Can I offer a bonus question? Because I think it's important to what we now do within Mercury, but maybe talk about the relationship we have with how we're adopting some of those best practices, specifically around, you know, the operating system and driving the next gen product and what that means for us.
Damon Dageenakis
I'll start. Last year we did release a major revision to what we call our intelligent controller operating system. That board that we'd had previously and today runs Linux and we've had one version of Linux for some time in our products. Last year we worked with our partners at ASSA ABLOY, they have a team that their, their only job is maintaining a kernel, a Linux kernel that can be used across many different ABLOY based platforms. They have to go in and add support for processor A, B and C, for example, and we're using processor C, so they have demand coming in that says, “Hey, we're building a new product, we picked this processor, it's the best thing for us and we get support from that group.” Their expertise and their full-time job is to help support us and many of the other entities within ASSA ABLOY to basically run a secure operating system environment.
And then on top of that, we do our own work to ensure that that fits our purpose, fits our applications, and then we integrate our application code. So that's been a huge strength for us because that was more of a part time gig some time ago. You know, these days we have a full team that supports that and then we have our own security champions on our side that are product specific. And then we also have our security champions that look after all of HID.
Will Brown
Yeah, I'll add on that too, because with the security side, we have a different approach, right? Where HID is actually leading the product security and privacy initiatives within ASSA ABLOY. So, you're seeing other divisions. Look at how HID is doing product, securing privacy and incorporating our policies and standards into their divisions and how they're developing their products.
Matt Winn
All right, Good. Important torch to bear, I would say. Very nice. Very nice. Damon, you mentioned new Mercury products coming out. Let's talk about the product life cycle. What are your practices on that? Tell us more. Behind the curtain.
Damon Dageenakis
Yeah. So, a lot of things have transpired in the last few years. Well, if you look at supply chain constraints that we experienced and many manufacturers experienced, through that process, we really realized the importance of having alternate designs, alternate constructions for our boards.
In the last couple of years, in order to keep manufacturing products, we've had to redesign boards with basically the same solution, but using different chips that were more available so that we could continue to sell our product. And as we've done that, we've also incorporated multiple options within a new design. For example, if you look at Ethernet, you plug a cable into it and that's what helps communicate with the board. You know, from the whole system we have multiple options for those five. If we have a problem, it's basically getting a supply of one of them. We can drop another one. We also have dual footprint designs, so if we don't have a PIN compatible component that could drop in and replace another one. A lot of the designs in certain areas, like around our power supplies, have alternate layouts and it allows us, again, if we have problems with our hardware components, hopefully we have backup options that can then be put on the board and they just go down in a different part of the board. But the board from the start was designed to support that more on the firmware side, you know, we support multiple processors for both our intelligent controllers as well as our input output modules that are more downstream boards. We support and maintain a variety of processors on the firmware side. So again, if we have to swap out MSI use, which are the processors, we can do that.
Matt Winn
Steve, commercially customer facing. What do you want to add there?
Steve Lucas
Yeah. So commercially, the lifecycle is a very important topic and called an opportunity and challenge at the same time is that the life of an access control system on average is 12 to 15 years. People will install a product on a wall and it's sitting there forever.
I'll bet the first Mercury panel ever produced is still on the wall, blinking somewhere, opening doors, which is good. But if you're in this environment of ever-evolving security, ever-evolving new feature functions and things and want to move that product forward, something that was designed in 1999 simply just can't keep up. Because of this, we're seeing a shortening of the overall product cycle.
Instead of expecting a 12-to-15-year window for a system that is condensing more and more, it's the technology and the industry pushing us in that direction. And I think the industry needs to start to maybe accept that a little bit more and not think that a controller is going to have a 12-year lifecycle from an initial investment point of view.
Matt Winn
Change isn't always bad.
Damon Dageenakis
Yeah, I think we have seen that too. We have seen, a lot of our end users that will budget for a particular life cycle of a product. So maybe they never budgeted before and it was more an exception or they only did it for new buildings. But several end users, that I've talked to, have a particular cycle for their CapEx to bring in new controllers.
We talked to them about the need to update controllers every so many years because as security standards evolve, the need to put even more powerful and more secure components on the boards increases. You know, we need to turn those quicker and quicker. I think that the mentality as we see it is in some respects change with some of our end users to know that, every four years or six years or whatever that they can accommodate in their budgets, they need to potentially replace things from a security standpoint to reduce risk as well as just a support standpoint because we support products and we when we discontinue a product, we support that product for multiple years, but it's difficult to support it for 20 years.
Matt Winn
Sure. Will, I'd love for you to jump in, especially from that security posture point of view, because as mentioned, the security landscape is evolving, I would say, more and more rapidly every year. What are your thoughts on this?
Will Brown
I think the ability to adapt and be able to replace things more important is very important. And we've seen, you're talking about an embedded device here and these access control panels, right? I mean, eventually it's built on a Linux platform. And a lot of components within there will go end of life eventually. And so how do you support this device, which is relying on critical components that go to the end of life? And if those critical potencies have a vulnerability in them, how do you patch them? Right? How do you apply those patches? And so you have to be able to completely update your operating systems and libraries and things like that. But eventually you reach the point where the operating system is itself completely end of life. And now what do you do? Now the only support is to replace the operating system.
And that may mean that the new operating systems don't support the hardware that you're on anymore. And you’ve got a whole new platform you got to build out and release. It's very important for people to consider going forward, like how am I going to, you know, in 20 years I need to replace this period? Right. It's not going to take that long. The hardware is going to change. We run into it because you said changing standards and things like that will be a taxing change. Right? I mean, let's talk about what's coming out these days, AI has been really important, right? It's only important for us with capabilities and features. But there's an AI attack coming now and, you know, these hackers are leveraging this type of technology to do more advanced attacks. Well, if you're still on a panel from 20 years ago, it never even considered AI. as a threat. Where are we going to be 20 years from now? I think the ability to adapt is very important. And being able to adjust and plan for these types of changes is very important.
Steve Lucas
Can I just just add to that? So, you know, when you look at the access control world and what we do, I mean, Mercury Controller is a technology device, right? It has all this built in stuff to drive access control and cyber security. And it does all these things. It's not that different from any other technology device that you are either going to have on you or have in your house.
When's the last time, how old is the router in your house? I would expect it's younger or older. Younger than 20 years. When's the last time you upgraded your phone? You're not walking around with a ten-year-old phone. Maybe there's a few folks who do that, but it's predominantly not the status quo.
Matt Winn
Yeah, that's a good point. It's hard to stay one step ahead if you're technology is a few years behind type thing. Okay, Good conversation. Very important one. Let's go back to open architecture. And I think that we did a really nice job of explaining what it is and why someone would want it, but we are very fair and balanced on HID Connects. I do want to ask the opposite question. And Damon, I would put you on the spot to start. Are there any downsides to open architecture? Are there any challenges that our listeners should be aware of?
Damon Dageenakis
I would say that if you don't have really strong partnerships with open architecture, you can get a lot of finger pointing going on in the channel.
And by channel I mean, we sell to direct system providers, which are called OEMs, that goes to an integrator, that goes to an end user. And if the end user is having a problem, they're going to be going to the integrator to talk to about it. If the integrator comes back up to the system provider and the system provider is not closely collaborating with us, the manufacturer or they could be pointing a finger at us, saying the integrator, well, it's really their fault.
We could be doing the same thing. I think you see that a lot of times in open technologies where you don't have that type of collaboration and a really strong and kind of bulletproof specification as you can get, basically frustration down to the end customer because the customer just wants the problem solved. Their integrator is going to bat for them and basically the one on site trying to make something better. And if they look upstream and they see partnerships that aren't really good partnerships, then you don't solve the problem very quickly. We've seen that in the past, sometimes in different cultures, in faraway lands or we have less partners and less close relationships, stuff like that can happen.
And that is one reason why we're very select when it comes to who we partner with and how we partner. It's a narrow channel of system providers that we sell through, about 30 of them, but they're very strong and all industry leaders, and we ensure that we can scale and work with at least those 30 partners say, and we can create those solutions where we kind of are basically, in a sense, a lot of times it feels like we're one company because we're going to bat together. I would say that that's kind of the biggest pitfall I've seen in the technology game.
Matt Winn
Will, from a security perspective, any downsides? Are there things that people should maybe just be aware of as it relates to open architecture?
Will Brown
No, I think the perception we have for open architecture a lot of times is, well, it's open, so therefore attackers can see what's going on in there. So, they're more likely to find vulnerabilities and ways to attack that technology. That's absolutely true. But that also means that the good hackers are looking at it, too. And they're finding these issues and they're reporting or improving the technology. The problem with a closed system, for example, is that they don't know what's going on in there. I can't find the issues. And we're relying on the manufacturer's honesty. They're doing the due diligence and finding these issues and fixing them. And again, how much do you trust the manufacturer of that closed system?
Matt Winn
Very fair point. Steve, anything on the downside you want to mention?
Steve Lucas
I think I will add that, you know, when you look at a product, it's kind of a standard offering in the market. There's an expectation that that product can do all of these things and that the partners that you work with in turn support all of those things. Within the Mercury environment, if we have 100 features that can be supported that are a wide range of stuff, well not every partner we have is going to support everything that Mercury does.
Everybody has their own commercial ambitions with the Mercury product. You know, some are very heavily cloud focused, some are K through 12 education, some SMB, some all the way up to enterprise and the very, very big systems that are out there. You have this wide range and if I'm a K through 12 focused manufacturer, I'm not going to invest my time and effort to bring forth the federal government standards and the things in the big enterprise that maybe some other larger partners might. And so that becomes a challenge. Then when you look at maybe either an end customer that's trying to look at Mercury and look at the partner family, or even to the consulting community when they're trying to help guide them on a path to go down. And that assumption that everything is supported isn't always true, but it's known that it can be because it's again part of the standard that is Mercury.
Matt Winn
And just kind of rounding out the topic of open architecture, intentionally vague questions for we'll go down the line but Steve. I'll start with you. What's ahead? What do you see as the future of open architecture in our space?
Steve Lucas
For the future, I think one of the areas that we're focused on and it's going to be a big driver for us commercially is taking this openness and driving it down below the controller. Today we have a program where we have a number of different manufacturers. We work with elevator, elevator controls, wireless lock providers, intrusion, all these different third-party products that we can integrate into the Mercury controller so that it adds more value from a Mercury standpoint. But to our end customer, to our partners, they essentially get to consume all of this information through the investment they've already made for the integration of Mercury.
So, the more we add into the Mercury controller, the more valuable the relationship is between us and our direct end customer. If they again standardize on Mercury and make that investment in five years down the road, there's a new wireless lock manufacturer. There's another cool widget that should be complimentary with access control in one way, shape or form, then having the ability to rapidly adopt and bring that product into our environment brings them additional value on something they've already invested in.
As we look towards the future, and I don't want to steal a lot of Damon's thunder, I'll throw it over to him and let him get into the specifics, but we are creating an environment that will allow basically third parties to take control of their destiny, in terms of developing these interfaces. Today we have to do all of that in-house or most of it in-house, which means Mercury becomes the bottleneck, in the new world there will be a technology partner program that kind of gives the power to the device manufacturers so that we can scale much greater and drive that value prop both for OEMs as well as our end customers.
Matt Winn
Damon, it's your chance to reclaim your thunder.
Damon Dageenakis
I'd like to hit on the interoperability piece to that, because we view, in the future, our product as creating even more synergies across different types of components like the wireless locks that Steve talked about. And as we offer that to our collection of system providers, we are now allowing end customer to have choice not only for access control functionality, but as they look at adopting other periphery or neighboring technologies, the standardization, I guess that we make by supporting those devices allows them to have choice not only on the different types of devices downstream that they they use, but also the host providers.
And like Steve said, one of the pitfalls is, maybe not all the devices, all those system providers, support all those types of integrations in the future, making those integrations more and more consumable by our system providers is another big aim of ours. So that when you go to buy Mercury panels and you have a particular application you're interested in, you have choice across those system providers and it's more of a standard or more of a rule that they all support these types of integration versus only a few select ones.
We really hope, with this open technology development environment that Steve was talking about down more on the embedded side, more on the controller, that they'll really foster some collaboration and support for all those system providers working with those applications and those integrations.
Matt Winn
It takes a village. Will, same to you. What's the future hold?
Will Brown
I think one of the things we need to keep in mind here, we talked about standards, but let's talk about regulations quickly, right? And there's a lot of regulations we're seeing coming down, especially from Europe, for example, that apply not only to the products. We need to make sure if we're going to sell to the European market that our products are meeting some minimum security requirements. But, you know, our end users are going to have requirements placed on them. You need to make sure that your network is secure and you have minimum security in your network.
Your access control system is going to be on your network. In fact, it might be part of your security policy and how you're maintaining the security of your network. We need to make sure that the products that we're selling, the partners that we're working with, are able to help our end users meet their regulations going forward and make sure they're in compliance with all the laws that are part of them.
Matt Winn
That's a big, big hill to climb. That's cool. Very cool. All right, guys. So final question, 10 seconds or less. Damon, we'll start with you. Burning question for today and I'll half it because we already answered it. Open architecture is, I think we did a good job of defining it, but in our space, why does open architecture matter?
Damon Dageenakis
It matters because it provides people choice and it provides customers basically more extensibility in the future. I think with open architecture, we allow solutions to really extend in the future from a security standpoint, from an application standpoint, and that hopefully will allow customers to make one investment and be able to build on that versus having to rip and replace and add more money into their systems over time.
Matt Winn
Good. Will, why does open architecture matter?
Will Brown
I think it matters because it provides our end users and customers the ability to adapt and customize. It's just not one system you're locked into, right? You can adapt the system. You can change the system for addressing your needs and your security issues.
Matt Winn
Steve, those are good answers. What do you have to say?
Steve Lucas
These are great answers. I don't think I can top them, but you know, echoing that, it matters because of the choice for foreign customers. Again, when you look at an access control system, the physical side of an access control system, the controllers and all the downstream stuff, that's where 80% of the cost to install a system is. So, if a customer can standardize on that and not have to worry about changing it two years down the road or five years down the road, because they have the choice for device manufacturers to integrate with or they have the best of breed and best manufacturers around the world from a software perspective, then I guess that's why it matters. It's why it matters to an end customer.
Matt Winn
Very good. All good responses. Well, gentlemen, that brings us to the end of the discussion. It was a very in-depth discussion, but there's a lot of discussion going on in the industry about this topic, what it is, why it matters. I think that we were able to provide a lot of perspective, thanks to your expertise, your experience and your presence on the podcast.
Thank you all for literally flying in to join us in the studio. It's been a great discussion. That brings us to the end of today's podcast. Thanks again to our experts, Will, Damon and Steve for coming all the way from their corners of the U.S. to share their expertise and perspectives.
It really has been a pleasure having you all today, and I greatly appreciate you traveling to join us for our humble little podcast. Thank you. Thank you very much. And as always, an even bigger, thanks to you, our listeners, for joining us for today's episode. We truly enjoy creating this podcast and hope that you equally enjoy listening.
Of course, we'll be back very soon with yet another episode covering yet another topic shaping the security and identity industry. On that note, be the first to know when new episodes are published by subscribing to HID Connects, doing so will ensure that you stay connected, all you have to do is subscribe wherever you get your podcast.
And while you're there, shameless plug. Be sure to rate and review this podcast. Good ones only. Just kidding. We welcome all feedback, but you can also subscribe to us and see the video versions on YouTube and check us out on our social media channels. And in the spirit of connection, please send me your questions, ideas for future episodes.All you have to do is drop me a line at [email protected]. So, friends, until next time. Thanks again for listening. May your identities forever be secure.