Passkey – What’s next?

Good. Perfect. So I'm going to start right away.

So guys, thanks for listening in. So I'm really excited to give you some insights about our journey. So maybe two words about myself. My name is over there. I'm Martin. I'm the technology officer for the Merck KGaA, for the global IT, which covers to a certain extent identity and access management as well. And what I would like to show you today is a little bit the thinking path. What are we doing on the management level and how do we translate this into a classical operational execution layer?

And Passkey is a fantastic example because it's covering identity management and security at the same time. Good.

OK, let's go through the real life example. So when you look at the classical evolution, which is, by the way, the topic of this conference, what do you see here? We are applying the software lifecycle development part here.

Plan, do, check, execute. Everybody knows about this. What does it mean? Simple to say. A big struggle with – one second. Why does it not show up? A big struggle with cost, time and scope. Always in a struggle. Way too expensive. You are managing things in a horrible manner. You are always facing some issues with quality. You are not delivering the requirements. You are always debating with the business. So literally it does not really evolve. Some people try to escape where? They try to escape into products. Products are expensive. So we have a kind of price increase all the time.

You are losing people. Why? Because people don't want to be with the product every time. They would like to be a bit more agnostic. So what happens? You finally build a church. So that's an AI created image. So you can copy that. No big issue. But what does it represent? It represents the Cologne Monastery. And if you look at this detailed picture, it's constantly under construction. That's how software meanwhile is, especially in the identity space. You are building churches constantly under construction.

Yes, they have an intent, but literally that's nothing you can manage. And the second part is the quality is normally always under average. So I guess that's the history of identity management. And then the big change came. What is the revolution that you see meanwhile? It's literally that. When you look at identity management, it's not about the process. It's not about the identity. It's about the security part. When you talk about cyber, quality all of a sudden is irrelevant. The impact and the risk becomes relevant. So that means you need to change the approach.

You definitely need to all of a sudden talk about identity as a risk. What does it mean if we don't control it well? What is the result we would like to achieve? And how do we use the identity management as protecting the company? So that's really, really way more important and it's totally changing the game. You establish a new security posture, assets, identity, device and data. These are the three pillars that we see at Merck and you need to tackle them somehow in a different manner. And one integral part of this security posture is what? It's literally the PASKE solution. Good.

So how do you tackle that? I guess get away from requirement analysis and stuff like this. You need to create a vision, a really, really strong vision that finally defines the vision. So we are not looking backward. We only look forward. And I call it, some people might have heard about that, the moonshot.

Now, when you look at the moonshot theory, it's something very simple. The NASA, they defined we would like to go to the moon a year, I guess 50 years ago, without really knowing do we have the material, do we have the people or stuff like that. So they were thinking about, okay, that's what we would like to tackle. And afterwards we start discussing with our real experts, what are the baby steps or the intermediate steps to really get there? So that's a totally different approach and that makes it, I would say, way more agile and finally successful in this case. Good. That's our revolution.

With every revolution, you need to have some kind of starting point. So I said, okay, to my team, let's get away from some requirements. We talk only about guiding principles. So the no-goes or the definitely-to-goes. One for me non-negotiable part when you're a company who would still like to own IT is control versus trust. What does it mean? When you look in the security space, one of the biggest mistakes that every company is doing, they trust. What does it mean? You are trusting against third parties, big SaaS providers. I don't want to name them in detail.

The moment this trust is broken, what happens? You can't undo it. Literally leaked credentials, attack surfaces that really all of a sudden get exposed.

So a big, big issue. So what we decided on for certain topics, yes, we trust with certain companies, we have good vendors in-house, but be honest, give a shit about any SaaS solution in the cloud. Why? Because it's only causing problems later on. And you really see it meanwhile happening very often. So we believe what's really important is control. It's not about controlling the employee or controlling somebody else. You need to be in control of the identity end to end where pesky, and you will see it in a minute, is an integral part. So that's fundamental.

The guiding principle that I always establish when I take a decision. So that's not negotiable. Next guiding principle, it's all about people. We managers always think we are super important.

No, we are not. The game totally changed. It's all about empowerment. What does empowerment mean? I only talk about the what with my employees. I never define the how. So they have to define with their own empowerment and also engagement, how do they get there?

Yes, I can give them some guiding principles or some guidance from, I would say, left and right. How do you get there in a good and controlled manner? But finally, they are accountable for the result. So this empowerment, literally what do we do? Flat hierarchies. That's really important. We don't need to have these biweekly meetings, show me status, green, red, yellow, the typical watermelon, inside red, outside green. We totally skip that. So really make it agile. Do it in a kind of agile methodology and give the empowerment to the contributor with rewarding, which is also very important.

Security by design. I guess many solutions that we implemented in the identity management space were more about the quality of the implementation. Was it done well? Did we develop it on time and stuff like that? That's really irrelevant if you ask me. You need to think about security by design. When you now take the example of Passkey, what does it mean? Passkey is a revolution. It's replacing the password, so a secret which we will use the last 50 years on. So if you now think you can replace it like to like, no, you can't.

You really need to think about, okay, what do I want to achieve from a result, which is maximum security at that point in time? So that means the architecture, the design and stuff like that, they need to create an avoidance of the risk. So that means that certain things like phishing or stuff like that are not possible. That means we are including in our architecture security by design. To make it with a real example, everybody's talking about MFA. Everybody's talking maybe about Passkey and is using an authenticator app. An authenticator app is not secure. We can discuss that easily.

It's not phishing resistant. It's a vendor, yes, like it or not, but that's not security by design. You're creating literally a security solution that you later on need to mitigate. So I was building the socket mark, so the instant response and the threat hunting team eight years ago. And the worst thing that you can do is deploying security relevant components, which are creating work for them. It's totally ridiculous. This doesn't scale. This doesn't work. You need to create or you need to deploy solutions from a guiding principle perspective, which are totally avoiding the risk by design.

So you literally need to go to the root and try to eliminate it. So that's fundamental when you talk about security by design. Agnostic and robust design. My head of IAM made a good sentence. It's the golden birdcage that you need to avoid. So why? The world is meanwhile complex. Pricing is changing constantly. Adoption is complicated. So what do you need to do? You need to build containers. Build containers that you can move them around. You need to be agnostic when it comes to a platform. You need to be independent from some vendor lock-ins. Why? Otherwise you don't own it anymore.

When you don't own it, you can't control it. When you can't control it, you have to trust. And the vicious cycle starts. Robust designs mean what? Zero downtime. We are a shop floor company. So we have power plants. We have a bioreactor, stuff like that. It's not negotiable. There is no downtime. So you need to create something which has always uptime in a different manner. And this only works with a very robust design. Good. Open technology standards. Only why proprietary stuff is causing headaches. Take Kerberos, take NTLM, whatever proprietary protocol you take from the past.

You always talk about how do I mitigate once a vulnerability is found. So really focus on open standards that are defined in RFC standards. Try to understand them. Try to get to a vendor which is offering them in a very transparent manner that you are very close to the implementation ownership. Good. And that's my take here.

We never, never share credentials in a third party SaaS solution. We go cloud for sure. We have co-location, we have AWS, all those things. But we never, never share credentials in a cloud. And I tell you why. The example is the banking problem. When you have an asset that you really, really like, where you have a value which has a price on top, you put it into a locker in a bank. The bank itself always becomes a target. Not you are the target. But the problem is you are taking the consequence. And the only thing that can be protected is literally the price but not the value.

So they will refund you the price tag finally but the value is gone when you have intellectual property or anything which leads to intellectual property, you are really, really in a problematic situation. That's the reason why I said, okay, anything which defines access always stays with us. Good. Let's translate those guiding principles into I call it blueprint revolution and I just picked out a few success criteria that made our teams and the product that we developed over time really successful.

Formerly, we started like every company with IAM experts. What is an IAM expert? Nobody can tell you.

Yes, somebody who is certified for some product. No, not at all. What we really need is an SRE, so somebody who understands the cloud, somebody who is able to orchestrate a CICD pipe, somebody who understands development principles, stuff like that. So real IT guys. That's the success. I still remember when I went to an external company and I told them, listen, you will build identity management for us.

He said, no, I'm a Java developer. What the hell do you want from me?

I said, the part of identity management is so small that I will teach you this on the fly and it's way more important that we talk about robust IT principles, real informatics and stuff like that. Code. People always said customisation, customisation. Everybody knows the nightmare of customisation, sometimes specific languages, old code, no code.

We said, no, skip it. You can develop from scratch. When you start developing from scratch with the classical methodologies, you can harden the code, you better understand the code. You're not so vulnerable to supply chain attacks like we saw in the last 12, 18, 24 months because you have full transparency. So development is key and you get way better resources, by the way, when you work with real developers instead of customisation guys.

The core, I guess we still make the mistake in the identity management space. We are rule-based. We believe we can define what we know. That's totally irrelevant. When I look into the real threat that we are facing, and trust me, I'm part of many SOCs where we see real threats, the adversaries, they only work in the dark field. So they literally never use a vulnerability. They only use zero days. So that means what you need to do to detect them is what? It needs to be data-driven.

You need to be behaviour-based and based on the behaviour, you need to find some kind of detection mechanism that gives you some insights on that. The same applies for identity management. We are a global company. We are in almost 200 countries, I guess, and it's not possible at our size to define the right on-boarding, off-boarding process everywhere. It needs to be data-driven, and this really improves things. Good. Building blocks. We try to avoid products. Why? Negotiation, buying them is quite complex. We try to skip it. We only focus on open-source and full-stack.

We made very good experience with this. You take hardened products in the market and try to build them as a building block inside your global solution, and that's the same what we apply for PaaSKey.

Data, yes, we come from a classical model, extract, transform, load. The data is normally shared. It's in a kind of relational database, I guess. That's okay, but it doesn't scale. So what do we do? We have stateless principles. The data is self-owned. We created our own data lake. We created our own data graph. Why? When you look forward into the AI stack, what does it mean for AI? The winner in the AI field will be the person with the data. Why? Because you need to have the data to train the model.

Once you start training the model, you can start supervising in a certain methodology to take decisions, and this only works when you own the data. Good luck taking out data of O365. I guess the retention rate is what? Three months, six months for an expensive price, so you can't take decisions on that. We have data, I don't know, eight, nine billion data points, and with this, you can really now start training models. Good. Now coming to the topic PaaSKey, we created an initiative called Moving Beyond Passwords. What does it mean? Get rid of the passwords.

We don't want to have passwords because the management of the password is really complex. It includes a lot of threats, and it also has a high, I would say, impact on the security. I'm not a big fan of user education. Why? Try to take the user out of the equation. So it's not your job as an employee to literally be inspector gadget and look if the email is legit to see if I may enter my password, stuff like that. It's like in a car. When I use my car, I drive very fast. I can trust that the airbag is working. I can trust that ABS is working and stuff like that. So that's the approach.

So from an architecture real quick, so technical details can be shared afterwards either by myself or the IM if you would like to. So we are using a StrongKey appliance, so that's an open source product which we have deployed worldwide. Inside the StrongKey appliance, we have an identity wrapper created in the FIDO2 server, and that's where we store the secrets. So literally all secrets at home, we have all relations with this, and that's very agnostic. We could move anytime somewhere else if you would like to, to have the relation employee or user towards the passkey.

So it's not stored in the classical SaaS cloud. Credential portal. When you have all of a sudden a passkey deployed, what is changing? Something fundamental is changing. The registration process of the passkey all of a sudden becomes critical. How do you ensure that somebody is able to register a passkey without being intercepted or stuff like that? We created our own onboarding portal with some security features, very custom towards our environment. We created something we call advanced protection.

With advanced protection, we are able to bridge the gap for, I would say, technologies that are not very forward thinking. So all legacy stuff, we created something called detached authentication, and with this, we are able to literally bridge the gap here. Good.

Next part, ADFS. We are still in a hybrid company. We are still relying, to a certain extent, on Entra as an IDP, and for that, we had to create in our hybrid authentication architecture some plugins that's working out to somehow make it useful. Good. Now something very important. The first three points were very technology driven, but the last point is more important. The rollouts took a few years. Why did it take a few years? We have change management here. People need to forget about the password and they need to learn what it means. There were a lot of questions I expected. Wait a second.

I now have a pin. Wait a second. Where is my biometric data?

Blah, blah, blah. With a very strong, I would say, approach of change management, which literally translated into all the small parts that you see here, I won't read them out, was finally making us successful. We can now say we are a fully fledged passkey company. So we have a rollout quote of almost 100%. So good luck with fishing our passwords. From the outside. We don't care if anything is stored in a third party cloud because somebody registered with a Merck account. You can't make use of the passwords and stuff like that.

Okay, guiding principles really quick in context of the passkey that you see, control versus trust. Like you saw in the slide beforehand, end-to-end ownership. So we own all components. We can look into all components. So nobody is literally operating those things for us. And we have the whole overview on data. It's FIDO device-bound what we've implemented. So that means you can't move the passkey from A to B, which is now forced by Apple, as one example. Security by design.

As I said, take the end-user out of the equation. Try to eliminate, I would say, the expectation that the end-user with his behavior is improving or declining the security model. That's not the intent. An end-user or an employee should do his work. His job is not to be the civil guard of security and be somehow looking into certain things. Are they working out or not? Worked quite well, I must say. Agnostic and robust design. The ICD pipe is really simple in the Kubernetes setup. We could move if we want to. Gives us also one big thing, cost avoidance.

Price tags are everywhere and we can quickly react in case we are not really seeing a value in this case or it's too expensive. Open technology standards, FIDO 2, so something which is RFC based and you can work against that we can directly guide people into that. Good. No credentials. I just showed them. We have some appliances that we deployed here. Good. These were the guiding principles.

Now, next, where do you find passkey in our identity stack? I forgot about one guiding principle. One guiding principle is one functionality, one system. I don't like systems that have multiple functionalities. Even if you would now say, but why? Quite simple. From an operational perspective, having this independence forces you on the one hand to build interfaces and on the other hand, it's giving you way more flexibility from an operational approach here. The area where we have passkeys applied, credentials for sure.

We allow bring your own passkey and the passkey itself is storing the credentials accordingly. We have a credential portal. How do you register your passkey? How do you recover it? How do you use the passkey for other authentication related stuff? Something which is really cool, it's currently not yet fully deployed, but we are in development, real-time anomaly detection. By having non-passwords, so the attack vector will change. People all of a sudden will look at the passkey as that's where to go, either the device or something like that.

We are currently building a large language model which will give us anomaly detection. What could be an exploitation that we don't know about?

Again, here from a security principle, quite simple. It's not so important what you know. The attacker always comes with something you don't know and the question is, are you quick enough to put it into context and able to react? If that's fine, then you're good and that's something you won't find in the market, so there is no product. There will be no product, I guess. We build it on our own. Development is something I would say which is from an effort perspective quite reasonable and that's why we did it. When you look at the process here, passkey, where do you see it?

Left in the identity data we started. Integrity is the first time where a user puts in the passkey. Device security is the second time. The software client is the third time and application is the fourth time. You have multiple views where you literally have an integrity on the end user. What's next? That's the last slide and then we're good. The three things that I believe come in the next 6, 12, 18 months enforce device-bound passkey and all device types. I guess the big beauty on a passkey is that it's bound to a device. Some suppliers try to work around it.

We will now reverse that and ensure that the passkey is only device-bound and therefore stays phishing resistant. That's one very important part that comes. The second part, protect the token and the cookie. Everybody talks about the authentication itself which is now protected but it translates into something which is a standard cookie in the browser. The browser is the new attack vector. What does it mean? You must establish a protection on the browser. Either we establish a company browser, take Chromium. Chromium has normally between one and two critical vulnerabilities per week.

If you don't control within the Chrome browser, the browser extension, the risk is very high that the credential means the cookie is leaking out in a very weak encrypted manner and the attacker is bypassing anything which comes with the authentication. So that's something you need to look at. If you don't look at that, you have a real, real risk very soon. Good. The next part, large language model. I already mentioned a bit. I strongly believe in authentication where it makes sense. So that means behavior-based.

We will enforce authentication when we believe from our LLM model a risk increase is happening. It's not this travelman-salesman problem that's bullshit, that's kindergarten we would say in Germany. Real behavior issues. Something you simply don't know and only the model tells you. So that's something where we are working on. Good. That was it. I tried to hurry up a bit. I made a bit too much slides. Appreciate that. Thank you very much.