Secure Disconnected Apps That Don't Support SSO or SCIM
Welcome, everyone, to the webinar series. Today, our topic is “Securing Disconnected Apps with Cerby: Identity Lifecycle and Governance for Apps Without APIs.” Cerby is solving one of the biggest blind spots in identity security: disconnected apps. These are apps that don't support APIs or SCIM, and they make up more of your app ecosystem than you might think. My name is Sean Hickey. I’m the Director of Customer Solutions at Cerby. I help our customers understand how Cerby can work in their environments, including through demonstrations and testing. Kyle Harris, a Principal Solutions Architect on my team, will be answering any Q&A questions that I’m unable to get to. Webinar Objectives and Structure The objective of this webinar is to explain how Cerby extends lifecycle management to all applications. We’re going to start with the identity and security challenge, move on to Cerby’s approach to identity lifecycle management, show a live demo, and end with a final Q&A. I encourage everyone to engage as much as possible. You can ask questions using the Q&A feature, and we’ll also have polls as we go. I'm going to go ahead and pause after each slide to review and respond to any questions. Identity Governance and Administration, or IGA, and Identity and Access Management, or IAM, tools are better than ever. Modern applications that support standards connect quickly, but many applications don't support standards such as SAML, OIDC for SSO, or SCIM and APIs for lifecycle management. As a result, a lot of provisioning and deprovisioning is still tracked through ticketing systems or spreadsheets. In the worst-case scenario, there is no visibility or control over many of your applications. Oftentimes, disconnected applications are left behind. I saw this firsthand. I spent much of my career specifically in identity, both in the governance and IGA space and in the IAM space, with Saviynt and Okta. Often, I’d see great success at the beginning when connecting applications, but the full vision behind those investments was never realized because we could not connect all of the disconnected applications. That could be because of technical limitations or because it was simply too difficult for the business. All right, so far, no open questions, so I will keep going. So, first poll: Does your organization struggle with managing disconnected applications? These are applications that are outside of IT’s reach. An easy way to think about this is: Do you have any applications where end users request access, maybe through an IGA or IAM solution, but the final provisioning step is still manual? Hopefully, it goes through a ticketing system. In the worst case, an email is sent to a manager or application owner, and they get to it when they can. There may be no audit trail, or the audit trail may be very difficult to reconstruct from spreadsheets and emails. Poll Results on Disconnected Applications All right. Well, that’s kind of what I thought: 100%. I’m not sure if everyone can see that. Every respondent said they’re seeing this issue, which lines up with what I’ve seen across our customers. I was actually a little surprised. I’ve been in this space for a long time, and as I’ve focused more specifically on disconnected applications, the scale of the problem has become much clearer. I knew it was a big problem, but the more I talk to customers, the more I see that it’s even larger than I thought. In the past, many customers knew there was no practical way to solve these issues without standards, so they often didn’t even include these applications in the scope of their projects. And that’s one of the reasons I came to Cerby. I saw that there was a way we could solve this problem, and I was passionate about helping customers and colleagues tackle the issue. Over 40% of business applications are not managed by IT teams today. Risks of Disconnected Applications Failing to connect applications to an IAM or IGA solution introduces security, operational, and compliance risks that weaken protection and reduce efficiency. I put together a few examples of the negative impacts of disconnected applications. There are many more, but these are the ones that come to mind first. One: security risks. Delayed or missed access removal or lack of centralized access control. Second, operational challenges. Increased IT help desk workload and poor experience for end users. Three, compliance and audit issues. A complete lack of audit trails or, even worse, failure to meet compliance requirements. And lastly, business impact. A higher risk of data breaches and lost productivity due to access delays. I'm going to pause here for a second and see if there's any questions. Okay, so one question, I'll read it for you. What would you say to project teams that aren’t prioritizing this type of integration work over other business priorities? One of the slides we’ll cover shortly addresses this. What I often see is that this is not an either-or decision. If you already have an IGA or IAM solution, your organization has already made a commitment to protecting applications. Rather than looking at this as a new project, you can look at it as a way to realize the full value of the investments your business has already made. We'll dig into that a little bit deeper later. Extending Existing Investments with Cerby Cerby extends your existing IAM and IGA investments to support every application in your environment. This is the heart of the matter and ties directly to what I was just saying in response to the question. Cerby connects to your existing solutions using industry standards such as SCIM and APIs to perform the last-mile actions in any application. For instance, a user may be granted an application through an approval flow in your IGA solution. We’ve probably all seen this: someone requests access, and someone else approves it. Today, that request probably goes to a manual ticket. When the team with administrative access to the application has time, they go in and fulfill the request. Then they go back into the ticketing system and mark the request complete. While that does give you access, it's slow. And you still don’t have an ongoing audit trail. That’s a one-time event. To get that information again, you have to manually go back to the application. All application integrations are built, monitored, and maintained by Cerby as part of our SaaS solution. We support well over 1,500 applications today, and we’re built to onboard new integrations quickly for our customers. That's one of the things that we do first with our customers. We go through the applications, prioritize the list, and we put together a plan of how we're going to quickly onboard the applications. Gone are the days of long professional services engagements and re-engagements when an application changes and an integration breaks. Everything in that flow is covered by and monitored by Cerby. You are not going to have to reach out to us to tell us that the application changed. We're actively monitoring it. None of the infrastructure lives in your environment. This is a SaaS solution. Many of our customers already have investments in recognizable IGA solutions such as Veza, SailPoint, Saviynt, Microsoft, and Oracle; IAM solutions such as Okta, Microsoft, and Ping; and workflow tools such as ServiceNow. The reason why that's so important is because you already have these processes in place for approvals, deactivation of accounts, certifications, and audits. We’re not going to change those flows. Cerby can be introduced into the existing process to replace today’s manually provisioned applications with an automated process. We do this primarily through APIs or SCIM. For instance, if I add someone to a group in Okta, that change is automatically visible in Cerby, and Cerby assigns the user to the application with the appropriate permissions. If I’m starting with Saviynt and onboarding a new user, access could come through a birthright rule or an approval flow. Instead of the last step going to a ticket, it becomes an API call to Cerby, and Cerby immediately provisions the access. If access needs to be removed, the same idea applies. Deactivate the user in one of the systems or change the role, and the access is revoked. When you’re running a certification campaign, one of these tools can reach out to Cerby, pull back the current access list, and let you complete the certification. Gone are the days of relying on emails and spreadsheets. I was one of the people in my past life who had to come up with scheduled tasks, spreadsheets, different ways to collect user data. I know the pain. It's one of the reasons why I moved over to help customers. We also have customers that integrate with workflow tools. We want to meet our customers where they are. While many of our customers have IGA and IAM tools, some do not. Some are using simple identity providers. Some have homegrown processes today. Some use ServiceNow for approvals and removals, but Cerby still adds value by automating those tasks. We even have customers that work directly in Cerby, using groups to create simpler roles and assign access to end users. I'm going to pause for a second and look at the questions. Do we need to use a browser extension for Cerby to work? For lifecycle management actions, no. Those are handled in the backend as a service. For this demo, I think it’s important to show not only provisioning, deprovisioning, and access retrieval for certifications, but also the audit log so you can see who is signing in and when. I consider that in scope for today’s demo. There are other features we won’t cover because of time, but this is one I do want to show. And the answer is yes. Browser Extension for Non-Federated Applications For applications that do not support federation and require a username and password, we have a browser extension. The extension enters the username and password, and Cerby can also handle the MFA. We’re going to see how that works in a second, so I won’t go any deeper into it yet. I appreciate the question. I'll pause for one more second to see if there's any additional questions before I move on. Okay. With Cerby, you can extend IAM and IGA controls to every application, even those that don’t natively support identity standards. It’s important to note that this works for both browser-based and thick-client applications. Integrating with Identity Providers Back to the previous question, for browser-based applications, the login's going to be through the browser extension. That can be on-premises, so something that's behind your firewall, right? Or it can be publicly facing. Same thing goes for thick client applications. For on-premises applications, we have an agent that makes outbound-only calls to Cerby over port 443. We automate provisioning and deprovisioning across all applications, ensuring users get the right access instantly and lose it when they no longer need it. We enforce consistent access controls by extending identity governance to every app, keeping permissions accurate, up to date, and aligned with security policies. Simplifying Audits and Compliance We simplify audits, access reviews, and compliance by centralizing visibility and enforcing governance without requiring manual work. That’s important because the value goes beyond simply making audits easier. I would argue that many applications are left out of audit scope when they shouldn’t be, simply because there is no visibility into them. The browser extension I mentioned a moment ago also allows us to see who is signing in to which applications and can suggest applications your organization already owns, steering users toward those approved applications. We'll dig into a couple of the other features of a browser extension. We won’t have time to cover every feature today, but I’d encourage you to reach out afterward. We can schedule a one-on-one session where I can show you more of Cerby’s capabilities and answer your questions. Lastly, we integrate with SIEM solutions such as Splunk so we can turn previously hidden access and activity data into actionable insights. I'll pause for one more second. Automating Provisioning in SaaS Apps Okay, next question. Can the tool automate provisioning in SaaS apps that don’t support standard provisioning directly, using RPA? Yes, 100%. We're actually going to dive into that right now. So we started specifically with applications that do not support single sign on. That’s why the demo is so important. I want to show you where we started, how users sign in, and how the lifecycle management actions are handled in the backend as a service. So while you can see the browser extension sign in to an application as an end user, the lifecycle management actions happen separately in the backend. In the backend as a service, Cerby signs in to the application on behalf of an administrator to provision or deprovision users, or to retrieve application attributes for certification flows. We’re intentionally built to tackle difficult applications and hard-to-automate use cases. All right. I will pause for one more second to answer any questions in the Q&A before I jump into the demo. As I'm going through the demo, I'll keep on track. I'll take a look over as I go through each section to see if there's any specific questions. And at the end of the demonstration, I'll be sure to make sure that I answer the questions as we go. All right. I’ve been sitting here for a bit, so my session may have timed out. All right. We're still good. Okay. So the first thing that we're looking at now, this is the Cerby dashboard. I'm an administrator in the dashboard, so I have the ability to log into applications, but I also have additional features. Let's look at a couple applications. One of the applications we're going to be provisioning to you today is Braintree. I'm going to go ahead and click on that, and it's going to give me additional administrator options. In the top left hand corner, you're going to notice it says your account is protected. Cerby managed email added. Cerby managed SMS added. Cerby managed 2FA is on. What that means is that I’ve enrolled this account with an email address managed by Cerby. You’ll see here that it says “Cerby Inbox.” This can use your company’s domain. When applications have MFA through email still, and hopefully we're there's not too many of those left, but there still are out there. The reason why we add the email account is we'll receive the email, forward it to the individual or administrator team as desired by our customer. It's up to you. And we'll collect, for instance, that one-time PIN that gets sent over. The phone number is managed by Cerby so that when a one-time code is sent, Cerby can complete the login to the application. Again, it's your choice whether it's kept within Cerby or forwarded on to the end user. And that's where there's this inbox right here. So any inbound requests, you can see them, you can determine who, if you would like it to be forwarded to. And lastly, Cerby can manage soft tokens. We do this for two reasons. First, it provides a much better user experience. Now your end users do not need to know the usernames, do not need to know their passwords, do not need to hold the token on their phones. Second, through our policies, we don’t just say that MFA needs to be enrolled or a password needs to be rotated. Cerby can proactively perform those actions. So now the policies that your organization has set around MFA, around password rotation, can effectively be brought down to applications where you don't have connections with them today, applications that are not federated. You can run health checks to confirm that applications are properly enrolled and configured, giving you confidence that the required security controls are in place for each application. Beyond that, because the end user can no longer sign in to the application without Cerby, the password can be rotated and stored in our vault, MFA can be managed by Cerby, and you gain an audit trail showing who signs in and when. So again, the end user is happy because they only have to click a button. The security team is happy because it has an actionable access log showing who is signing in to the applications. A side benefit is that you can see whether you’re actually using the licenses you’re paying for. So primarily, we're interested in security, but it's always important to understand who's using the applications, how is your investment being used. When connecting Cerby to an identity provider such as Ping, Microsoft, Okta, the end user can have all the tiles here that represent the applications pushed back to their IDP so they can have one place to land. They can log in directly to the application by clicking log on. They can navigate to the application site for the login page. The extension will prefill or they can go to the extension itself and log in. We are a complete vault as well. That's why you see secrets. We'll dive into that if we hopefully have another session together. Collections is a way to manage how your applications appear. So this is I get to pick. I have automation accounts as an administrator, have location one, however I want to organize my applications. Business Hubs are for applications where Cerby is performing lifecycle management functions. Members simply shows all the members within Cerby. You'll notice in the top it says members fifteen and guests five. I’ve connected my Cerby instance to an Okta instance. The members are all coming from Okta. But my organization does not want to pay for accounts in AD or accounts in Okta or contractors or other people. So maybe there's some teams that are using Cerby, for instance, maybe it's a marketing team or someone's coming in just any business application where they need access temporarily or they need access, but they do not belong or have a policy against them being inside of my IDP. They can be added here as a guest user. Teams. You'll notice that I have three teams. One of them being financial applications and the other Okta push groups, got a very creative name. Those both are marked as read only because those are actually mastered by my Okta instance. I created this LCM demo team locally within Cerby. So automatically, if I have groups that are created within Okta, they're going to come down to Cerby. I can then tie those to applications. If I put someone in an Okta group tied to applications they should have access to, Cerby automatically assigns them to those applications. That's key because you do not have to change your business process. I went into that earlier, same thing for your IGA vendors, whether it be Saviynt or SailPoint. You already have your process flows and your business flows that you built today. You do not have to change them. The only difference is that the process happens automatically instead of manually. I'm going to answer one more question. Yeah. It's in this business or a similar user preference. Kyle, if you can answer this question at the end, I’ll dig into the other questions in the meantime. Can you sync apps and users from Cerby and have them show up as an Okta tile? Yes, that is correct. Let me see. I'll sign back into Okta real quick. In this instance, I’m connected to Okta, but it works the same way no matter which identity provider you’re using. Let me just wait for the code to roll. So in this case, I'm just going to sign in to Okta. I’m going to go over to my dashboard. You’ll see Atlassian here; this was actually pushed from my Cerby instance. So if we go into the accounts here, I go to Atlassian. For this application, I extended it from Cerby back to Okta. So that gives you a single-pane-of-glass experience. So it's up to you everyone. As administrators, you’ll likely come directly to Cerby. For end users, you can push those application icons back to the identity provider so they have one place to go. So let me run through. And, Andre, I see your question. When we get there, I will go ahead and show you how you add additional applications. So there's two ways we add applications in Cerby real quick. First, for login functionality and MFA, you can click “Add Item” and find the application for your organization. The second option is through Business Hubs, where, as I mentioned before, we manage lifecycle actions. Demonstration of Cerby's Features All right. Let me keep rolling so we can complete the demonstration, and I will go ahead and answer some questions afterwards. All right. While we’re in Okta, I have a test user for the Braintree Hub. Let me log in to Braintree. Cerby enters my username and password, and on the next screen Braintree requires a soft token that is managed inside Cerby. All right. And the reason why I signed in first is I just want to go to team and show you the users. So the user that we're going to be adding is going to be added the first one through the financial applications group here. Now if we look back at Braintree really quick, we go to teams, we're going to see financial applications here. And I've already set the roles specifically for this group that's coming out of Okta. Let me go to Financial Applications and look for Jordan Smith. I’m going to add Jordan Smith. He’s been added. Now, if we look at the teams, we can see the change. Financial applications. Jordan Smith is now there. While we're doing that, we'll roll over the second application just so we don't run out of time here and we'll go into both of them afterwards and show you that they were provisioned. Second application is a test loan approval LCM application. So if you see here, it has more complex permission sets. When we look at that application in Cerby, I'm going to go to the members. I want you to notice the unmatched users. We'll go back to that in one second. One of the questions that was asked earlier was around, matching users and how we can reconcile. So I want to make sure we cover that, and I put a test user in there because it's a very often asked question. But if we look here, we can see what access they have for this application. When you have a certification campaign, it’s simply an API call to Cerby to pull back the application access. We have a record of everything people have access to within the application. That’s what you use to complete the certification. So you have what are the users that have access to the application, what are the roles, what do they have in the app access, so that fine-grained entitlements. You can actually complete this. This is all happening with applications behind the scene that do not have APIs, do not support SCIM today. So we’re reaching into those applications, performing the lifecycle management actions, and then checking for updates. We do this on a periodic basis. You set the frequency. This is where we're going to see, is there something that's changed in the application, right? Is something out of sync with Cerby? Was something changed outside of Cerby? And that's where we see these unmatched users. So this is an example. Intentionally went in, created a user directly in the application. They were not created through Cerby. That’s why they’re unmatched. Let me go in really quick and add my user here. We have both applications. It was Jordan Smith. Now, this is represented graphically in Cerby. The majority of our customers are doing this through another tool, but we give you the options to create the groups within Cerby to do this or to go in one by one and set the specific roles and permissions for the users. So we're just going to make him a loan officer, click share, that's going to kick off the automation in the background. While we're waiting for that to go, let's go into here and refresh, see if it's completed. And Jordan Smith now has access within Braintree. Okay. So I can get to some questions. What I'm going to do is I'm going to go back to the groups real quick and I'm actually going to remove Jordan so you can see that we disable the accounts as well. So I'm going to go to Jordan Smith, remove his access in Okta. That's going to now reach out to Cerby and automatically revoke his access. In a loan application, let's look at that other user who was unmatched. Thursday test. Super creative name. I'm going to go to Thursday test. I'm going to change him to inactive. Submit. Oops. Inactive. I’m also going to delete him. While we’re talking, I’ll click “Check for Updates” so the reconciliation kicks off immediately and we don’t have to wait. And it's going to go out to the application and reconcile to see where the users are, what users exist. I’m going to answer two questions here before we wrap up. For a new web application that isn’t integrated yet, what are the steps to integrate it? In a one on one session, I'll dive in deeper, but at a high level, there's two paths to integrate applications. Path one, if there are applications that you have sandboxes for, you give us an account, we'll go in and build the integration. That's easier because there's less back and forth. We actually can do any testing on our own and build the integration with you. There's many applications, that do not allow for this. And we have a browser extension called Cerby Scout that allows you to go into applications and capture the steps needed to build the integration. So let me just show you that real quick. I’ll use pickaxe.com because it’s quick to type. All right, I’m going to open Scout. And, actually, I'll just create an API key real quick. Expired one hour. Next. What’s going to happen is that Scout lets me go into the application itself, walk through the actions, and capture those steps. So, see how simple that was? For example, I can select “Create Account,” enter a name and phone number, and walk through the required steps. Now, if I hit stop, you get to preview this as well. This is important because, for many applications, the business owner is the person who knows how the process works. The IT team may not know the business steps required to create the integration. Here you can see the recorded actions. We’re not recording any of the underlying data. You can preview and see what you're sending over to us, just the actions that are being created. Once you go through, you name it, you have the application, and then you tag the type of task. So are we logging into account? Are we removing a user? Are we adding a user? And this is how we can quickly build out those integrations for you. At the end of this, you’ll see a link to our website. There’s a demo button at the top of the screen. We can dig in even deeper. But it's important to know that we're specifically made to build application integrations quickly. We see new applications all the time, and we’re constantly building integrations for them, including login with password rotation and MFA as well as full lifecycle management capabilities. A core part of what we do is build those integrations quickly. We want to see the difficult applications, including homegrown applications. We're going to build them with you. We're going to build them quickly. All right. So in the background, let's get back over to Braintree. Jordan has been removed from the application. That’s an example of removing access from an external source. Let me get back to Cerby here. This is hub. We'll go to the demo app. And we'll notice now that we've reconciled, and we know now that that user has been removed. My super creative Thursday test user. Now, all these actions, like I said before, the reason why I did connect to Okta, I wanted to show you the connectivity. If you go to developer.cerby.com, all these actions can occur from any solution. SailPoint, Saviynt, Okta, Oracle. It does not matter. We intentionally use standards to communicate with Cerby, making it easy to connect different systems. Lumos, Veza, it does not matter. Even if you have a homegrown solution today that you've built for IGA solutions, and there's a couple out there still, I've worked with these organizations before, all you need to do is communicate with Cerby. It could be as simple as group membership. For more complex applications where groups or SCIM do not work well, you can send an API call that tells Cerby to provision a user with specific entitlements or pull a user’s entitlements for a certification campaign. All right. The last thing. So all this activity, we talked about tools like Splunk beforehand. I would encourage you, you have all the activity. So this is going to be anyone who's logged into applications, which you could not get before if they're disconnected. Now you can go to Cerby and pull audit information to see who is signing in to these applications and when. You can pull the information about who has access to the applications back to your different tools to do an audit, Right. At the end of the day now, you're going to have a better end user experience, not just for the users who are using the application, but those teams that are manually doing the provisioning, manually doing the auditing. That's time intensive. And no one wants to be the person who has to go in and manually click through those applications every day. And you don't want to wait a day, two days, three days, for instance, when you have a new employee coming on board for them to get access. With Cerby, it happens immediately. It’s faster and more accurate. All right, let me check out the questions here. Does this support data transfer as part of an offboarding task, such as transferring a user’s data to their manager? We'll dig into that further. So one of the things I think your question is around, can we reassign an account to someone else if they leave? And the answer is yes. One of the areas where Cerby started was social media. If you everyone are aware, everyone probably used X, used Instagram, used Facebook before. If your marketing teams are sharing usernames and passwords today, this is an easy example of the kind of problem Cerby can address. But when you have accounts, like this is in real world, I have an Instagram account here, Cascading View Lodge, shared with my wife. We're both able to log into that application. Neither of us has the credentials or password because the password is set to rotate automatically, and MFA is managed through Cerby. So what's happening is, is I've required in my Okta instance that you have to sign in, go through MFA, be in a certain location to sign in. That session cannot start in Cerby unless those controls are satisfied. That's an important point because all the controls they've already put in place now in your IGA solution, in your IAM solutions are going to be in place, but now they're going to be enforced down to those applications. In the same way, we can reassign that account based on your required time period. For example, if Sean Hickey leaves the organization and Tom Smith should have access to his account for 30 days, you can reassign the account from Sean to Tom and then have Cerby automatically deactivate it after 30 days. So yes. All right. Closing Remarks and Next Steps I'm going to pause here to see if we have any additional questions. So there's a lot of other features that were out of scope for LCM today. I touched on a couple of them because I do think they're important for security and having a holistic view, but I'll give everyone a second to ask any other questions. All right. Think you've answered them all. So, I appreciate it. If you, so there's two ways you can get in touch with us. One, there's a poll that came out and if you say, yes, let's chat. We'll proactively reach out to you. Whenever we reach out to you, it'll be someone either myself or someone from my team who will specifically work with you. Bring your list of applications and your questions. All of us have deep identity experience. We can help you understand not only how Cerby works, but also how Cerby fits into your environment and works with your existing processes to make meaningful changes quickly. Second, if you go to cerby.com, you’ll see a “Request a Demo” button in the top-right corner. If you request a demo, someone will reach out to schedule time with you. We’ll talk about how Cerby can help your business, and someone from my technical team will walk you through how Cerby would work in your environment. If there's no other questions, I really appreciate everyone's time. Someone asked whether this session is being recorded. The answer is yes. We’re going to have these types of webinars regularly. Go check out our LinkedIn profile or website to find them. And feel free to reach out. You can find me on LinkedIn, use the demo link on our website, or click “Yes, let’s chat” in the poll, and someone from our team will reach out to you. I really appreciate your time. Thank you.
Cerby extends your existing identity stack to disconnected apps: the applications that don't support SCIM or APIs, so your identity provider and IGA tools can't manage them. In this Cerby webinar, Shawn Hickey walks through how Cerby automates identity lifecycle and governance for those apps, and demonstrates it live.
What are disconnected apps?
Disconnected apps are applications that don't support common identity standards like SAML, OIDC, SCIM, or security APIs. Because your identity provider and IGA tools can't reach them, access is provisioned and deprovisioned by hand, tracked in tickets or spreadsheets, and often left out of audits entirely. More than 40% of business applications are not managed by IT today.
How does Cerby help?
Cerby completes your identity program rather than replacing it. It connects to the IGA and IAM tools you already run (Okta, SailPoint, Saviynt, Ping, Microsoft, Oracle, ServiceNow) and performs the last-mile lifecycle actions on the apps those tools can't reach, using SCIM and APIs. Your existing approval, certification, and deprovisioning flows stay the same. The manual step at the end becomes automated.
What the webinar covers:
- Extending provisioning, deprovisioning, MFA, and password rotation to apps that don't support SCIM or APIs
- Keeping your existing IGA and IAM flows, automated instead of manual
- Support for browser-based, thick-client, and on-prem applications
- Turning access and activity data into audit and SIEM insights
- A live demo of provisioning, deprovisioning, certification campaigns, and building integrations with Cerby Scout
- Offboarding and account reassignment, including shared accounts like social media
Presenters
Shawn Hickey
Director of Customer Solutions
Cerby