Docusign Surfaces Identity Truth at Scale with Bravura Security

Turn Identity Into Your Source of Truth

See how Bravura Security unifies identity, privileged access, and password management on one platform the way Docusign did.

Speakers:
Peter Muller, Principal Security Architect, Identity, Docusign
Bart Allan, General Manager, Bravura Security

Peter Muller (00:08):

So, Docusign — like most software companies, we have two distinct environments: obviously corporate IT, and our product environment. They're different, but both still need access management. Among the hundreds of applications, there are some real ground rules around financial data, client data, and intellectual property — the things that make our product better than anything else you'll find anywhere in the world.

(00:48):

But when we started our journey, almost everything was based off manual operations — which, again, won't be surprising for most companies that started out in governance. We had dozens of teams supporting all of these processes in a very loosely structured way, mostly email-driven. An email would get passed around: someone's joining, so a bunch of people start their joining process; or someone's leaving, and you start their leaving process. That startup approach doesn't really scale very well. It would require continuous extension and headcount, on top of the capability to actually do what we do. And without centralized control of governance, it became quite difficult to keep proving that we were doing the right things for the right people — and to do it in a way that was real time.

(01:44):

So I had a slogan that people who work with me, internally and externally, have heard probably a bunch of times: our motivation to do identity governance is not just to fill some sort of compliance requirement. Compliance and audit artifacts are useful byproducts of good governance. In fact, speaking to some of the folks in the room today, I find that many organizations start their identity governance journey because there's some compliance requirement, and they treat that journey in many ways like an IT service-desk ticket-management problem. They want to be able to prove that someone requested access, prove that somebody approved access, and prove that somebody provisioned the access. And all of these things, in the end, can't be manual tasks — that's what the identity governance tool represents. So you can show, if an auditor comes in and says, "Hey, how did this person get the access that they have?"

(02:52):

When we were looking to choose a technical partner, we were definitely tired of these manual operations. The point wasn't to move these tickets from ServiceNow to some identity governance tool and just complete the same cycle of manual requests, manual approvals, manual provisioning. And we found that Bravura had kind of the same general intellectual approach to process-based automation: you start by defining the process. You make sure that all your internal partners are also accustomed to the new process — whatever that process is going to be — and then you actually automate it. You make it work, and you make it repeatable.

(03:35):

As is natural, you first master the identity building blocks, right? You're not starting with role-based access control. You start with the very basics — what do I do when someone joins? What do I do when someone leaves the company? What do I do for a rehire, a transfer, or any of the lifecycle events we all have to deal with in the identity space? Once all of those processes are defined, you can move on to the things like role-based access controls and attribute-based access controls.

(04:10):

In a sense — as I said earlier, we have two different worlds: our corporate IT stack and our product development stack. The product development side has processes that are simpler, fewer applications, and fewer users; it's not everybody who works at Docusign. But in the end, they had the same hurdle: to manage those identities into and out of the company, based on human resources data.

(04:49):

So, our automation in action. 2025 is on track to have over 1.2 million unique operations executed. Every lifecycle event, every attribute update — basically anything that comes into the HR system — generates dozens of operations across a bunch of different downstream systems, trying to make sure everything is perfectly following that same flow. So if any kind of department change happens, or anything else on that side — which happens fairly often — all that information has to be synchronized, so that no system is out of synchronicity.

(05:34):

The corporate identity governance environment manages over 20,000 unique permissions across the landscape. It could be more if I counted differently, but I'm trying to look only at the active things we actually care about — not, you know, every distribution list that gets created in a workspace, because at Docusign everybody can create those.

(05:58):

On average, a standard user has approximately 101 unique permissions to do their job — and that's across the board, irrespective of what your job is. The average is right around there.

(06:12):

Our most recent analysis, from October — so just a few weeks old — shows that 87% of access that users have at Docusign is now granted through automatic, policy-based assignment. Which, in my opinion, is a fairly good place to be. That means the 13% that's left over goes through access requests.

(06:41):

And access requests are a standard and healthy part of identity access management. You don't want to grant everybody everything every time. Even though least privilege is a thing, there are things that should require an approval — and that represents about 13%.

(07:02):

Certain subpopulations are faring even better. Our developers are at 93%, so more than nine out of ten things they use are being delivered through automated processes — where there's no end-user interaction, no approver interaction, and absolutely no manual provisioning.

(07:29):

So that should set the context. But if our success story ended there, my presentation would be a little shorter — I'd stop it. However, unfortunately, we've seen situations in the past where a user would be offboarded. They'd be effectively locked out — whether it was a quarantine situation or an offboarding — and yet their application sessions lived on. And that's not cool. These were not robot accounts. These were not malicious accounts. This was just a platform gap between our intent and the actual enforcement of what we were trying to do. And in a fully SaaS environment, the concept of mastering applicative sessions is super important.

(08:20):

If you looked at it from a pure compliance perspective, we were meeting and exceeding those objectives — users were getting terminated correctly. If you looked at the logs, you would see they were offboarded in terms of what it looked like in our directory, and offboarded in terms of what it looked like in Okta. But they were still logged into Salesforce, still in Zoom, or in any of the other tools they may have had a session in.

(08:46):

Because Okta doesn't natively support universal logout. In fact, I don't believe any of the large market-share IDPs do — and it's also because a lot of SaaS tools don't support it either. So there's no magic button you can push that makes session termination something that automatically happens for you. We found out that the right combination of timing gaps here could still leave access open.

(09:21):

The classic solution in many companies would be to say, "Hey, we have DLP, we have log detections, and we can find and react to misuse or abuse while that connection is still there." And yeah, those things are really important — our security team did a great job of making sure that when something was getting offboarded, they had their logs, scrupulously, for the standard user. But I don't think it makes sense to remain in a purely reactive posture.

(09:44):

We wanted to actively manage — and I put in parentheses in my notes, actually govern — this offboarding process, and not just have a purely compliance box-check where we can say we offboarded each person. So we want to be able to reach into the session layer and actually ensure that access was really removed.

(10:14):

So we worked with our partners, Bravura, and we extended connectors for the systems we were really concerned about. We're not doing this for every application — not every application supports it — but the big ones, like Okta, Google Workspace, Azure, and Zoom, do support it. So, to make things a little bit easier, here's a quick representation of what we do.

(10:36):

On the left-hand side, you'll see Workday, which is our HR system of record, and you'll see that all the planned lifecycle events come from there. If you look down, you'll see ad hoc quarantine events, because we have lifecycle processes that can quarantine. Those can be triggered by people — HR, for example — in the unfortunate situation where they're walking somebody out of the building, and the discussion didn't happen to be very positive. They can trigger it and make sure the user is losing access basically in real time.

(11:18):

Security is in the same situation. If somebody feels like a user is seeing something they shouldn't, then — up at the top — we have security detection integrations that basically allow for the case where, if an automation detects, through observability or other information, that an account is being used in a way that's unexpected, it can also quarantine that account.

(11:39):

Now, what's interesting is that our rule is that our quarantine operation should not be destructive. So we're not preventing users, we're not taking away their access, and we're not modifying their set of permissions in various systems. What we are doing is making sure they're effectively losing access at the session level. You see on the right-hand side all the API calls — again, there are more systems than those — but these are the systems where we make the API call to make sure the sessions are getting terminated.

(12:19):

So we now almost have instantaneous session termination handling. Some systems are slower. Microsoft, for example, will take multiple minutes. Their API response will be an "OK 200" — and "OK 200" means "I received your request." It doesn't mean I've actually terminated those sessions by the time it follows through the various different levels of the Azure stack. It can take five to ten minutes, and those are things you have to account for and be honest about. So — do you do the session termination? Yes, I did. When did you do it? Here's my log. When did it become effective? In the few minutes that followed. I can't guarantee in advance exactly how long that is.

(13:04):

For some systems, we're actually reaching farther than web sessions. There are lots of salespeople at Docusign, and there are a number of sales tools that use the Salesforce platform as a way to log in. Salesforce then grants OAuth tokens to those other systems, which allow Salesforce users to use Salesforce but also a bunch of other applications. If you look at the session-termination tooling available on the market, it will only go and kill web sessions. We want to go a bit farther, so one of the things we do is look up all the OAuth tokens that Salesforce granted to other applications and kill those as well — making sure the affected users lose access to all of those applications at the same time, across all of their places.

(14:00):

So now no one has to guess whether a user has actually lost access. No one has to only look at the Okta log or the directory to see, theoretically, when we opted them out. And for audit, we can conclude exactly what happened and when.

(14:21):

Now we're talking about a slippery slope. While it's possible to extend connectors for any identity governance tool to do a bunch of things, the types of automations that we should be doing in identity governance should stay in identity governance. There are folks within every company who, for business reasons, want to do what I would call SaaS operations. I think it's important not to cross the line and try to do everything in an identity governance tool. So session termination didn't come out of the box — it wasn't something we were supporting immediately — but we added that capability in partnership and made sure we could do it. That doesn't mean we should try to do absolutely everything.

(15:13):

Let me give you an example. If somebody leaves the company and the business comes to me and says, "Hey, when somebody leaves, why don't we do this thing based on the user lifecycle where we reassign all the tickets assigned to that person to somebody else?" — my answer would be that's not identity governance, that's SaaS management. Or if somebody says, "I want to make sure a manager receives access to the user's documents in Google Workspace" — you're halfway there, so maybe we'll do it in the identity governance tool. But the idea I'm trying to keep in mind is that identity governance is not meant to be an automation free-for-all. You might say, "It's a great tool, we can use it to do a bunch of automation" — but it is not SaaS governance, and you shouldn't try to share the same responsibilities across those steps.

(16:09):

So I say to you: if someone leaves your company today, and you were asked, "Are you absolutely sure that this person no longer has any access to all the tools they may have used today?" — can you emphatically say yes? Or would you say to yourself, "Well, there's a session timeout — reached in a few hours, or 12 hours, or 24 hours, or a week"? It's an interesting question to ask, and in a lot of regulated environments, you probably want to have an answer to it. Thank you.

Bart Allan (16:42):

Thanks, Peter.