Just to give you some more background of who we are, where we come from. I just mentioned we're a science platform. So we are focused and specialized on Siam. And we see identity not as something that you have to have and something that has to somehow work a topic. That's only for the security people in the company, but identity is actually the front door to everything your users will do. And to every interactions your users will have with your platform. So it's critical to make sure that this front door is not only secure, but also a great experience to walk in through.
And you all can read those numbers for yourself. So I don't have to go through them, but just to highlight. So we were actually founded as a developer centric tool from there, we abstract it. So those 25,000 customs, you can see here, point out actually users, mostly for their own applications, making sure that the services they provide to their business partners and customers just meet modern, your and security ex expectations.
But of course, also we brought up in the last eight years to cover employee cases, how to make sure that your, that you increase employee adoption of new tools, you bring in how to make sure to give them a great experience.
And so with those customers, we work on having this great you access great experience. We're also happy to see that we have the security insights to really differentiate on automatically. What is a malicious login? What is a trusted login?
And this is a key piece I'll go into a bit more detail later on, which is just crucial for us as a platform to make sure we know our customers. And we know when to challenge them with additional security when to NA them. And when you just go on and give them a great experience, they serve when accessing our app. But that's enough about OEO. We're here to talk about user experience and security and what we are seeing in the market. This is just a siding of a study, PW seated on experience. They themselves call it experience is everything and that's truly, or that's very true.
Nowadays.
You can see some stats, some facts, some figures, but in both directions, positive and negative, we can see that the user experience your customers have with your solution, you will either win or lose customers and win or lose customer trust independent of the security aspect. So if we think on a positive side, you can actually observe a 16% price premium.
If, for solutions where customers say it's a great experience. So it actually is on your bottom line. If you have a great experience, you will get more revenue from your customers. You will also get more data if they trust your experience and trust isn't, or oftentimes for an end user, isn't about security features. It's not about the certifications you have, especially not gonna be the seed scenario, but it's about how the solution look and feel. Is it consistent?
Does, does it do any weird jumps where I'm redirected to a weird page?
I wasn't expecting these are all things that built trust with your customers, but also on the negative side, we can see that a lot of bad experiences are abandoned. And if you just think about yourself, if you just think about apps you might get or specific applications, you will probably observe as well that if an app doesn't do what you expected to do, you'll probably look for an alternative, or if it doesn't satisfy the need, you have strong enough, you will just abandon it.
And this becomes more and more through in B2B scenarios as well. So no matter if your end user is a customer, your own employee or another business, every in the end, it's always an individual sitting in front of that app. And this individual just expect a great experience. So they find it intuitive to use your application. But also on the security side, I don't have to tell you that I am pretty sure that you are familiar with the security channel cause we're facing.
We had a lot of great talks before this one.
We will have a great, great talk after this one, going into why cm is important for securing your services. We just see that there are so many different new attacks that you have to prepare users from. And just having one single data bridge, just, just doing one era in this whole story can lead to a lot of lost trust and a lot of also negative consequences in terms of fines and all of that kind of stuff. So in fact, we see over 40% in peak times, over 40% of all those four and a half billion logins we have on our platform, we see are malicious. So it is a everlasting threat.
And you have to anticipate that you can't just go on. What's the best experience for my users with no compromises insecurity. So if we think about security versus user experience, we have to think about what is actually the part of your act that sign covers for you.
And usually it's this three, three and a half step processes first around identity verification, making sure who is your user authentication. If you want to put it into more technical terms, then we have the access control layer.
So making sure that your users can only access those portions of your app, that they're allowed to the governance piece. And this one is crucial because you could do that outside of your identity system. You could just build something around that, but there's no better place to determine what your users can access than within the very first interaction you have with them. Because if you're getting it right in the science tool, you don't have to worry around it, about it in all your downstream tools to make sure users can only access what they want to access.
And then the last piece, especially when we think about customer facing applications is around data acquisition.
It's not only enough to know who your users are and what they're allowed to do. You also want to know who is my user, how are they interacting with my platform? How can I make sure that the services and options I present to my user reflect what they're interested in? How can I make it intuitive to build my app, which is crucial in UX, which actually can be supported by a good science tool and all of that will lead into the head over to your end application done.
So you also have to make sure that after you've done all of those steps, the page that you use and up on in the end looks and feels the same, like the whole process before, which is just also crucial to have this consistency factor in your, and to walk through each and every individual layer starting with identity verification.
The big problem here is usually twofold for your business customers. It's option overload.
So think about a relatively small app and you have 50 different customers who all want to sign in with their own Azure active directory, active directory, Okta ping, federate, whatever you have as an enterprise identity system. How can you make sure that these users can access your app in an intuitive and simple way? And what we found when talking to customers is a very simple measure you can use, which is called ID first verification ID first login, which means you users first give you just the email address and you can dynamically route them to wherever they should end up afterwards.
So if I ask or zero access your application, I can only see login with Google because we use TSU internally. But if you see any other corporate customer there, they only see the options that fit for them.
So you make it very easy for them to access your application. And it's a very guided process of taking users by the hand and putting them in the right place to access your application. But also if we come back to a more B2 C centric case, the number one reason why users won't access app anymore is because they lost their passwords. So we all know that passwords a huge security threat.
I think there's no major company that deals with security that doesn't say passwords are a huge attack vector. But also if we think about user experience, not ha or having a password means that customers are prone to forget that and prone to not being able to access your application. And even if you have great processes around password resetting and user self-service on reclaiming that password, you still introduce friction. So password mass logins are great options to make this initial step off at any verification, very intuitive and easy for your customers.
So you just sent them out an email, sent them an SMS. They have this one time code and whenever they sign in, they basically get a new credential to sign in with. And they don't have to let rely on just their email address. And then after we done all of that one part that's often overlooked. And this is also to go into all the other talks you hear about science ready while you need a managed tool is to handle exactly such edge cases like account linking. What happens if you user science move the email and they sign in through Google social provider, or they said they even sign up with that.
You need to have a tool that puts all of this information together and to get you a unified user profile, not only for your own analytics, but also to make sure that your users have a great login experience and that they don't see data when they, or some data when they're signing with the email, but completely different data when they're signing with Google because you can't match these users.
So identity verification, it's a lot about reducing friction, making it as simple for users to sign in and also on your back end, making sure that you don't lose track of users no matter what they do on this identity verification, step going a bit further into access control. Just the second part, now that we know who our users are, we want to know what they're allowed to do. And this is usually where most of the friction is creative, especially for people who aren't that tech savvy and who could be put off by having content management.
So every one of you who downloaded an app on their Android phone or iPhone lately probably has seen that where you get this big list of this app wants to access this whole stuff on your phone. And you're just completely overwhelmed of why, why would it do that?
And why should I give that this access? This is like way too much, but also we have conditional access requirements to main based requirements where it's around bringing your own knowledge and making sure that users can only access those parts of apps that require.
And just to give you some guidance on there with content management, something we always recommend is using minimal privilege. That means when your user first accesses your app, just ask them to read a user profile. And then if they app want to upload a photo, ask them, can we access your photos? If they want to share something to another app, we can say, can we have the access to share? This does increase friction because you just have to give you multiple permissions in multiple points of the app app, but it makes it, it builds trust.
It makes it very easily understandable for why an app needs access to a specific part of my phone of my device, of my profile.
When it comes to conditional access, usually find permission based policies. This is about bringing authorization into the tool itself to get a bit more technical in the end. Any science tool will give you an access token, which is a proof of what the user can do. Make sure that this token reflects exactly everything a user can do within the system and make sure your science tool itself checks on a smart way.
If a user comes from this country, maybe we don't give him that permission because all of our customers are based in Germany in Europe. So if they sign in from Sydney or from New York, they won't be able to access as part of my app until they change delegation. And this also leads into domain based requirements. This could be something like passport, a verification, like face verification, but also like this. I know my users should be only here.
If they sign in from there, do something, reauthenticate them. And you need all of that. Or you can integrate all of that into your tool.
And it makes it very easy for your customers to understand what's going on because they will be prompted at login. This is what you're allowed to do, and this is what you're not allowed to do. They will be prompted off. Can you give us the permission to do these three things? And they will be only prompted to reauthenticate them if really required. And if you need that with the knowledge that you're having. And then on the last point, just very quickly on the user profile, you're not done with your user experience journey, just because users now have access to your app.
Think about integrating all the tools that you have triggering email campaigns from your email or from your directory from your identity system.
Think about gathering payment details from your users, putting them into your CRM tool, but also gathering data for personalization of your tool, for analyzing how users user app, and to progressively profile what your users are doing. So basically don't prompt everything at once, but just ask them every time they log in. Can you give us a few more pieces of information about you? This is something where a good sign tool should support you.
And this is something very powerful to build a consistent and understandable user experience for your users when they access your login to put it all in a nutshell, it's not a, it only job to care about good user experience. It means your security team. It needs your, your researchers, your marketing team, your developers, but if you put all of them in the same room, and if you have a science tool that supports that you have a great and very flexible way to delight your users, bring your app closer to them, make consistent and greatly increase your customer adoption and retention in the end.
So to that, a security solution is not a blocker of engaging UX combined with your right expertise and tools. It is a vital piece in exciting your users and putting a competitive advantage over your competitors who don't have those features. That's it with my quick impulse, talk about this. If you have any questions more than happy to answer them right now in the sponsors lobby, or you can always reach out to me or any other colleague of zero, you know, so we can have a deeper conversation of how you would actually implement that in the real world. Thank you.
