From User Effort to Enterprise Command: The Flip in Password Management

Terms and Conditions for Complimentary Team Lunch Offer

1. Eligibility: The offer is valid exclusively for Identity and Access Management (IAM) or cybersecurity teams. All team members must be employed within the same organization
2. Registration Deadline: Teams must complete their registration for the event by February 21, 2026, with the workshop held on or before January 30th, 2026, to qualify for the complimentary lunch offer.
3. Mandatory Attendance: To be eligible for the complimentary lunch, at least one member of the IAM team must attend.
4. Workshop Completion Deadline: The lunch and learn must be completed by March 30, 2026. Failure to attend the workshop by this date will result in forfeiture of the complimentary lunch offer.
5. Lunch Distribution: The complimentary lunch will be provided in the form of an online food delivery service voucher on the day of the event. It will be valued at $25 per person for up to 10 people. 
6. Offer Non-transferable: The complimentary lunch offer is non-transferable and cannot be exchanged for cash, credit, or other services.
7. Limited Availability: The offer is subject to availability and may be limited to a certain number of teams or participants as determined by the event organizers.
8. Please note that additional terms and conditions may apply. Participants are encouraged to review all event documentation for further details or contact the event organizers for any clarifications 

Review the Full Session Transcript

No time to watch the session? No problem. Take a read through the session transcript.

1

00:00:02.613 --> 00:00:20.413

Carolyn Evans: I’m Carolyn Evans, I'm the Director of Marketing here at Bravura Security, and I'll be your host today. And I'd like to introduce you to both Colin Duffy and John White. Colin is our SVP of Channel and Sales, and John is our VP of Customer Experience. They will be walking you through all of the changes and what's new.
 

2

00:00:20.413 --> 00:00:31.742

Carolyn Evans: And before we jump in, again, there is a Q&A and a chat tool, and you… please feel free to send your questions through there. We're definitely going to take time at the end to answer them before we wrap up.
 

3

00:00:32.083 --> 00:00:33.793

Carolyn Evans: Colin, over to you.
 

4

00:00:34.223 --> 00:00:50.783

Colin Duffy: Awesome. Thanks, Carolyn. Appreciate the introduction. Certainly excited, and thank you, everyone, for joining, today's session. Today, we're going to talk about a very important release in terms of Bravura security. We're going to start by grounding
 

5

00:00:50.783 --> 00:01:04.122

Colin Duffy: kind of what is the current reality for most enterprises in terms of password operations today, and then we'll talk about a shift, that we're seeing across organizations and what's changing in Bravura Pass to accommodate that shift.
 

6

00:01:04.123 --> 00:01:14.532

Colin Duffy: And then we'll close out with what this means for you, depending on your role and what's changed. It isn't just about scale, password operations are now a continuous responsibility.
 

7

00:01:14.533 --> 00:01:23.122

Colin Duffy: not an occasional recovery task by the user. So we're super excited to walk you through that. And this is all made possible by the fact that we've
 

8

00:01:23.193 --> 00:01:41.082

Colin Duffy: Been in this market for 30 years, and we have, you know, invested heavily in a Converge platform for identity security capability, spreading across identity governance, privileged access management, and end-user password management. So today, we'll focus on
 

9

00:01:41.083 --> 00:01:51.923

Colin Duffy: How we can bring two capabilities together to deliver a brand new user experience and a greater resilience for customers in terms of the management of passwords at scale.
 

10

00:01:52.873 --> 00:01:57.173

Colin Duffy: So with that, I'll pass it off to John in terms of, kind of.
 

11

00:01:57.343 --> 00:01:59.933

Colin Duffy: Taking us forward, and, yeah.
 

12

00:02:00.693 --> 00:02:02.252

John White: Awesome. Thanks, Colin.
 

13

00:02:02.263 --> 00:02:27.003

John White: So yeah, like Colin said, we're going to spend a little bit of time sort of giving you a lay of the land in terms of where we see things today, and why what we're releasing in version 12.9 of the security fabric, is really relevant to, you know, the problems we're seeing today. So, the reality we're all kind of operating in right now, for all our good intentions and progress, passwords still haven't disappeared. In fact, in many ways.
 

14

00:02:27.003 --> 00:02:28.792

John White: they've spread, so…
 

15

00:02:28.833 --> 00:02:36.383

John White: Password fatigue and credential-based attacks are still high, they're still increasing, and both businesses and end users are still feeling that pain.
 

16

00:02:36.383 --> 00:03:00.712

John White: There's a proliferation of applications and systems that people interact with on a daily basis to get their work done, which means more logins. I mean, I myself, you know, I might be in a somewhat unique position, although I think most people on this call would probably have a similar situation, but I've got hundreds of different accounts and logins. I mean, even just to get set up today in Zoom, I, you know, resurrected a login that I forgot I had from
 

17

00:03:00.713 --> 00:03:25.652

John White: from, you know, last year and logged in to it today. So, I mean, that wasn't something that's managed by anything, it's something that I have to maintain or recover or manage myself. So, that means in most cases, especially where not integrated with a consolidated SSO solution, like many things even like this, there's passwords to manage for you, there's passwords that you need to choose, it could either be… it could be other things like vendor support portals as well, so if you log into our
 

18

00:03:25.653 --> 00:03:41.933

John White: support portal, there's another credential that you need to manage. If you work with partners, you might have a portal with them that you need to log in and work on to do certain things or access certain materials, and so on. And all of these come with their own set of enforcement rules and password complexity policies. More overhead, right?
 

19

00:03:42.043 --> 00:04:04.403

John White: So, at the end of the day, people, humans, we could say this one of two ways. They are either lazy, or more positively, I suppose they're efficient. And by that, I mean, you know, they, and by they, I mean us, will tend to find the easiest and most efficient way for us to comply with, or work around password policies, or, you know, password enforcement.
 

20

00:04:04.403 --> 00:04:26.362

John White: That leads to things like using the same password for personal accounts as you do for work-related purposes. It means using the same weak patterns in your personal life, that you might, you know, use to get around password policies. You will be hitting the low bar rather than exceeding it, so if you have a minimum password policy for complexity, you're going to hit whatever you need to get past that.
 

21

00:04:26.613 --> 00:04:50.993

John White: Even just saying that out loud, I think two things really stand out to me from that. I mean, one, if we think about identity as a new perimeter, and users have been kind of backed into a corner in terms of managing their own passwords in so many places, it's not surprising to think that they would have reuse between their personal lives and business. That means if there's a breach or a compromise of a service that a person uses in their own personal life.
 

22

00:04:50.993 --> 00:04:51.703

John White: Which…
 

23

00:04:51.703 --> 00:05:01.162

John White: Has a high probability of probably having weaker protections than some of your own internal business systems. That means your identity perimeter is only as strong as what this person might be doing in their own time.
 

24

00:05:01.243 --> 00:05:10.582

John White: The other, in terms of using weak… the weakest patterns, kind of speaks for itself when you say it out loud. Again, when we set a password policy, we're setting a minimum complexity policy.
 

25

00:05:10.583 --> 00:05:21.813

John White: You think about that for a second, we're setting a low bar that we can stomach, and that users are going to meet you right there. They're not going to get an award for, you know, having a really, really, really complex password. They're going to get what they need to.
 

26

00:05:21.813 --> 00:05:27.253

John White: And that's as far as it goes, right? The behavior just doesn't have the right channels for reinforcement in this case.
 

27

00:05:27.813 --> 00:05:43.512

John White: From a statistical point of view, we at Bravura Security are big fans of the Verizon Data Breach Investigations Report, or DBIR. And in the latest 2025 report, we still see an 88% of basic web app attacks.
 

28

00:05:43.513 --> 00:06:06.803

John White: are using stolen credentials. So, for an industry that's moving away from passwords, we can see there's still a huge unresolved problem that isn't going to be covered soon enough by password alternatives to leave unaddressed. And even if those alternatives do take off massively, it's still not likely to have full coverage, meaning there's going to be gaps presenting risk that needs to be mitigated.
 

29

00:06:07.023 --> 00:06:31.182

John White: We still see passwords show up in things like non-SSO integrated systems, you know, whether that's a political or a technical or a, you know, economic reason that it's not integrated with an SSO system. There are still legacy and on-prem systems that are business critical that have a password, maybe not a primary use, but are still maybe in a recovery scenario where they're still, you know, present, even though they're being kind of obfuscated by…
 

30

00:06:31.313 --> 00:06:35.252

John White: MFA, or maybe passwordless technologies, if you're really on top of the ball.
 

31

00:06:35.573 --> 00:06:39.202

John White: So these, these passwords persist in the gaps.
 

32

00:06:39.373 --> 00:06:53.573

John White: But, at the end of the day, I think the risk isn't just more passwords. When we talk about credentials in a hybrid identity context, I think the biggest issue, really, isn't complexity, but it's that ownership is fragmented. So.
 

33

00:06:53.733 --> 00:07:04.103

John White: For example, different systems enforce passwords and password complexity differently, so even if you think you have a standard, you actually have multiple standards, depending on where the password lives.
 

34

00:07:04.153 --> 00:07:24.032

John White: Even when password policies are synchronized, and some of you might be doing that today, the password itself is still user-chosen in most environments. And then another, you know, self-service reset UI and UX can look slick and modern, and it should, but it still makes users responsible for password creation.
 

35

00:07:24.033 --> 00:07:31.013

John White: The issue with this, like I said, is that humans will optimize for speed and memorability, and this is where reuse happens, patterns happen.
 

36

00:07:31.013 --> 00:07:45.762

John White: And then even those well-meaning users that came up with a really good, strong, compliant password they've, you know, memorized and mastered for their own personal logins generates that massive hole in your sort of web of trust for that user's identity. Personal breach for them has an impact on your business.
 

37

00:07:46.053 --> 00:07:54.042

John White: And then on top of that, because password change and recovery are reactive and they're system-specific, your outcomes depend on which system you hit and when.
 

38

00:07:55.303 --> 00:08:14.042

John White: So, where SSPR fits, it still provides an essential capability, and we're not saying it is an essential, right? It helps restore access, it gives you an avenue for, you know, recovering access without necessarily involving another person. It's definitely better than submitting a ticket and waiting for that to come back to you.
 

39

00:08:14.043 --> 00:08:19.272

John White: And it does provide an avenue to reduce, but not eliminate disruption.
 

40

00:08:19.283 --> 00:08:30.563

John White: And in the context of what we talk about today, you know, there are still fallback recovery scenarios that you really ought to have an answer for, and those shouldn't be too onerous or time-consuming for the user if those situations arise.
 

41

00:08:32.183 --> 00:08:42.572

John White: So, I mean, like I said, SSPR improves recovery for sure, but no matter how you improve it or dress it up, it doesn't change who owns the password lifecycle. Ownership is still split.
 

42

00:08:42.573 --> 00:09:07.292

John White: That's why we see lockouts during incidents, and even just regular password lifecycle events. I mean, for example, have you ever set your password on a Friday because the password policy forced you to and you forgot what it was on Monday? Did you miss a character when creating a password and can't remember what you actually typed? You know, or have you been, you know, where I was just recently, struggling with a really opaque complexity requirement that no matter what you did, you didn't meet the complexity it was looking for.
 

43

00:09:07.293 --> 00:09:16.622

John White: but you didn't get the feedback you needed to get past that. These are all things that are intrinsic with owning that password lifecycle yourself as an end user.
 

44

00:09:16.663 --> 00:09:34.162

John White: We also see help desk escalations when self-service breaks, which comes with an obvious operational cost, as well as some increased risk factors that I'll touch on a bit later. But even at a really basic level, some of these recovery scenarios involving the help desk kind of echo the same problems I've been talking about with passwords, you know?
 

45

00:09:34.163 --> 00:09:58.472

John White: We really don't like to see it, but so many organizations still rely on things like Q&A to get through an assisted reset. If they don't forget the answers in the first place, which is super common, they're also liable to optimize that for themselves in the same way as we talked about with passwords. So, you know, like, where were you born? Red. What car do you drive? Red. What's your dog's name? Red. You know, granted, modern solutions can block that and force uniqueness.
 

46

00:09:58.473 --> 00:10:17.573

John White: It's still not hard to work around those things using the same weak patterns and kind of optimization that we see in user-owned password lifecycle. Or just the obvious ones, you know, easily found information that's likely sitting on social media. So again, another breach of your identity perimeter because of the way end users handle personal data on the internet.
 

47

00:10:17.573 --> 00:10:31.623

John White: And these scenarios arise because of the nature of password reset, the reactive break-fix nature of users owning their own passwords, and all of this ultimately contributes to gaps between policy intent and your credential reality.
 

48

00:10:31.723 --> 00:10:46.653

John White: So, I know that seems like a lot of doom and gloom, so I'll stop for a moment and hand it off to Colin to hopefully start bringing us out of the darkness here, and get into one of the biggest opportunities presented by what we're bringing to the space as part of our latest release of the Security Fabric. Colin, over to you.
 

49

00:10:49.183 --> 00:10:54.562

Colin Duffy: Thanks, John. Yeah, moving forward here, we're just going to touch on some of the
 

50

00:10:54.593 --> 00:11:13.263

Colin Duffy: the gap, that we continue to see as customers try and solve this problem with disparate tooling. So, what we've seen is, obviously, a combination of the self-service password reset coupled with the password, manager, or password vault type of.
 

51

00:11:13.263 --> 00:11:30.252

Colin Duffy: Tool, but that still continues to introduce friction in terms of users having to navigate two separate systems when it comes to managing the passwords they effectively own and are accountable for in terms of governance.
 

52

00:11:30.253 --> 00:11:48.983

Colin Duffy: And then we also see that the adoption of these tools, in terms of password managers, is weak within enterprises. Oftentimes you have different teams running different tools, just a product of, you know, addressing the problem space on their own or in silos.
 

53

00:12:06.793 --> 00:12:09.223

John White: I think we might have lost Colin.
 

54

00:12:16.373 --> 00:12:20.312

Carolyn Evans: Yeah, I think we might have lost Colin.
 

55

00:12:20.682 --> 00:12:26.032

Carolyn Evans: I can hear you, John, but I couldn't hear Colin. I think Colin just dropped.
 

56

00:12:26.323 --> 00:12:29.202

Carolyn Evans: Okay.
 

57

00:12:29.952 --> 00:12:32.793

Carolyn Evans: So… let's see…
 

58

00:12:33.763 --> 00:12:47.112

John White: Okay, I mean, I'll kind of fill it until he comes back. So, I mean, what we're really trying to get at here is that, you know, password managers are an avenue to correcting and addressing some of the things that I was talking about.
 

59

00:12:47.113 --> 00:13:11.153

John White: But, you know, the reality that we see, and we talk to a lot of different organizations all the time at trade shows, we talk to our own customers, we talk to prospective customers, we talk to the market, analysts, you know, many people are trying to use password managers, but adoption is super inconsistent. So we see people bringing different tools across different teams. Think, like, your KeePass for legacy IT teams, you know, the latest, you know, personal password manager that people
 

60

00:13:11.153 --> 00:13:20.092

John White: from, you know, not to pick on Carolyn, but, you know, a marketing team might bring in. And that's separate from what IT might be pushing on the entire business, saying, why don't you use the solution we're providing?
 

61

00:13:20.203 --> 00:13:38.282

John White: So there's really inconsistent tooling that's being used. We're seeing user-selected solutions outside of governance, so you've got no idea what it is. And none of this is integrated into all of the self-service password reset stuff that people are sort of relying on SSPR for, so…
 

62

00:13:38.283 --> 00:13:42.553

John White: They've got one experience for one thing, and another experience for something else.
 

63

00:13:42.553 --> 00:13:51.082

John White: Or they're not using anything, and they're still, you know, writing things down on post-it notes, or under the keyboard, or, you know, trying to memorize the same pattern they use everywhere.
 

64

00:13:51.333 --> 00:13:57.392

John White: Very, very poor adoption of the practice, and very poor adoption of, sort of a cohesive set of tooling.
 

65

00:13:57.743 --> 00:13:59.273

John White: Colin, I think you're back.
 

66

00:14:01.913 --> 00:14:10.182

Colin Duffy: I am back, but I don't know if it's reliable. I continue to have issues here with respect to, I guess, what's a bandwidth-intensive
 

67

00:14:10.713 --> 00:14:17.393

Colin Duffy: Connection, but yeah, appreciate you taking that up in terms of that particular slide.
 

68

00:14:17.723 --> 00:14:26.852

Colin Duffy: The next one is touching on, kind of, the core friction associated with those separated experiences. So users are, you know.
 

69

00:14:27.033 --> 00:14:35.343

Colin Duffy: potentially frustrated, in terms of resets. Password recovery happens in one user interface, user experience.
 

70

00:14:35.403 --> 00:14:47.672

Colin Duffy: Password vaulting is living in another. And then, from an IT standpoint, in the event of an incident, or a breach, or a compromise, it is a significant lift in terms of coordinating
 

71

00:14:47.673 --> 00:14:54.782

Colin Duffy: the different constituents to resolve that potential compromise. And, you know, it oftentimes doesn't involve either of those
 

72

00:14:54.783 --> 00:15:10.802

Colin Duffy: tools in terms of addressing the problem. So, this is kind of what we're driving at in terms of the opportunity we see in the market. We are well-positioned from a password management connectivity standpoint, user experience standpoint, and
 

73

00:15:10.903 --> 00:15:22.942

Colin Duffy: the convergence of two capabilities around password vaulting and password recovery to help customers, attack this problem space differently going forward.
 

74

00:15:22.943 --> 00:15:33.052

Colin Duffy: The next slide there touches on the convergence that we are seeing, and what we are really coming together here today to talk about, with, with customers.
 

75

00:15:33.243 --> 00:15:35.473

Colin Duffy: Sorry.
 

76

00:15:36.243 --> 00:15:51.653

Colin Duffy: So, we continue to recommend that self-service, you know, it's still valuable, it's essential, it should remain a big part of your password governance journey and program for end users, but it…
 

77

00:15:51.783 --> 00:16:13.033

Colin Duffy: can start to shift to a, a kind of a tool or feature that is less, prominent for users as we move towards more of a centralized governance model that is led by the enterprise, where ownership, tends to… or is now transitioning to, IT operations.
 

78

00:16:13.043 --> 00:16:30.822

Colin Duffy: Taking care of the credential lifecycle on the behalf of the user, and their user experience now shifts from one that is less about self-service recovery, and one that's more about enablement in terms of retrieving credentials through a password manager, and covering off those systems that are
 

79

00:16:30.823 --> 00:16:37.123

Colin Duffy: Also, on the long tail side of your… identity security estate. So.
 

80

00:16:37.153 --> 00:16:51.403

Colin Duffy: We are encouraging customers to look at this problem space differently. We see the opportunity to flip it on its head and move away from a user effort-driven, friction-driven experience to one that's led by the enterprise in terms of
 

81

00:16:51.403 --> 00:16:59.992

Colin Duffy: Automating the creation, change, rotation, and recovery of systems… sorry, recovery of passwords on those integrated systems.
 

82

00:17:00.123 --> 00:17:11.673

Colin Duffy: You know, freeing users from being the custodian of those passwords, allowing them to move to more of a passwordless experience, and also giving
 

83

00:17:11.753 --> 00:17:30.473

Colin Duffy: the enterprise the power to recover at scale. So, that's what we're very excited to introduce, and we'll get more into that in terms of the following slides. But, you know, having laid out the problem space, we think we have a very compelling proposition in terms of how to think about password management going forward.
 

84

00:17:32.513 --> 00:17:33.723

John White: Awesome, thanks, Colin.
 

85

00:17:34.073 --> 00:17:49.753

John White: So yeah, I think the shift is pretty simple to say, but huge in impact, right? Passwords move from user-owned to enterprise-run, and that ownership, I think, helps… really helps drive consistency. That's why this changes everything, right? That's why we're calling it a flip in the model, a flip in the paradigm.
 

86

00:17:49.913 --> 00:18:08.212

John White: So, in this new model, the enterprise runs passwords, and they do that as an operational capability, but to make ownership real, we can think of what's needed as an operational delivery and a recovery or a response layer. And this is what we're bringing with version 12.9 of Rivera Pass.
 

87

00:18:08.773 --> 00:18:20.023

John White: So, first is the operate layer. This is the one control layer to run password lifecycle operations across systems. It starts with connectivity, so you connect your platform.
 

88

00:18:20.023 --> 00:18:31.483

John White: you know, reverse pass in this case, to all in-scope systems, cloud, on-prem, legacy, you know, and that's where, especially the places that you're interested are things where SSO and passwordless don't fully reach today.
 

89

00:18:31.493 --> 00:18:39.933

John White: Although even, you know, your SSO password is still important to be able to have an avenue for recovery, or re-securing, which we'll get to in a minute.
 

90

00:18:40.473 --> 00:18:56.092

John White: This is also typically where traditional SSPR solutions kind of sit. So, if you're using something a bit more advanced than, you know, the default Entra ID SSPR, like, you know, any of the solutions out there now, up to kind of this time, this is where they sit, and they don't really go much further than that.
 

91

00:18:57.073 --> 00:19:20.332

John White: So, we're really excited to get into what, you know, Bravura Pass brings to sort of evolve this. But once you have that critical subset of systems hooked up, you know, if that's what you have today with PaaS, or if there are additional systems that you realize, hey, we should probably hook into this, you get that set up, and you've got the ability to now centralize how passwords are created, changed, and recovered. So you've got the ability, you've got the connectivity, you could do those changes with this layer.
 

92

00:19:21.083 --> 00:19:46.043

John White: A big operational win here can also be for mitigating help desk risk, so if you have this centralized and everything that you need to reset passwords on is brokered by this sort of central operate layer, you should be able to provide, you know, a help desk reset and unlock capability. Some of you might be doing that already, some of you might not, but I think it's really important to kind of come look at this for a second, and consider that you can do this without granting
 

93

00:19:46.043 --> 00:20:04.342

John White: broader admin rights to the people who are helping to reset credentials, which helps support, you know, the principle of least privilege. So, no Active Directory users and computers permissions, no intra-ID user administration roles, just controlled access brokered by the same tooling as what you're trying to build towards here with Enterprise-owned Password Lifecycle.
 

94

00:20:04.653 --> 00:20:17.993

John White: And for those help desk assisted resets, you really ought to be enforcing caller verification as well. So, if you have the central platform and you can funnel everything in here, if you do that, you get consistency and security in that workflow.
 

95

00:20:18.133 --> 00:20:36.663

John White: Taking a second on that, I think color verification in this sense has become increasingly critical to securing the identity perimeter, particularly after COVID, and then the increase in work from home, and the rise of more distributed teams. You don't always know or have a familiar relationship between help desk agents and the users calling in.
 

96

00:20:36.663 --> 00:20:59.963

John White: It's especially important now, more than ever, with AI-assisted phishing and social engineering and audio-video impersonation, that whatever platform you use to employ Enterprise-owned Lifecycle, or even just, you know, regular old self-service password reset, it's really important that it supports the notion of additional user verification and authentication during things like assisted resets, which
 

97

00:21:00.083 --> 00:21:02.263

John White: Rivera Pass also brings to bear here.
 

98

00:21:02.713 --> 00:21:17.362

John White: So, with all of this, the core breakthrough you're aiming through… er, sorry, you're aiming for is consistent behavior across systems, same operation, same expected outcome. On the user side, this starts to set up a model where they don't have to juggle where passwords live or how they're managed.
 

99

00:21:17.363 --> 00:21:23.402

John White: And in practice, this operate layer is what starts to make enterprise ownership real.
 

100

00:21:23.693 --> 00:21:42.803

John White: So, I mean, you're probably here if you're using Bravura Pass today, which is a good thing. If you're not and you're interested, this is kind of the starting point, but the whole fabric kind of operates this way in terms of connectivity. The fun part, which kind of starts to come into play with version 12.9, is this deliver capability. So.
 

101

00:21:43.033 --> 00:21:59.093

John White: We're calling this, essentially, passwords as a service. This is a governance capability for managing passwords, especially in hybrid environments. The model, simply, is that the enterprise centrally generates compliant passwords on-demand or policy-driven, using that operate layer.
 

102

00:21:59.093 --> 00:22:08.482

John White: And those generated passwords are then automatically updated in the user's password manager. So this is a, you know, an app on their phone, or a browser extension,
 

103

00:22:08.483 --> 00:22:15.053

John White: Or a desktop app, or a web app. And then those users autofill or retrieve what they need when they need it.
 

104

00:22:15.183 --> 00:22:40.173

John White: This is really the missing piece for end users when we think about this problem. Most organizations can generate strong passwords, they could send them out, they could do a blanket reset across the entire organization, but they can't deliver them cleanly. So, if you think for a moment about a mature privilege access management program, for example, this kind of thing should largely be solved through automated randomization, programmatic retrieval of new passwords and secrets.
 

105

00:22:40.173 --> 00:22:47.053

John White: And automated orchestration to update things like services and schedule tasks that depend on a privileged service account.
 

106

00:22:47.233 --> 00:23:06.952

John White: But on the end user side, none of this really helps them, right? Hence why end users can be the cause for greatest concern or hesitation if you need to do something like this. And again, if we're going back to the notion of identity being the new security perimeter, it's critical that we have the ability to execute just as quickly in this arena as we should be doing for privileged access. So…
 

107

00:23:07.013 --> 00:23:22.742

John White: Delivery, in this matter, changes the experience for the user. There's no remembering, there's no reusing, there's no post-its or spreadsheets, there's no guessing what password goes where. We've removed all the friction from the password reset experience, while improving security at the same time, which is a huge win.
 

108

00:23:23.923 --> 00:23:38.962

John White: There's an added benefit here for some of the long-tail applications that Colin was mentioning earlier. You know, even where lifecycle automation isn't possible, for, like I said, you know, political, economic, you know, complexity reasons, whatever.
 

109

00:23:39.083 --> 00:23:43.483

John White: You can still, help improve governance using Bravura Pass.
 

110

00:23:45.083 --> 00:24:03.003

John White: really what this gets down to is using that password manager, right? So, this is also consistent with the guidance, that NIST has put out in, if you're familiar with it, Special Publication 800-63B, which basically encourages the use of password managers so people can use long, unique passwords without having to remember them.
 

111

00:24:03.173 --> 00:24:18.132

John White: This matters in the context of Bravura Pass and this, concept that we're bringing to bear here, because there are really two categories of password in every organization. The ones that IT and security can govern through integration, like the one in the operate layer we're talking about.
 

112

00:24:18.463 --> 00:24:25.362

John White: And these long-tail applications that will never be fully integrated. So we talked about vendor portals, external platforms, one-off apps, things like that.
 

113

00:24:25.483 --> 00:24:37.143

John White: For those, the best outcome is still strong, unique passwords and zero memorization, because remember, that's still, you know, a chain, potentially a weak link in the chain of your security perimeter.
 

114

00:24:37.143 --> 00:25:02.022

John White: And a password manager makes that practical. So, there's a nice side effect here for adoption with this delivery capability, which is that once users are already retrieving or auto filling their centrally managed passwords from the password manager, it becomes a natural place to store everything else, too. So, even something like a Zoom login for me today, you know, or your vendor support portal, for example, likely completely outside enterprise control, can still benefit from the same habit
 

115

00:25:02.023 --> 00:25:08.433

John White: and password hygiene, right? Generate a strong password, store it, and let autofill handle the rest.
 

116

00:25:08.543 --> 00:25:18.793

John White: So users end up with the same experience everywhere for all passwords. It's a forcing function that helps the mantra kind of go from know the password to retrieve the right password for everything.
 

117

00:25:19.753 --> 00:25:28.283

John White: Now, once you can operate across systems, deliver passwords cleanly, the third capability, is really what changes incident response.
 

118

00:25:28.503 --> 00:25:40.453

John White: So you've got the ability in the operate layer to integrate and control password policies. You can, funnel help desk escalation to a central point and enforce some of that, user verification stuff I talked about.
 

119

00:25:40.453 --> 00:25:48.903

John White: You've got a backstop emergency for self-service recovery processes where you still need them, and you've provided an integrated password manager for your users.
 

120

00:25:49.163 --> 00:25:59.263

John White: You have a delivery capability, which automatically is updating those connected credentials for users in their password manager, and this also buys you that mass adoption and familiarity with the model that we talked about.
 

121

00:25:59.563 --> 00:26:11.852

John White: And then the respond or recover capability here takes both of those and allows you to, at any time, you know, reset or re-baseline passwords for your entire user base, or just a particular subset.
 

122

00:26:11.853 --> 00:26:27.173

John White: When we talk about enterprise-scale response and recovery in the context of end-user passwords, what we're really talking about is business continuity without the fire drill. Mechanically, that means one click orchestrates resets across all connected systems.
 

123

00:26:27.173 --> 00:26:35.883

John White: But the important part isn't the click, it's the orchestration. It means no scripts, no outages, no lockouts, no overnight IT marathons, no user interruptions.
 

124

00:26:35.893 --> 00:26:47.553

John White: It's a simplified and reliable way of doing this versus anything you might have seen done in the past that involves multiple credential stores and, most importantly, manual end-user communication.
 

125

00:26:47.583 --> 00:27:05.103

John White: You know, I've heard first-hand accounts of all the crazy ways people communicate passwords to end users, both in, you know, regular user lifecycle and in emergencies. Things like unencrypted messaging and SMS, email, physical mail on paper, passing it through intermediate people, or even just, you know, using a blanket standard default value.
 

126

00:27:05.143 --> 00:27:17.273

John White: The kind of response and recovery that this gives you, should be, you know, coordinated, simultaneous reset at any scale that helps you avoid all of those, we'll call them less than optimal delivery mechanisms.
 

127

00:27:17.663 --> 00:27:27.762

John White: And what it ultimately enables is what we're calling breach or reset tomorrow readiness, so that you can safely reset at scale and contain faster with much less disruption.
 

128

00:27:29.043 --> 00:27:40.312

John White: And then, you know, once you've got this in place, a mass reset basically becomes a repeatable capability, not a custom project. It's something you can realistically consider operationalizing.
 

129

00:27:40.313 --> 00:27:54.013

John White: You can start thinking about integrating this with other threat detection and response tools, because you know you have a reliable mechanism for re-securing or rebase lining one or more user accounts without impacting the end user or getting in the way of their work.
 

130

00:27:54.103 --> 00:28:04.662

John White: Users likely won't even know that you've done it as they continue to go about their day, using their password manager to authenticate themselves when necessary, without knowing or typing passwords themselves.
 

131

00:28:04.663 --> 00:28:25.763

John White: And because this is so well-defined and reliable, it cuts down the overhead required for reporting and auditing such an event, because everything's driven by the same operate layer, Bravura Pass in this case, right? Whether it's a mass reset, a selective rebase lining, a self-service initiated randomization, or a help desk escalation workflow, all of it's coming from the same place.
 

132

00:28:25.813 --> 00:28:34.893

John White: So when you combine, you know, operate, deliver, and recover, what do you get? I mean, essentially, end-user password management that runs itself.
 

133

00:28:35.313 --> 00:28:43.692

John White: So yeah, with that, Colin, do you want to pull all this together and help summarize for folks some of the takeaway outcomes that they can expect from adopting this approach?
 

134

00:28:44.323 --> 00:28:48.892

Colin Duffy: Yeah, for sure. I'm going to stay off-camera, see if that helps me stay on the session, or in the session.
 

135

00:28:48.893 --> 00:28:49.672

John White: Fair enough.
 

136

00:28:49.673 --> 00:29:02.702

Colin Duffy: But appreciate, yeah, that segue. So, in terms of outcomes, we're going to look at this from kind of two perspectives. From the IT security side. So, this new paradigm offers customers the opportunity to.
 

137

00:29:02.703 --> 00:29:10.842

Colin Duffy: really take back the control of enterprise credentials. I mean, the legacy approach in terms of
 

138

00:29:10.843 --> 00:29:21.893

Colin Duffy: Trusting end users to be the custodians of passwords hasn't worked well over time, and we can all point to examples of where that's failed. So the opportunity to shift that model
 

139

00:29:21.893 --> 00:29:39.992

Colin Duffy: to the enterprise in terms of consistent policy enforcement across those integrated systems is certainly one benefit here. You're now kind of getting away from those scenarios where you might have dreaded introducing a password policy change of going from 8 to 16 characters to 24.
 

140

00:29:39.992 --> 00:29:51.483

Colin Duffy: That becomes irrelevant in this scenario. Users don't care how long the passwords are now, they're simply just retrieving the password value, auto-filling it, and getting on with their day. So that's one piece.
 

141

00:29:51.483 --> 00:30:00.313

Colin Duffy: And then, you know, being able to extend that password governance to non-integrated systems as users adopt… sorry, adopt a password vault.
 

142

00:30:00.353 --> 00:30:19.913

Colin Duffy: to govern those loose credentials that you can then, you know, own in terms of policy enforcement and rules and reporting as well. There's reduced reliance on users, both in terms of ownership, but also in terms of recovery, and their experience drastically improves. They're no longer burdened with
 

143

00:30:19.913 --> 00:30:27.822

Colin Duffy: The composition of passwords, or the notifications to change passwords, you know, every 90 days, or however many days you're currently doing it.
 

144

00:30:27.823 --> 00:30:48.423

Colin Duffy: The help desk side of things is also very important in terms of not only are we enabling the help desk to better verify and authenticate those callers in the event there is a password reset, but by design, the help desk will be less involved. There will be fewer password-related issues in terms of, like.
 

145

00:30:48.423 --> 00:31:04.362

Colin Duffy: I can't get my password, I forgot my password, the user can solve that problem simpler themselves in this new model, and the help desk is less likely to be a target in terms of phishing, because they're not necessarily owning the password reset or unlock process for
 

146

00:31:04.363 --> 00:31:10.732

Colin Duffy: the users as much as they would have been in the past model. And then lastly, the value of being able to
 

147

00:31:10.793 --> 00:31:28.422

Colin Duffy: repeatedly, in a repeatable way, sorry, contain credential compromises if they do, you know, surface, or if there are scenarios where you have a SIM system or ITDR systems detecting that there's some anomalous behavior.
 

148

00:31:28.423 --> 00:31:34.133

Colin Duffy: that system can call out to Bravura Pass and trigger a, targeted…
 

149

00:31:34.133 --> 00:31:47.852

Colin Duffy: password reset or a mass password reset through automation without disrupting the end user themselves. So, there's certainly a number of value propositions here we'd love to talk through with customers and understand if these resonate and
 

150

00:31:47.853 --> 00:31:54.272

Colin Duffy: How that could help their business in terms of maturing their password management program. John, anything you want to add to that?
 

151

00:31:59.023 --> 00:32:06.313

Colin Duffy: Okay, I will jump to… from a user standpoint, yeah, simply just reducing friction around this entire process.
 

152

00:32:06.313 --> 00:32:20.813

Colin Duffy: So achieving a passwordless experience while still, you know, passwords persist within the environment. From the evolution of password management, we all know the direction this is going in, but, you know, passwords will persist for a long time.
 

153

00:32:20.813 --> 00:32:30.812

Colin Duffy: So giving users an experience that doesn't involve ownership of the passwords is a win, fewer lockouts, fewer surprises in terms of
 

154

00:32:30.833 --> 00:32:44.233

Colin Duffy: having to manage those passwords, and, you know, accelerating recovery time, I can go fetch my credentials from my vault, or I can see password history in my vault. I can fetch a previous credential if I needed to.
 

155

00:32:44.233 --> 00:32:54.022

Colin Duffy: So, certainly benefits there in terms of the user experience, and the freedom from having to own the password lifecycle in this new paradigm.
 

156

00:32:55.083 --> 00:33:01.643

Colin Duffy: John, do you want to touch on, kind of, what 12.9 introduces in a bit more depth, and some of the, kind of.
 

157

00:33:01.783 --> 00:33:06.103

Colin Duffy: Key points for me, you know, forward-facing perspective.
 

158

00:33:06.103 --> 00:33:12.263

John White: Yeah, absolutely. I think I just… just want to hammer home the experience here on… on passwordless experience, right, as well.
 

159

00:33:12.263 --> 00:33:36.852

John White: you know, we're trying to give an idea where you don't interact with passwords as an end user, but the added benefit, and Colin was kind of hinting at this, is that when passwordless, you know, does, or technologies like that do replace what you're doing with passwords, the benefit is that by doing this now, while there's a gap to fill and there's things that need addressing, you can get your users on board with what that kind of life looks like
 

160

00:33:36.853 --> 00:33:37.733

John White: looks like.
 

161

00:33:37.733 --> 00:34:01.272

John White: Right? So, when we get to that point, which, you know, at Perverse Security, we're all about that, and we've got ways of enabling it, even within our fabric. When you get to that point where everything can be passwordless, you know, if we get there, your users should already be used to that experience, and they probably won't even notice the transition, right? You know, in one case, they're doing, you know, they're going to a page and it's auto filling and logging them in, you know, the next day, it might be a passkey, which
 

162

00:34:01.273 --> 00:34:09.072

John White: Coincidentally, you know, the security fabric also helps, you know, manage those and share them amongst people, and…
 

163

00:34:09.173 --> 00:34:28.473

John White: use it as a recovery method. So, what we're really going for, again, is not going against the grain of this movement towards SSO and passwordless, but supporting the underlying passwords that still exist today, and giving people a path to changing their behaviors well ahead of, you know, the ability to actually change the technical underpinnings of it, so…
 

164

00:34:28.813 --> 00:34:36.012

John White: I think it's a really cool, value prop for, you know, an end user that, you know, they don't need to care about passwords anymore.
 

165

00:34:36.803 --> 00:35:01.762

John White: But yeah, I'll move on, here to just a kind of a highlight here of, Rivera Pass version 12.9, and really the Security Fabric 12.9. In case you can't tell, there's a lot of energy and effort being put into this sort of shift in paradigm, helping our customers move in that direction. In order to support that, there's been a ton of work that's gone on behind the scenes to, modernize the way that we deal
 

166

00:35:01.763 --> 00:35:14.782

John White: with APIs. We've been working on a REST API for the last couple of minor versions, major and minor versions. It is now to a point where we can really start to push some of these really interesting new experiences for people.
 

167

00:35:14.783 --> 00:35:28.843

John White: And in terms of aligning with what the, you know, what the market is doing and seeing now, we're really focusing on ways to enable things like bring your own AI, integrating with things like tools in whichever LLM you're using.
 

168

00:35:28.843 --> 00:35:40.923

John White: And we have the intent to release an MCP capability later in the year. So, all of that API work basically goes to supporting that, you know, the new experiences and AI enablement.
 

169

00:35:40.923 --> 00:35:48.993

John White: There's also a lot of work going into reporting and visibility, and observability, that the API helps expose, and
 

170

00:35:48.993 --> 00:36:13.733

John White: If you've been using the product for a long time, the, you know, screenshot on the right-hand side there probably drew your attention right away. That work is enabling things like this, which is part of our new user experience for Rivera Pass in version 12.9. So, there's data, you know, that's exposed on that screen, for example, that, you know, we've known and we've had, and we've pulled out a system for ages. These new endpoints enable us to surface it a lot easier for customers.
 

171

00:36:13.733 --> 00:36:19.023

John White: And kind of give you insight into the information that we have through those live integrations.
 

172

00:36:19.023 --> 00:36:28.663

John White: With the, you know, the systems that we're trying to control with Enterprise Manage Reset, or indeed anything that the security fabric is integrated with for, you know, identity and privilege cases as well.
 

173

00:36:29.893 --> 00:36:33.702

John White: In terms of, sort of.
 

174

00:36:33.703 --> 00:36:58.632

John White: next steps and takeaways. We've got a few different resources here. First up, if you want to see how this looks for year-end users after adopting the approach that's made possible through what we're releasing here in Bravura Pass 12.9, we'd be really happy to dive into that with you and walk you through some of the finer details. As long as some demos, although, you know, I'll set the expectation up front, when you take away all of the work of managing passwords, it ends up being a pretty short demo.
 

175

00:36:58.633 --> 00:36:59.532

John White: But I think…
 

176

00:36:59.733 --> 00:37:07.762

John White: How you do that and, you know, what that means for you in terms of managing and owning the password lifecycle is a really interesting conversation, so…
 

177

00:37:07.763 --> 00:37:22.922

John White: That is available here. If you're looking for help applying this sort of approach in your environment, we're also offering something we're calling a password control health check. It's a guided working session, so less of a sales demo and more of a collaborative mapping session and discussion.
 

178

00:37:22.923 --> 00:37:29.262

John White: It would consist of largely talking about most of what we talked about today, but in the context of your organization, so…
 

179

00:37:29.263 --> 00:37:39.752

John White: Looking at your current end user password workflows, where passwords are created, changed, synchronized, if they are synchronized currently, and where they're recovered across the systems that matter most to you.
 

180

00:37:39.753 --> 00:37:59.122

John White: the friction points that you might already be seeing, as long as uncovering some maybe lesser-known ones. So, again, thinking about lockouts, inconsistent outcomes, where self-service is turning into escalation, and, you know, like we've mentioned a couple times today, what that help desk escalation workflow actually looks like is a really important point to dig into, and something we can help with.
 

181

00:37:59.183 --> 00:38:23.882

John White: And then from there, we would do what we were saying earlier about a reset tomorrow readiness. So, if you had to reset all of your passwords or scope population safely and verify it end-to-end, you know, could you do that without disruption today, or how far would you get? And then, obviously, off the back of that, we'd want to leave you with some prioritized opportunities and next steps based on how that session goes. So, whether that's to further consolidate password control.
 

182

00:38:23.883 --> 00:38:30.223

John White: to mitigate risks, or ultimately move towards this enterprise-managed lifecycle, we want to give you a path to doing that.
 

183

00:38:30.623 --> 00:38:43.813

John White: And then finally, if you're interested more generally in what it takes to get to version 12.9, or you're looking for a more general overview of some of the things that you might not be taking advantage of today, we'd be really happy to set up an upgrade workshop with you as well.
 

184

00:38:43.813 --> 00:39:07.593

John White: You know, our customer success team has been talking extensively with customers over the past year or so, focusing a lot on the operational efficiencies, risk mitigations, and overall ROI that the security fabric can unlock for you. So, if you haven't had the opportunity to go through things from that perspective yet, this could be an excellent opportunity to maybe surface some of the things you can do today to get more value out of the product, or that you can get after an upgrade.
 

185

00:39:07.593 --> 00:39:12.632

John White: And help you surface some of the hidden value, either that you're already getting, or that just might not be apparent.
 

186

00:39:12.883 --> 00:39:28.903

John White: But yeah, if any of that sounds interesting to you, I'm sure Carolyn can help facilitate follow-ups after this, and we can get one of those booked in with you after the webinar today, but that's… that's all from me. I'll pass it over to Colin to close us out.
 

187

00:39:29.503 --> 00:39:31.772

John White: And then I think we might have questions as well.
 

188

00:39:32.203 --> 00:39:43.993

Colin Duffy: Yeah, thanks, John. Yeah, if anyone wants to raise any questions, there is a Q&A feature available that we can accept question submissions.
 

189

00:39:43.993 --> 00:39:58.872

Colin Duffy: I know, John, you were doing a webinar recently as well on this, so one of the questions that kind of stuck out there that maybe we can revisit for this audience, was around, you know, if customers are already investing in SSO and passwordless.
 

190

00:39:58.903 --> 00:40:10.272

Colin Duffy: why focus on passwords at all? And, you know, why… where do passwords typically remain? I know we've covered some of that, but we've come across this as we've presented this capability.
 

191

00:40:10.333 --> 00:40:13.532

Colin Duffy: Two customers, in the run-up to this release.
 

192

00:40:13.633 --> 00:40:25.403

Colin Duffy: But it seems like, it's a pretty natural question for many customers in terms of, you know, what's the value of doing this in the face of, you know, passwordless and SSO still kind of evolving?
 

193

00:40:25.713 --> 00:40:33.612

John White: Yeah, and I mean, that's kind of why I've changed my tact with this and how I introduce. So, you know, at the beginning of this session, I laid it out, I think.
 

194

00:40:33.643 --> 00:40:36.882

John White: Pretty, pretty obviously, but it's good to circle back to this, right?
 

195

00:40:36.883 --> 00:41:01.802

John White: contrary to the claims of, you know, the imminent end of passwords that going on for multiple decades now, they're still here, right? This isn't the first time we've heard that they're going away. We've been trying to get rid of them in one way or another for ages, and in complex environments, and in a lot of the scenarios that we talked about today, they're likely going to remain for longer than we care to admit. So, we can't turn a blind eye to the risks that they pose in the meantime, right? Just because we hope that it's going to go away.
 

196

00:41:01.803 --> 00:41:19.892

John White: away doesn't mean that we can write off that risk. There's still a big issue to address there. And if we go back to the stats from the Verizon report that I mentioned, you know, again, if everybody's moving towards that, and it's moving as fast as, you know, you might be led to believe by, you know, reading your LinkedIn feed or whatever it might be.
 

197

00:41:20.093 --> 00:41:29.772

John White: 88% of attacks on web apps being linked to stolen credentials suggest that that's not being done effectively yet, right? So you don't want to be caught up in that.
 

198

00:41:29.843 --> 00:41:44.183

John White: That's why we're trying to find ways to bridge the gaps here, and you know, like I said, we're supporting passwordless journeys in other ways, in other parts of the fabric, but we recognize that there is a gap to fill there, and it's not appropriate to leave that sort of unaddressed.
 

199

00:41:44.233 --> 00:41:51.332

John White: And I mentioned this at the, sort of, the ending of your bit there about the benefit to end users, Colin, but…
 

200

00:41:51.333 --> 00:42:13.712

John White: there's some really good work in terms of normalizing how that kind of workflow would work for a user, and getting them to go from passwords to password lists, or to some other technology that doesn't involve their password overnight is not going to… is not going to happen. I think, as everybody knows, there's sort of a long tail involved in getting users to change behaviors, so if you have the ability to start getting people used to that sort of thing now.
 

201

00:42:13.713 --> 00:42:15.872

John White: This is a really good way of doing that.
 

202

00:42:16.053 --> 00:42:22.623

John White: And then I think the final point on that is, even in the implementations of password lists that we've seen out there.
 

203

00:42:22.623 --> 00:42:47.472

John White: there's still a lot that's bubbling under the surface that hasn't been addressed, right? We see passwords as an option for authentication disappearing from a lot of workflows, but the password still exists. And those, you know, remain a vulnerability and something that needs to be addressed. So, even if, you know, you switch to passwordless, you know, in some of the more recent implementations, you're not doing away with the password, you're just, you know, hiding the fact that it's still there.
 

204

00:42:47.473 --> 00:43:00.093

John White: Or it's used as a recovery mechanism, right? And in that case, SSPR comes back into play. So, there's a lot there, that we're still trying to address, and I think it's just a really good bridge for, you know, where we want to be and where we actually are today.
 

205

00:43:01.513 --> 00:43:07.442

Colin Duffy: Awesome. I see that Case has his hand up. I can allow Case to talk, if that works?
 

206

00:43:09.093 --> 00:43:10.363

Carolyn Evans: Yeah, absolutely.
 

207

00:43:10.533 --> 00:43:14.252

Colin Duffy: Okay, Case, you can come off your mic… your mute, yeah, there you go.
 

208

00:43:18.963 --> 00:43:20.603

Colin Duffy: I don't hear you, though.
 

209

00:43:26.423 --> 00:43:33.573

Carolyn Evans: there was another question while we're, getting the audio sorted out there. There was another question about,
 

210

00:43:34.053 --> 00:43:42.152

Carolyn Evans: What should we be looking for from an audit and governance point when passwords still exist across non-SSO and legacy systems?
 

211

00:43:44.813 --> 00:44:09.102

John White: Yeah, I mean, what you're really looking to do, is… well, so sorry, non-SSO. So yeah, for non-SSO, what you're trying to do is you're trying to use this as a forcing function to get people to use something like a password manager that helps you start to capture, you know, the actual reality and the password hygiene of those systems. I mean, if you're talking about integrated, you know, the benefit of that operate layer is you have a single source of truth
 

212

00:44:09.103 --> 00:44:33.632

John White: for who initiated changes, what was impacted, what verifications were put in for help desk assistance and stuff like that. For the non-integrated applications, if you've got wide adoption of the password manager, because everybody has to use it day to day, you can start to get similar metrics from that. So you can see the last time it was changed, you can see if it shows up in a breached report, or sorry, a breached password list, you can see if it's using a weak password.
 

213

00:44:33.883 --> 00:44:57.673

John White: If you have certain forms of 2FA, we can see if that's being used alongside that credential. If you're using a passkey, we can see that. So, all of that stuff starts to give you the ability to build a better picture of, you know, the state of non-integrated applications. But you can also use that information to then say, hey, we've got an organization of 150 people, and 120 are using this application that's not integrated.
 

214

00:44:57.673 --> 00:44:59.533

John White: with SSO or Federation.
 

215

00:44:59.533 --> 00:45:05.133

John White: maybe that's a target for integration, and we can bring that under the fold of the centralized control or the SSO program.
 

216

00:45:06.723 --> 00:45:07.423

Carolyn Evans: Okay.
 

217

00:45:07.853 --> 00:45:12.003

Carolyn Evans: That sounds… achievable.
 

218

00:45:12.223 --> 00:45:24.312

Carolyn Evans: We have a couple more questions. So, another one here, if we move towards enterprise-managed password life cycles, what changes
 

219

00:45:24.933 --> 00:45:26.882

Carolyn Evans: For end users, day to day.
 

220

00:45:28.003 --> 00:45:40.182

John White: Yeah, sure. I mean, we kind of touched on this a few times, but really, I could sum it up as, you know, the goal is less, right? Less password creation, less memorization, less being caught off guard by expirations, less lockouts.
 

221

00:45:40.183 --> 00:45:57.532

John White: The ideal is that passwordless experience that Colin mentioned, where users are retrieving and auto filling what they need, while the enterprise, you, handles generation and lifecycle changes behind the scenes, without users even noticing or needing to care, right? And then again, you're getting people used to what passwordless should feel like.
 

222

00:45:57.533 --> 00:46:11.253

John White: And you're following along with NIST recommendations for, you know, using and promoting password managers and what they enable, which is, right, those randomly generated passwords that surpass your password complexity requirements rather than meet them.
 

223

00:46:12.653 --> 00:46:13.443

Carolyn Evans: Right.
 

224

00:46:13.663 --> 00:46:15.173

Carolyn Evans: One more question.
 

225

00:46:19.463 --> 00:46:25.672

Carolyn Evans: What does reset tomorrow readiness look like, and what should teams plan for before they ever need it?
 

226

00:46:27.763 --> 00:46:38.562

John White: Yeah, so I think a lot of that comes from, you know, what we could offer with the health check that we're talking about. Understanding what your user password workflows look like, what the recovery scenarios look like.
 

227

00:46:38.563 --> 00:46:58.422

John White: And then understanding, you know, and having the ability to scope who to reset, knowing that you can execute it safely across the systems you govern and the ones that you've identified, and then being able to verify things end-to-end. I think the common, the common failure mode of doing that kind of activity before a solution like, what
 

228

00:46:58.423 --> 00:47:01.353

John White: mass password reset and preferred pass are bringing across
 

229

00:47:01.353 --> 00:47:26.062

John White: isn't performing the reset, it's coordinating across systems and making sure that those credentials are reliably updated, which means users aren't interrupted. So, think about your critical workflows, think about what you need people to be able to continue to do, what that business continuity looks like, and make sure when you push that button, you've sort of set your foundations correctly, and that those will be re-secured or re-baselined, and people will be able to get credentials out of their password manager
 

230

00:47:26.063 --> 00:47:27.353

John White: without interruption.
 

231

00:47:28.683 --> 00:47:43.903

Carolyn Evans: Okay, I think with that, we're at time, so we're going to wrap it up here. If anybody has additional questions, please shoot them to us. We're going to, send out an email with this recording, and then you will be able to, respond to that.
 

232

00:47:44.083 --> 00:47:51.653

Carolyn Evans: So thank you, Colin and John, for all of your time and walking us through today. We've put a couple of…
 

233

00:47:51.833 --> 00:48:04.063

Carolyn Evans: links in the chat, to link to the, the, items that John introduced, the password control health check, an upgrade workshop, and then a demo, if you'd like a demo,
 

234

00:48:04.673 --> 00:48:12.983

Carolyn Evans: Specifically for your organization. So please, click on one of those, request, and we'll connect with you soon.
 

235

00:48:13.963 --> 00:48:16.182

John White: Awesome. Thank you so much for your time, everyone.
 

236

00:48:16.343 --> 00:48:17.293

Colin Duffy: Thanks, everyone.