In episode thirteen of Zero Trusts Given, Tom Tittermary sits down with Dr. Mark Taylor, Chief Innovation Officer at Sage Creek USA and former CTO of U.S. Special Operations Command, for a deep dive into what Zero Trust really means for the Department of Defense. The conversation unpacks the evolution from network centric security models to data centric Zero Trust architectures, with a particular focus on mission partner access, cross domain solutions, and data tagging and policy enforcement. Dr. Taylor shares hard won insights on why traditional network boundaries and CDSs often undermine true Zero Trust, and how identity, ICAM, and policy based access controls are critical to enabling secure information sharing across classifications and nations. The episode also explores the stark contrast between enterprise and tactical environments—where disconnected, contested operations demand resilient, local decision making—and why commanders at the edge must retain authority to adapt security policies in real time. The result is a candid, practitioner level discussion on moving DoD Zero Trust from theory to mission impact, at the speed of need.
[Tom Tittermary]
Hey everybody, welcome to another episode of Zero Trusts Given. It breaks my heart, but I am solo today. Typically, I have my co-host, Tom Gianellos, with us.
Unfortunately, he is doing much more important things than sitting in the studio and having conversations with me. He's out with a couple of customers today. However, this is a big one.
So, a guest that I've been trying to pull in here for a long time, somebody that is going to be really interesting and fascinating to talk to, I've got Dr. Mark Taylor with us. Dr. Taylor, could you please introduce yourself to the crew?
[Mark Taylor]
Hey, thanks for the introduction. Mark Taylor, I'm the Chief Innovation Officer for Sage Creek USA. It's basically a consultancy.
I support both the Department of War, CIO with the contract, as well as commercial entities as they come around. Specifically, I focus on high-impact integration of policy as well as architectural guidance. So, what does all that mean?
That means that I'm actually trying to help customers get more value out of the things that they're trying to do and map it to need. Prior to that, I was the Chief Technology Officer for Special Operations Command down at McDill. I did that for three years.
Before that, many years of tech sales. I was Chief Architect of General Dynamics. And I was an Army Officer way, way, way back when.
So, thanks for having me.
[Tom Tittermary]
It's funny how, like, the jobs and the resume that happened way, way, way back when, like how they end up coming full circle in so many different cases. I love also, like, Mark, I'm going to kind of give you a comment here, like, the humility with which you approach. Hey, I was the CTO of SOCOM, right?
But it's never, it's never, I never forget that it's, like, how interesting it is to be able to have a conversation with you about today, given that individual reference relative to your resume. But, yeah, I want to have you on today. We've had a couple of conversations on the podcast where we tend to bounce between topics, where it's always zero-trust related.
But we typically land on either one of two things. One of the categories that I'm looking for relative to zero-trust. So, identity, posture, data authorization, secure connectivity, policy decision point, policy enforcement point.
The other place that we go, because it's DOD, is typically this counterplay between what are real enterprise valid solutions in that context, and what are real valid tactical solutions in that context. The tactical ones are always the more fun conversation. The enterprise ones are always, like, the bigger user counts, the bigger flow-throughs, the bigger architectures.
But the tactical ones are always the more interesting ones. But that was one of the big reasons I'd love to have you, that I wanted to have you out on the show, is to kind of run down that side of the conversation, if we could.
[Mark Taylor]
Sure. Let's go.
[Tom Tittermary]
Cool. There's a really interesting notion that I'm finding in a couple of the conversations I'm having recently in DOD, where it's very specifically a mission partner context conversation. Like, how do I implement zero-trust with a mission partner when they have their own identity systems, and, frankly, they're coming from a different nation?
The notion that I've seen from a lot of the MILDEPs over time has been, hey, we would love to share this data with this mission partner, but I can't put them on the dot, dot, dot network. And that dot, dot, dot, they'll name a data classification. For this conversation, let's call it SBUE, right?
I can't put that mission partner on the SBUE network, right? And there's the same thing happening on the mission partner side. I can't integrate identity.
I can't put them on my classification network. So what will happen sometimes, it's the least agile thing ever. They'll create a third network, and they'll independently populate it from both sides, and the people that need to share data, and only those people end up living in that third network between the two.
Something I've seen super recently that is interesting is people are finally coming around to the notion of, hey, there's nothing about this network that makes it SBUE. The network's just the plumbing. It's the pipes.
This happens to be the structure and the boundaries that we keep all this type of data in, right? So that was why I couldn't put the mission partner on it. But I want to give them access to individual pieces of data in the right context.
So I'm seeing that application-centric or data-centric versus network-centric ability to share. I was just curious on your thoughts on what you've seen around that in the past and kind of where you see that individual piece going.
[Mark Taylor]
Right. So about 20, excuse me, and I'm going to date myself here, about 25 years ago, we had this problem solved at the time with a thing called the extranet. So if you're old enough to have heard the term extranet, essentially imagine a DMZ.
You have an untrusted enclave. You have a semi-trusted enclave, which is the DMZ. And then you have a trusted enclave, which is your network below your firewall.
Now imagine DMZ 1, DMZ 2, DMZ 3, and every single enclave in that DMZ XYZ is the extranet. So those are basically proxy third networks that you're talking about. So I can't get untrusted enclaves to communicate with trusted, but we can communicate in the semi-trusted environments.
That's the extranet. And that is how we solved world hunger, world peace, the whole nine yards a long time ago. Over time, like anything, security boundaries and enclaves changed, requirements changed.
They came up with different versions of the actual security enclaves that they had. And so we got back into this world of CDSs. 25 years ago, there were like three main cross-domain solutions, right?
Owl, Hissy Guard, Radiant, Mercury. Now you've got a bazillion of them out there, and those are basically what's used as the segment versus a layer-2 domain at the DMZ 1, DMZ 2, DMZ 3. Now you're going through independent cross-domain solutions to pass data at the same classification to a mission partner that you might go into a gunfight with.
So you see how, you know, that creates churn. It creates a time-to-value delta. But from a security classification standpoint, that's the security mechanism because it's a hardware-based solution that folks like.
So here's where we are in time. Now there's a war of religion. It's how many cross-domain solutions are we going to have versus actually have true zero trust.
If, in fact, I'm utilizing true zero trust, then theoretically, I don't necessarily look at everything as a network boundary, an enclave, which all the security controls are written to. But instead, I look at my data environment. So instead of a network, as soon as I say it's a network, now the network becomes the security policy enforcement point, whereas instead I look at the data and who has access to the data.
And so then I must provide a data tag or some kind of mechanism to identify the object by a data tag. Then I must be able to provide encryption per object that would be mapped to the data tag. And then finally, the data tag and the data object that has these things must then be properly mapped to an ICAM or IDM solution so that an identity for a human or an endpoint for a device can be mapped to the appropriate tag.
That way I can have a policy enforcement mechanism to make sure the right device or the right person is having the right access to the right data object. So that's a whole lot right there. No, no, no.
That's a career. That's a full-time job of a lot of people.
[Tom Tittermary]
I love when this happens. What's really interesting is you said a bunch of things that independently I knew, but the way that you said it made me have a different understanding of how this got to be the way that it is. So the reason that it's quote-unquote the SBUE network is the CDS is the hardware device that lives at the boundary that parses data by security level.
And it allows or disallows things into that individual Layer 3 network segment based upon its individual security level. So people over time, due to the CDSs living at the boundaries and that being the data flow component, started calling the networks that individual thing. However, what we're talking about, and I'm in violent agreement, and I want to dig into the data piece a little bit too, is that what that does, those CDSs at those network boundaries, makes it almost impossible to ever allow a mission partner direct access to.
And then you've got to build a third structure. You've got to build the carve out. And then those have their CDSs that have different security.
So none of that sounds agile in a lot of ways. And it sounds like the belt and suspenders move would be exactly like you're talking about. You know, from an individual file perspective, from a granular structured data database perspective, how do I get the tagging of the data as granular as humanly possible?
How do I have a uniform tagging of the data? And then how do I apply, we talk about this on the show all the time, all my policy decision points. So geolocation, time of day, impossible traveler, identity, posture of the device, all of those different things.
Should that user be able to access that piece of data in that context? So that's the belt. The suspenders of it would be, is that resource even reachable from another set of boundaries?
Can that resource, is there a path for the user to get to that resource before that more granular discussion of can they get this individual piece of data happen? So that's where I tend to line up on it. But it sounds like you do make an excellent point, though, that it is a religion conversation in many of these cases.
There's a couple pieces to it, right? So I tend to be really proud of a lot of the good things I've done in industry. And it's hard for me, it's really hard for me when a better mousetrap is developed or comes along that kind of subsedes that beautiful thing that I built.
So it's kind of like, hey, you can't talk bad about my kids type of thing is one. And then the other is, I mean, I started having these CDS conversations in the context of the IC specifically where there's just almost correctly so, like, just a lot more religion on the topic of data and how it gets shared. But we always come back to culture here, too.
Like, how do we pivot that? Like, I think everybody, once we have this conversation, sees like, hey, there's a better way. Like, how do we lead that horse to water in that way?
[Mark Taylor]
Right. So here's the thing. If you want to have zero trust, in order for that to be capable, you have to have a data tagging strategy, and you have to have an ICAM strategy.
And if you don't have everybody using the same data tags and the same ICAM, well, then you're just going to federate, right? Because that's what is required to get the zero trust. So it's a lot of things.
The very first thing you break in your network when you put a CDS in it is zero trust. Those things are kind of diametrically opposed. And so at the highest levels, we're trying to identify where is an appropriate place to put a cross-domain solution or a CDS into the environment such that you don't break zero trust.
Why? Because when your data passes through the guard or the CDS, you strip out your metadata, you strip out your tags, right? So that's a time-to-value metric on the other side.
So, you know, I find something, I want to pass it through here to a different security enclave. Now I've got unstructured data on the other side, and I've got to figure out how to parse through that. So then what do we have to do?
It's about education, and it's about policy. The education and the policy needs to be such that the environment, not the network, is capable of providing the same security controls with the capabilities that are native to the environment. So now if I have a data tag, I can get data that's this enclave, but you might not because you don't have through ICAM that same data tag access for that encrypted object.
Now, how is it that I will be able to have it but you won't? You need your policy enforcement point, right? So now that creates the space for new tech injected into the environment to have policy enforcement protocols and policy enforcement devices.
These things didn't exist 20 years ago because you weren't looking at trying to move things based off of policy. From a network protocol standpoint, we had route maps, things that you would use to have certain data travel through IGP into your EGP for BGP as your external protocol for those network nerds out there that would go outside of a normal- I have a feeling there's a couple of network nerds on the Zscaler-centric DOD Zero Trust podcast, so I think we're set. But the long story short is literally we're flying the plane while we're trying to build it.
A lot of these policies are in flight. They're being developed. And so you said something earlier about the object, and we have to make sure that you have data object encryption per object.
And so ultimately that's what I think is going to be part of the future, to have the ability to have different enclaves share the same environment. I'm not choosing the word network. And then have Zero Trust be a policy-enforced capability for different entities to access different data.
And so you call the different enclaves different data tagging environments, right? So then that gets to another point, and we can go down a rabbit hole, is before you had user and group access as your policy enforcement boundary, then they came out with RBAC, role-based access control. So I'm an admin.
You're marketing. My role allows me to have it. You don't.
Okay. Then over the last 10 years, you've heard about attribute-based access control, which is that but more granular. So we're both admins, but I'm the admin of these five groups, and you're only the admin of two out of that group.
So I have admin of more groups. That's the attribute differentiation. But now it's the new shiny, the new new, is policy-based access control, where I'm taking attribute-based access control as the enforcement mechanism, but it's based off of policy to get even more granular, and it is through the policy-based access controls that you will see the capability for different entities to have access to different levels or different enclaves of data that are contained within the same environment. And so that is the discussion, and that is where all of the new capabilities will be. And so the old heads, which, you know, I'm one probably, arguably, are going to argue because they're going to try to get back to old thinking.
They're going to try to get back to a network-centric way of looking at it. However, it's 2026. We have to get away from network-centric and on to data-centric.
It is only until we move to a data-centric policy and a data-centric view and approach are we going to be able to move data to the speed of need.
[Tom Tittermary]
It's always interesting to me the data. So, one, there isn't a standard taxonomy. I'm a broken record on this.
Right before we hopped in around DoD data in general, that's a noble goal. It gets very interesting and sometimes even in the conversation a little bit political, right? But you do make a good point that, like, to be able to get to this, you know, vision on a hill, we've got to accurately, we've got to come up with a baseline taxonomy for everything.
I always say, you know, we need like, you know, the old Charles Linnaeus binomial nomenclature style thing where it's, you know, kingdom, phylum, class, order, family, genus, species. Everything fits under a category somewhere, and there's always a structure that you could add a new category when one becomes available. So, we do that and we tag the zettabytes of data appropriately that live across the DoD.
Great. Now, we fully implement and perfect all of our identity-style solutions that are across there. Got it.
We coordinate host-based policy data across mobile devices, and then we kind of also do that for who we now need to account for AI energetic offerings and how they can access data and individual things. Like, there's a lot of underlay here that takes place, but at the end of the day, I think what becomes really interesting, it gets, when you talk about Zero Trust, it just gets really, really simple in that there's data you make the decision of access to make. And then there's the enforcement of that decision, right?
So, I could put as many things as I want into that policy decision point bucket as makes sense and can improve the security, right? It could be identity. It could be the individual, you know, value of the tag relative to the individual piece of data.
It could be the posture. It could be the geolocation. It could be the mission partner country.
It could be nation of origin. You can get as granular as you want in that case. The fun thing from the Zscaler side, and I try to say Zscaler as little as possible on this podcast, but on the far side of that, I'm just, I'm the PEP, so I'm the band hammer.
The decision comes to us and the path exists or it doesn't exist in most of those cases. But I think you've lined up where, you know, in each of those individual categories we just talked about, there's a static order that lives that's been built over the last 15 years that we're trying to get underneath the roots of to change in some way. I think a lot of folks that I talk to about this have the same vision of where to go.
It's the really hard part becomes like, hey, where do we start relative to that? And I think there's categories like the data side, there's a start. The identity side, there's a start.
The network side, there's – one of the big moves I saw was I finally landed in a conversation where it landed where, no, the network's not SBOE, the data is. And there was like a granular policy change relative to that. So I'm seeing the movement in that.
[Mark Taylor]
Yeah, it's all about the interpretation of the how. But then, you know, like any bureaucracy, it's all a matter of tearing down walls and getting everybody to agree without specific agendas, right? And that's, you know, for the government as well as corporate America.
You know, when you go to corporate America, different companies are trying to make sure that everyone is biased towards their solution. And so it's not – it's a big, hairy problem. I think there are technical directions to go down, and it's just something that we're going to continue to work and smooth out over time.
And, you know, there's going to be bumps along the way. It's not going to be a straight line. It's going to be a lot of course corrections to get there.
[Tom Tittermary]
Yeah, it's one of the harder things is, you know, I picked my path a long time ago where I'm on the commercial private sector side of this whole thing, right? But as an engineer, right, I had that choice to be like, am I going to be the sales guy or am I going to be the engineer? I'm on the engineering side because I like solving problems.
And the way that I end up – I'm biased, obviously, but I'm biased in a very honest way where I picked Zscaler because they had the best nerd knobs and the best tech for my opinion, and I felt I could do the most good with them. If I'm just going to open the kimono and be kind of honest sometimes, like from a private sector perspective, there's almost an instinct sometimes to over pivot and be like, hey, here I know I have the best thing, and I'm going to push for it. But this other thing also lives under the banner of my company, so as a good corporate citizen, I may want to push over on that side as well.
I try to avoid that as much as possible and just build the best possible solutions for customers. But just to validate what you just said, do any Google search on should I do this individual thing for my health, and there are 15 people that would be like, of course. But they all come from the companies that are selling the thing, so there's that weird competing intention behind.
[Mark Taylor]
Yep. I mean, facts.
[Tom Tittermary]
Yeah. So another topic. I don't want to do like a hard pivot.
I feel like we could dial these two together, right? So everything we're talking about requires, if I'm going to do real solid data tagging and authorization, that requires some kit. That requires some hardware.
That requires probably a lot of, if you can AI model it and GPU build it, great. It requires probably a bunch of flash storage to move the data at the appropriate velocity to have it happen and have it act in time. These all to me sound like architectures I've built for enterprise, right?
So I want to get to this enterprise to tactical conversation, because there's two main things that are happening there. One, the requirements and the needs of that tactical space are drastically different, for good reason. And two, I'm running into this in a couple programs I'm working right now where I will explain my capabilities, and the immediate questions back are, hey, what is the CPU and memory you require in order to deliver that individual capability?
And the number can't be big, because there's a million things they want to do in a very defined, pre-populated kit. You can't just buy more servers in that case. Those are the main ones I've seen.
If there's anything else to add to that list, or if you just want to kind of roll down those two and kind of qualify, you know, either of those statements.
[Mark Taylor]
Sure. So, you know, the Department of War, specifically SOCOM, you know, we tend to have and fight and prosecute war in other parts of the world. And what I mean, tongue in cheek, is that you're going to fight normally in a country that doesn't have good bandwidth, right?
You're not going to go connect to the local Internet. So you take your Internet with you. You take your connectivity with you.
And, you know, most people think the Earth is round. It's actually kind of oblong. And there's different metal deposits at different parts of the Earth.
And so what does that mean? That means that your comms don't always work as intended. And so what your radio max distance here, you know, in America might, and I'm making this number up, might go five miles.
You go to, I don't know, I'm making this up again, you know, Uganda. It might go to right. Not because Uganda is some crazy place, but they might have different magnetic pulls.
Right. So so things like this affects communications. You look at all the craziness of Afghanistan, just at those crazy altitudes where the helicopters couldn't fly as high.
So the environment gets a say on how your communications will operate. So you got to understand that first, that that where you go will or can potentially affect how your devices work in a lab field tested. Right.
So that's a then you got to identify, well, what's enterprise and what's not enterprise. Right. So a common thing that I would talk to CIOs about is, you know, Excel.
You got an Excel spreadsheet. I raise your hand in the audience. If you've had an Excel spreadsheet that was used by everybody in the company as the source of truth for this thing.
OK, so I know I could use Excel and do my my my laundry list or I can come with my grocery list. So when I do it as a grocery list, it's a personal app. Right.
For a user. But when I build all kinds of macros and now it's an enterprise app. So you have to identify, well, what is the app?
What is that doing? And so you have to understand that. So then you got to apply those two things in conjunction with a mission.
And you have to try to figure out, well, what is it that I'm doing that I need to be able to get back from the tactical edge to a strategic enclave? Here, we might look at any geographic combatant command that's outside of the continental United States to outside the continental United States. CONUS versus OCONUS.
They might look at OCONUS as that's tactical. Well, I can tell you, looking at a four star headquarters in Africa, all the way down to a maneuver element, there's a whole lot of of levels of headquarters and and and compute and storage in that in that vein. So then it's about defining the very smallest tactical piece, probably a squad size element, and then identifying what is it that must operate in a detailed environment, which basically means your connectivity back to and through the Internet or some kind of circuit back to OCONUS or some higher level headquarters is is cut off and you can still operate locally.
So you see how this is a long wind up just to get to the tactical edge. Right. So then it's about what is it that I have to be able to operate?
So I need to understand what are the applications that I need to be able to operate? Given the fact that I can't talk to a higher level command, that list is get smaller and smaller and smaller. The further down you go.
So then what are the things I need? Well, this is the reason why there is the whole discussion about zero trust OCONUS versus CONUS versus cloud versus no cloud. Because if I put all of my identity in cloud, like in TRID, but I'm in a gunfight in the mountains of Afghanistan, I'm probably not going to be able to get authenticated with with with a CONUS based identity management system.
I have to have enough identity local or in my own box so that I can log into my stuff. I then have to have the ability to get access and proper permissions to the stuff that I'm going to use laterally. So you see how there's there's levels to this whole thing.
So to me, given who I've supported over the last few years, I need to be able to get down to a maneuver element that might be in a gunfight. That's tactical. When it starts getting to a strategic level, that's when it's going to get back to what I would call a hardened or semi hardened site.
It could be on the back of a Humvee or could be in a safe house or it could be on a local in theater base, in which case now they can have discrete servers and potentially have cooling and and and conditioned power for that environment. In which case now it's got reliability and it's got redundancy and it's got survivability, which means I don't have my primary and my backup next to each other in the same rack. They're they're they're physically separated, you know, by hundreds of feet.
So a mortar round doesn't take everything out that that is the way that, you know, I have to think. And so or or I have been thinking I've been architecting. And then you look at, well, what is the application?
The application must be able to live at its smallest element, but yet have the ability to reconnect and extend once it gets enough bandwidth or it gets the connectivity back to the strategic environment, at which point in time it will send the diff. It will do, you know, a CRC check. It will do some kind of checksum.
It will do some kind of mechanism to make sure that it is now recalibrating, reconnecting and making sure any updates it will send back, whether that be through some kind of Q mechanism or whether it be through a discrete push.
[Tom Tittermary]
I think you just landed on it. It was it was funny. I was thinking about taking this conversation a different way.
But you just landed on when I'm working with other technology companies around what these detail components look like. So from my side, like when I'm trying to build these individual tactical components. Right.
It's got to be my my phrase that pays is it's got to be Nokia brick phone resilient. If if it's grunt simple, better. Right.
If I could put any operator in front of it and it makes sense in the context, better. And then the third one is that from a detail perspective, it's got to work connected or disconnected in those cases where we always, always land in this scenario. Having some of the most interesting, difficult conversations are the race conditions relative to.
Well, no. In the tactical scenario, I had to make a change to the identity system or I needed to change or data was ingested or. Right.
And it conflicts with the enterprise policy. Who wins and how does that work and what does that look like? Right.
What I'm seeing is in most cases that people are looking at the local identity and the local policy as the source of truth informed by the enterprise. So then that way on the reconnect. Right.
If there was, you know, individual identity changes that happened based upon the context, they'll revert back to normal or there be a note of an exemption at the at the top level to not override the local, but note it from a logging perspective. But that gets to be a really. So let's say that, you know, you've got folks in a kinetic situation forward and they have to share data with a local mission partner and that decision happens locally.
So the identity changes locally. Now the wires go back up, but you get connectivity, but you're still kinetic. Are they going to lose connectivity in the middle of the scenario because they don't match the enterprise policy?
Like those become very interesting conversations that I've gotten to have over time. And how do you build technology that kind of manages those types of situations? You got it.
You have to account for it in some way. You can't just, you know, crush fingers, hope work.
[Mark Taylor]
Yeah. So all of the policies I support in the Department of Work, I always make, you know, that have some kind of technical widget, use case, whatever, whatever is coming through that that I might work with. I always make sure that I put a statement up front or somewhere that's germane to the document that essentially provides.
However, you know, I'm ad libbing, however, the local commander or leader gets the discretion to make the change as needed, as required by the mission. Why? As a lieutenant of a platoon in the middle of a gunfight, you got to remember the enemy gets a say.
Right. You know, based off of the time, the terrain, the tactics might change of the enemy. The enemy gets a vote.
Right. They don't show up on the map at 12 noon and get shot in the face like they're supposed to, according to our op board.
[Tom Tittermary]
Right.
[Mark Taylor]
They they they do their own thing. Sometimes they don't listen. And so if we allow young officers and young NCOs to change on the fly in the middle of a battlefield condition or kinetic to make sure that they're successful.
You look at Chamberlain, you know, and remember the book Screaming Eagles, the Ballagettis Berge put everybody on a line and had them basically attack downwards in a wheel motion. And it broke the back of, you know, the Confederates. He made that up on the fly.
And, you know, that's all I can figure out. Well, you know, you're going to have to come up with things on the fly as needed to make sure that you all don't die and you achieve your mission. Why do we hold our I.T. and our comms to a different standard? Right. So you've got to give the commander you've got to give some folks the ability to change as needed. And then at such point in time that you are in a posture that you can change it back to whatever's air quotes more acceptable than then do so.
[Tom Tittermary]
Yeah, you just landed on the I mean, one of the most interesting pieces here is, you know, we're talking about data that's wildly sensitive. So I think that's where most of the religion comes in. And most of the why can't give them the opportunity to make changes on the fly relative to who gets what.
So that's a wildly complicated problem. There are lives at stake in the scenarios that we're talking about in most of these cases. I think the whole thing just goes back to.
So I'm going to use this kind of as a as a as a rapper to kind of wrap this up. It's been a phenomenal conversation, but I very much appreciate the opportunity to get to have these conversations and to try to solve these problems. Because obviously the the effects on the far side are are pretty impressive.
Obviously, pretty important at the same time. But one, I want to thank you, Dr. Taylor, so much for coming on the show. I obviously I want to invite you back.
I know we were talking before the show about, you know, having a conversation about post-quantum crypto. I think that'd be a really fascinating one. I'd love to invite you back.
You don't have to answer now. I'll see if we could work it out on the on the scheduling. But thank you so, so much for this conversation has been really enlightening.
I'm sure everybody listening would would say so at the same time.
[Mark Taylor]
Awesome. Thanks for having me. And I look forward to coming back.
Talk about post-quantum cryptography and hopefully bringing some folks from tectonic labs to help me out.
[Tom Tittermary]
Excellent. So. So, hey, everybody, one reminder on the way out.
We do have kind of a commercial email address. Zero Trusts Given. Trusts with an S.
Zero Trusts Given at gmail dot com. If there's anything you heard today and you'd like to present a comment on, hey, we need more Tommy G back. He can't miss any more episodes or Tom Tittermary talks too fast.
Any of those things. We'd love to have that there. Also, if you ask a question in that email and that we end up addressing it on the show, we're talking about it with marketing on the back end.
We'd love to get you out, obviously, within the government maximum care package from the Zero Trusts Given show. A couple of fun things in there. But again, once again, from my side, unfortunately, I don't have time to say goodbye as well.
But, Dr. Taylor, thank you so much for coming today.
[Mark Taylor]
Awesome. Thanks for having me.
[Tom Tittermary]
All right. Thank you much.