Skip to Main Content

Software Bot Implementation Q&A: The Future of Identity and Software Bots

Recently, this large, national bank decided to turn to robotic process automation as a way to help the bank streamline application and resource provisioning, which previously required time-consuming manual processes.

We covered their move to robotic process automation in the post, National Bank Readies Itself for the Rise of Software Bots. Because implementing software bots is a new topic to many, we thought it would be helpful to take the subject a little deeper and share our conversation with the bank’s identity and access management development manager. This executive helped to lead the robotic process automation program at the bank and has 15 years of experience in identity and access management implementations and management in the finance, higher education, and retail industry verticals.

Where do you see RPA heading five years from now? If you let your imagination run, it can really get interesting where AI and cloud data could possibly take software bot technology.

We were just discussing this on a call this morning. Today, a human can decide. We were talking about toxic combinations. We want to make sure that somebody who has access to the payroll system doesn’t also have access to the payment system. You don’t want to give them access because they may want to pay their bills with somebody else’s money.

A robot cannot make that decision today. It’s not going to go rogue on you. It’s going to do whatever you told it to do. It’s going to follow that process. So toxic combinations, not that they should, but could be a little bit more flexible because it’s specific to that process. A person may not be able to have the same access that a robot may have. For that one thing because the robot can’t make the decision, “I’ll transfer money to somebody else.” Now, the risk is that the robot can be hijacked. For this risk, you need to make sure that there’s enough security around the robot’s credentials so that it can’t be hijacked.

But five years from now it gets interesting because you’re wondering what happens when someone wants to make this process a little bit smarter. They decide that they want the bot to be able to make some decisions. They will want to provide a little bit more insight to a process and potentially allow the robot to make some decisions that may be useful to the process. But you have to start building a better understanding of the entitlements involved, and I think the understanding and the treatment of those robots will be essentially different five years down the road than it is today.

It seems to me, and this just may be a bias, that you can provide humans some degree of leeway, as long as the right levels of monitoring are in place. A robot, however, is always going to do what it’s told, so you have to be very careful who can tell it what it can do and what it can be told to do.

Exactly. And that’s why you want to make sure that the scope of access is limited to the things that are specific to that process. You don’t want to give the robot full administrator rights to a system. That’s a bad idea. But again, the knowledge of that resides with the process owner. We could guide the business by saying, “Hey, you shouldn’t be giving your robot access to administrator rights.” But it’s possible that application, and the way it is managed, requires the administrative capability to automate. Now you have a risk assessment to make. And we’re transferring the risk from a risk assessment that’s been done by a service account to the process owner. And it’s that process owner who essentially absorbs the risk of what happens with that robot.

This is the same thing as a manager. You’re the manager of your team, and you want to make sure your team has the right access, but people can also still make unethical choices. This is why access and identity governance, and all that goes with it, is so important.

And we’re not the only ones doing the robotic process automation. I know that it’s a big thing now in a lot of other organizations. The problem is that it’s not being managed right. And if you don’t start from the get-go, managing it later is a nightmare. We are already seeing that. Now that we’re looking at it, I’m glad we’re starting now.

But, you know, if you are five years down the road and your robotic process automation organization has evolved, but you don’t have the right processes in place, you’re going to be behind. It’s going to be tough to try to get in the middle of it and be able to govern that.

I imagine if you don’t govern these RPAs now, it’s going to be really tough to do so in the future. And I would also imagine there’s a competitive-edge factor here, too, because those that get it right sooner rather than later will have an efficiency edge.

 Definitely. The faster you’re getting access managed across the organization, and the security team can properly govern these processes, you enable the business to move quickly. In that sense, it definitely gives the organization an edge. We’re able to build processes quickly and govern them at the same time. We’ve put something in place quicker and reduced the risk. If you don’t have that, they’re still going to implement it quickly. But the risk has just now gone up.

I believe so, too. And I think that the risk part of the equation will rise exponentially. Yet, it seems that in some ways, in many ways, organizations have grown better when it comes to managing identity basics — especially from the days when it was predominately spreadsheets and binders.

Actually, I was lucky we had a spreadsheet. On the mainframe side of our enterprise, we had different applications and we would only certify these applications twice a year because it was such a huge pain. The printouts were massive. And we would send them through the company mail, to each manager.

We’d have the managers review the user’s access. And each manager at each location would verify the user’s access or remove the user’s access. And we’d spend two months trying to make sure that the user’s access was legitimate or needed to be revoked. And we’d then spend two months trying to remove the access that they’ve said should be removed. It was a painful process.

Hopefully, we don’t see as much of that anymore and organizations are more mature today.

Some organizations, yes. But those that aren’t, it’s not all their fault. It’s not that hard to build a web service that provides the ability to do provisioning. You would think that since it’s 2019, it shouldn’t be that hard to do that. But many applications today actually have zero ability to be able to provide a secure API for provisioning.

They may have all of this great technology for the business to do its thing, and that’s what the business cares about. But when it comes to security, the business doesn’t always understand the challenges they bring when they select an application that doesn’t support any capability for automated provisioning, and the cost associated with having to assign a person to that provisioning task.

 These are the manual processes that are ripe to be automated by RPAs.

That’s where the idea of building an RPA option comes in. I was very skeptical at the beginning because I didn’t necessarily want a robot to learn what a person does to do access provisioning. You are giving that robot highly privileged access, essentially to different applications.

But at the same time, if we can govern those bots properly we can then give an edge to the business because we will be able to provide a way for the business to provision these applications in an automated way.

I think there’s quite a bit of accelerated disruption coming in the years ahead. And companies must get on top of this or they’re really going to face very real competitive disadvantages, and RPA can play a central role in this.

I think it is. I see the benefits, but I see the many challenges with it. But you can’t just say no to the business. We don’t have a job if the business does not succeed.