Publication Date: 23 March 2025

Abstract

This is the first of a series of reports on specific vendor offerings that enterprises should consider as they modernize their Identity and Access Management (IAM) foundation. We’ll start with a vendor that has a unique approach to “Zero Standing Privileges” (ZSP) – enabling context-aware access in multi-cloud environments.

While most large enterprises already have a Privileged Access Management (PAM) solution, there are significant weaknesses associated with most PAM deployments that are becoming increasingly exposed from a usability and security perspective.  Advanced functions such as behavior and activity monitoring, risk scoring, assessing the trustworthiness of the end user, administrator, or AI agent and support for multi-cloud and hybrid environments are areas that need to be improved.

This report focuses on a relatively new vendor in the IAM ecosystem worth considering: SGNL. Here we describe SGNL’s capabilities with particular focus on facilitating multi-cloud secure access while better supporting the current pitfalls or missing pieces of many current PAM and access control deployments. To support our assessment of SGNL, we’ve included a typical use case (which TechVision directly experienced when working with our customers) and we’ll examine how SGNL addresses these use case requirements. We’ll then conclude with a set of pragmatic recommendations and an enterprise action plan for improving enterprise access control capabilities via SGNL deployment.

Authors:

Doug Simmons Principal Consulting Analyst [email protected]

Gary Rowe CEO / Principal Consulting Analyst [email protected]

 

Executive Summary

In reviewing most of the high-profile breaches over the past decade or so, it is apparent that the ultimate targets for most hackers are the administrative accounts used by systems administrators and administration-centric applications. “Privileged Accounts” for Operating Systems like Windows and Linux, network and security devices, cloud platforms, database servers, and web servers – as well as those embedded within applications to perform administrative functions in application-to-application communications are the top prize for hackers and thieves. These administrative accounts are privileged user accounts, in that they enable the human or agent to configure environments and access the data contained therein. This sort of legacy administrative access control generally relies on standing access for specific individuals (or roles). From a stolen credential standpoint then, once a hacker has heightened access to a single server, database or device, the path often opens to move laterally within the infrastructure to hack deeper and deeper within the enterprise – or beyond.

To help reduce such an attack surface that enables administrative account hijacking, solutions residing under the banner of Privileged Access Management (PAM) have been available for quite a while. While typically supporting credential-based standing access, such solutions have been on the market for nearly two decades now and have gradually improved to the point where most enterprises find them reasonably compelling. That said, the overall footprint for PAM deployments across many enterprises remains somewhat patchy, especially in multi-cloud environments.

However, while PAM deployments proceed in an effort to more securely manage administrator access, there needs to be a means to establish more comprehensive, contextual and auditable capabilities reflecting all identities and access rights – whether end users, system or application administrators or application entities such as AI agents. And these capabilities should decouple specific identities from standing access.

The key intersection should occur with Identity Governance and Administration (IGA) and Runtime Access Control. These two foundational IAM Capabilities typically enable policies and processes that institute a keen level of awareness and monitoring of ‘who has access to what, for what purposes, for how long and under whose authority?’

TechVision Research had the opportunity to speak at length with Ian Glazer, Vice President of Product Strategy at SGNL a couple of weeks ago. The purpose of this meeting was to understand what SGNL’s (https://sgnl.ai) approach is to Identity and Access Management (IAM), Identity Governance and Administration (IGA), Role Based Access Control (RBAC) and Privileged Access Management (PAM), and how their approach differs from the many existing vendors in this space.

SGNL – backed by security technology investors including Cisco and Microsoft, is a growing 4-year-old company based in Palo Alto, CA, is focusing extensively on privileged access and in particular, removal of “standing access” to IT resources, such as cloud infrastructure, developer code and customer data – to name just a few. This is not just for administrative access, but for basically all access from all users who have access to critical or high-risk enterprise information. Their approach is based on contextual awareness of myriad conditions that exist at the time of access – in other words, capturing and leveraging real-time signals from multiple sources.

TechVision values this approach and finds it intriguing in that SGNL’s runtime access control model enables a viable form of Just in Time (JIT) access, which is the capability we have been championing for several years.  JIT access is not just for administrative access – but for any access to sensitive enterprise information. This is key, as we’ve been pushing for many years for a solution that essentially brings many of the key capabilities of a traditional PAM solution and extends these to the general knowledge worker population as pertains to sensitive information access. Key to this discussion, however, is that SGNL takes JIT access a step further by enforcing zero standing privileges (ZSP) – thereby incorporating runtime contextual awareness much more robustly.

No matter how far along you are (or aren’t) in upgrading and modernizing your IAM capabilities, don’t delay moving the needle forward. If you’re behind, don’t boil the ocean – start with the highest risk environments and make the necessary improvements. If you’re reasonably far along, keep it up by adding the features such as those provided by SGNL that will improve your multi-cloud cybersecurity, DevOps, automation capabilities and better knowledge worker access to sensitive organizational information. There is no longer any excuse for doing nothing. TechVision recommends a structured approach to identifying key access control risks across this spectrum and has developed a Reference Architecture that is very useful in evaluating the set of capabilities necessary for your future state access control foundation. With over 30 years of helping our customers identify and mitigate these identity-centric risks, TechVision can help with this process.

 

Introduction

TechVision Research recently had the opportunity to speak at length with Ian Glazer, Vice President of Product Strategy at SGNL and long-time IAM leader. The purpose of this meeting was to understand SGNL’s (sgnl.ai) approach to Identity and Access Management (IAM), Identity Governance and Administration (IGA), Role Based Access Control (RBAC) and Privileged Access Management (PAM), and how their approach differs from the many of the existing vendors in this space.

SGNL – backed by security technology investors including Cisco and Microsoft, is a growing 4-year-old company based in Palo Alto, CA, is focusing extensively on privileged access and in particular, the removal of “standing access” to IT resources. This is not just for administrative access, but for basically all access from all users who have access to critical or high-risk enterprise information. Their approach is based on contextual awareness of myriad conditions that exist at the time of access – in other words, capturing and leveraging real-time signals from multiple sources.

TechVision values this approach and finds it intriguing in that SGNL’s runtime access control model enables an improved form of Just in Time (JIT) access, which is the capability we have been championing for several years.  ZSP and JIT are not just for administrative access – but for any access to sensitive enterprise information. This is key, as we’ve been pushing for many years for a solution that essentially brings many of the key capabilities of a traditional PAM solution and extends these to the general knowledge worker population as pertains to sensitive information access.

Note that traditional PAM has been centered on System Administrators (i.e., “sys admins”) who manage (often multiple) cloud platform services, operating systems and network devices and configurations. A mature, JIT-centric PAM solution typically supports four primary types of privileged access activities:

• System Administrator Privileged Management – centered on managing and rotating passwords and access to them.
• Privileged Session Management – involves establishing and monitoring sessions for multiple systems. It functions by authenticating users (e.g., using multi-factor authentication) and then providing user access to shared accounts.
• Application-to-Application Privileged Management – refers to providing applications and scripts access to passwords stored in a password vault. This is basically used to eliminate hard-coded passwords stored in each application.
• Super User Privileged Management – focused on “root” accounts (e.g., root is the superuser on Linux systems). Root / superuser accounts are most often used to make system configuration changes and can override user file protection. These are very powerful, often human-associated privileged accounts that provide the basis for configuring almost everything deployed in the enterprise IT infrastructure, including in the cloud.

JIT PAM means that system administrators – whether human or application functions, can be assigned privileges in near real time using their existing accounts or granting ephemeral access through the mechanisms cloud and other platforms provide. JIT PAM limits the duration for which an account possesses elevated privileges and access rights in that the creation and deletion of an appropriate privileged account is assigned only to meet that specific period’s mission objectives. The “good reason” is to eliminate the risk surface of having privileged accounts that are “always on” and the carte blanche removal of “standing access”.

To make this work, business processes typically initiate IT Service Management (ITSM) “tickets” that are assigned to an individual along with the necessary access request(s) they need to perform privileged level actions on an application or system.

Now let’s reiterate: JIT access shouldn’t only apply to administrative access: we are rapidly moving toward JIT user management for sensitive data access, such as enterprise financial applications, health care applications or any application or system that maintains information associated with regulatory compliance or intellectual property. For a more comprehensive dive into the concepts of PAM and JIT PAM, please refer to the TechVision Research report “Privileged Access Management: Will We Never Learn?”

For balance of this report, we’ll investigate SGNL’s approach to eliminating standing access in support of both sys admins and non-administrative sensitive data access.

SGNL Background

SGNL was founded in 2021 by Scott Kriz and Erik Gustavson, who sold their previous startup, Bitium to Google in 2017. Bitium, was an identity and access management solution that provided single sign-on, multi-factor authentication, user provisioning, password vaulting and directory synchronization for various applications. Similar to Okta, Bitium supported multiple SSO protocols, including SAML, OAuth 2.0, and OpenID Connect. After Google acquired Bitium, the founders shifted focus from authentication to securing sensitive customer data, code, and cloud infrastructure using business context and SGNL was born.

In February 2025 SGNL secured $30 million in a Series A funding round led by Brightmind Partners, a security-focused firm co-founded by Stephen Ward, former Partner at Insight Partners, Home Depot CISO, and ex-Secret Service cybersecurity leader. Additional participation from Costanoa Ventures, Microsoft’s M12, and Cisco Investments brought SGNL’s total raised to $42 million since its founding in 2021, allowing the company to expand go-to-market efforts, accelerate product development, and enhance customer support.

SGNL Contextual Awareness Foundation

Core to SGNL’s value proposition is a robust foundation of expansive contextual awareness. SGNL extends the basics of JIT access requesting and granting by leveraging contextual information (signals) from multiple sources, relying on both open standards (the Shared Signals Framework from the OpenID Foundation) as well as 3rd party proprietary signals. The objective is to remove standing access to critical systems by granting and revoking contextual access in real-time. To accomplish this, SGNL brings in context-based intelligence and prevents both humans and non-humans from freely navigating cloud applications like Azure, AWS, GitHub, and Salesforce, as well as on-prem systems. To be sure, today’s era of persistent identity attacks highlights high-risk standing access as one of the most serious threats to critical enterprise systems.

Traditional IGA, RBAC, and PAM approaches can fall short because they weren’t originally designed for today’s identity-centric security perimeter. SGNL’s approach to access management is more dynamic to achieve Zero Standing Privilege across both cloud and on-prem applications systems.

The SGNL platform is offered in two formats:

• A fully cloud-based, highly available SaaS solution operating in multiple regions,
• An on-prem Kubernetes appliance that can be installed in existing enterprise datacenters or cloud VPCs.

The following high-level diagram illustrates this platform approach.

Figure 1: SGNL Platform Overview (Source: sgnl.ai)

The three primary components of the SGNL Platform are:

1. Policy Engine – this is the repository that contains the rules and conditions for managing access controls. The Policy Engine relies on the data fabric, which includes data SGNL ingests from systems of record (such as ServiceNow or Workday) as well as any signals received – be they standards-based Continuous Access Evaluation Protocol (CAEP) or proprietary. All of this data is considered when evaluating policy.
2. Identity Data Fabric- this is a graph database that stores all the information SGNL retrieves from systems of record, such as existing IAM systems (e.g., Okta and SailPoint) or business systems (e.g., ServiceNow and Salesforce) or HR systems (e.g., Workday and BambooHR). Additionally, the ID Fabric incorporates all the near real-time signals received – whether the signals are based on the Shared Signals Framework or proprietary signals.
3. CAEP Hub – this is the “event framework” that allows SGNL to receive, reason again, transform, and transmit both standards-based near-real time signals (e.g., CAEP and Risk Incident Sharing and Coordination (RISC)) or proprietary ones. CAEP Hub allows the user to describe what signals are important to them (e.g., “seeing a change in session risk score”) and what actions to take if the signal is received (e.g., terminate the session in Okta, tell SailPoint to deprovision the user from a group, and send a message to a specific Slack channel to kick-off further Security actions.)

SGNL’s policy management system allows policy reuse across multiple enterprise systems. This approach allows the application owners to build and maintain policies in a more straightforward, human-readable format while allowing identity and security teams to establish global controls and policies. A snapshot of how this is configured is illustrated below:

Figure 2: SGNL Policy Overview (Source: sgnl.ai)

SGNL’s dynamic access platform is built with microservice-based architecture, which better supports the level of scalability, performance and reliability required by enterprise customers. It also allows for regular updates helping to ensure the timeliness and accuracy of the data supporting access decisions. Coupled with SGNL’s enterprise identity graph database, the platform can provide API response times of under 100ms at the 95th percentile, according to SGNL’s published results.

How the SGNL Platform is architected and integrated across the enterprise is illustrated in the high-level architecture shown below.

Figure 3: SGNL Platform Integration Overview (Source: sgnl.ai)

SGNL Integration

A major challenge with IAM/PAM/IGA over the years is how easy or difficult it is to connect with and properly include data from various disparate environments. This is particularly challenging for large organizations. SGNL seeks to address this with an extensive library of pre-built “system of record” connectors to common enterprise systems and allows enterprises to add custom or homegrown systems to the platform. These pre-built connectors are important in expanding the base of connected systems and supporting real-time decisions.

These connectors can be used to protect enterprise systems as well as to ingest contextual data from systems of record. SGNL connectors are available for:

• AWS
• SalesForce
• GitHub
• Azure
• Snowflake
• CrowdStrike
• Apigee API Gateway
• dev
• Workday
• ServiceNow
• SailPoint
• MuleSoft
• Okta
• Kubernetes
• PagerDuty – (an operations automation and incident response platform)
• Please see https://sgnl.ai/product/integrations/ for more.

The CAEP Signal Sauce

As shown in Figure 3, CAEP is the open-source Continuous Access Evaluation Protocol, which is a security standard that enables real-time monitoring and evaluation of a user’s access rights throughout an online session, allowing for dynamic adjustments to access based on constantly changing security conditions like user behavior, device status, or emerging threats. CAEP moves beyond the traditional one-time login model to continuously assess access based on updated information. SGNL has complete support for CAEP and the Shared Signals Framework within its CAEP Hub. In addition to that, SGNL sponsors an open-source project to help enterprise and technology providers work with CAEP, called caep.dev.

SGNL’s caep.dev offering includes the following features:

• Register and create streams to Shared Signals Framework (SSF) Receivers
• Generate CAEP events on demand and receive them through your Receivers
• Download scripts to instantly create a SSF Receiver

The Continuous Access Evaluation Protocol was first conceived in a blog post by Google. Since then, an informal standards development effort has grown around it and ultimately merged with an existing working group in the OpenID Foundation, to form the Shared Signals working group.

As an example, SGNL provides guidance such as the following for integrating AWS into the enterprise:

“AWS API Gateway need not know about the policies, systems of record, or any of the data in SGNL – it simply needs to pass to SGNL:

• Who/What is requesting the access (The Principal)
• (Optional) What is attempting to be accessed (The Asset)
• (Optional) What operation is being attempted on the asset (The Action)
• An access token that ensures the Protected System is a legitimate caller into SGNL

Prerequisites

• An existing AWS API Gateway deployment
• A SGNL Client
• A SGNL User Account with Admin privileges
• At least 1 system of record integrated to SGNL, containing principals and (optionally) assets that will be evaluated in access evaluations
• (Optional) 1 or more policies that you want assigned to the integration

Figure 4: Sequence Diagram for Integration of AWS and SGNL (Source: sgnl.ai)

The steps:

1. An API client (e.g. application, microservice) makes a request to the AWS API Gateway containing the request context (e.g. principal (e.g. user), API resource, and HTTP verb “POST”).
2. The AWS API Gateway instantiates the configured Lambda authorizer and passes the request context information and sends an authorization query request to the SGNL access service API.
3. The Lambda authorizer sends an authorization request to the SGNL policy engine.
4. The SGNL policy engine calculates the human-readable policies associated with the authorization request in milliseconds and determines a final decision. (A) The policy calculation results in an allow. (B) The policy calculation results in a denial.
5. (A) The Lambda authorizer returns an allow IAM policy to the AWS API Gateway. (B) The Lambda authorizer returns a “deny” IAM policy to the AWS API Gateway.
6. (A) If the decision returned by the Lambda authorizer is denied, the AWS API Gateway denies the request for the API resource. (B) If the decision is allowed, the AWS API Gateway proxies the request to the backend API.
7. The backend API service sends a response back to the AWS API Gateway.
8. The AWS API Gateway sends the response to the API client along with an HTTP 200 status.

Policies are configured next and can be set to “simulated” or “enforced” to allow designers to test their signal integration and responses before setting to Production (e.g., enforced). More information about setting up SGNL policies for AWS access control is available here: https://help.sgnl.ai/articles/protected-systems/protected-system-api-aws-gateway/

Additive, Non-Disruptive Deployment

One very important factor to consider is how simple, or difficult, it is to deploy an additional component to your overall cybersecurity, IAM and platform infrastructure. After a thousand plus consulting engagements over the years, the team at TechVision certainly knows full well that something can look good “on paper” but be a nightmare to implement. To allay such fears, we’ve done some deep analysis as to what it takes to deploy SGNL into an existing IT ecosystem consisting of “all the usual suspects,” namely, one or more cloud platforms, HR systems, business applications, workforce productivity apps, web-centric, device-centric…

Remember, the CAEP Hub automatically responds to real-time events happening anywhere in the configured enterprise ecosystem. Sessions across enterprise services and apps are dynamically controlled and based on the enterprise’s own policies. No matter what the event, CAEP Hub can act accordingly.

With triggers based on context changes, the CAEP Hub can be set to monitor and act on session revocation, session hijacking, malware, token theft, credential changes, and device compliance changes. For example, the illustration below shows how SGNL reacts to device configuration changes identified by a common endpoint management solution, such as Microsoft InTune.

Figure 5: Example Policy for Device Access Management (Source: sgnl.ai)

With this overview of the SGNL Platform behind us, let’s now look at a bona fide use case for supporting sys admin access to multiple cloud and vendor instances.

SGNL Support for TechVision Use Case

At TechVision, we do a lot of things. We research, assess, recommend, roadmap and often support our customers with specific systems administration tasks when engaged to do so. We have below a use case that we developed as part of one of our existing engagements, which we will use to describe how SGNL can improve the workflow, time consumption and granularity of access.

Use Case Description

Today, it takes our administrator 4 minutes to log into a client’s infrastructure as an administrator to make system changes.  For example, this is the process for AWS admin access:

1) Long into Azure Virtual Desktop – This virtual desktop has the enterprise endpoint protection software and other controls on it, and requires a username, password and MFA (multifactor authentication). In this case the Okta Verify application is used, which has a client installed on the smartphone and uses facial recognition to help validate our administrator. Note that the password is 16 characters in length with standard complexity rules (e.g., CAPs, numerals, special characters).

2) Log into AWS as admin – once our administrator is logged into the Azure VD, he can log into Amazon Web Services (AWS) using his enterprise username as tied to Azure Active Directory. However, he must now pass a second Okta MFA request for AWS authentication. This results in the receipt of a One Time Password (OTP) from the existing SailPoint IAM/IGA infrastructure (e.g., the “identity data fabric”) to be able to authenticate to the AWS login screen.

3) Get kicked out if there is an Internet brownout or after 8 hours and do it again.

Note that the above process is not only time-consuming, but also lacks some core capabilities including:

1. It does not support different levels of admin access – he’s either “in” or “out”.
2. There is no session monitoring or keystroke recording.
3. There is no workflow integration for access requests, approvals or tracking. In this case, the customer uses ServiceNow for IT service management, but ServiceNow is not part of the current workflow.
4. There are no contextual considerations regarding location, time of day, admin “reputation” or vetting approvals, continuous evaluation of contextual conditions, etc. The admin is either “in” or “out”. In other words, standing access remains in place for the duration of the session.

The above is a standard use case for administrative activities in most enterprises today. There are many things that should be improved to support access management going forward including better contextual awareness, on-going monitoring or continuous evaluation and single sign-on. These are basic elements that need to be addressed.  The “typical” legacy process is arduous and weak.  The question we want to answer is if SGNL can support this use case and improve the cybersecurity posture of this organization? We’ll focus on answering this in the next section.

SGNL Support for Use Case

Briefly, here is how SGNL could be deployed in support of the use case we described:

1. The first step to address this use case is to deploy the CAEP Hub and Policy Engine on either AWS or on-premises – doesn’t matter which. Note that SGNL is available as its own SaaS offering on Azure, Google or AWS; hosted in the customer’s own private cloud; or on premises.
2. The Policy Engine should be configured to enable the necessary contextual awareness conditions that must be evaluated during the session log in to AWS. This will assume that the existing Azure Virtual Desktop authentication process leveraging Okta remains in place. This could be modified later, if desired.
3. Configure ServiceNow, SailPoint and Entra AD (and possibly other source systems) to send specific signals to the CAEP Hub that the Policy Engine will use.
4. Configure Okta to accept and respond to command signals sent to it via the Okta REST API. This configuration includes registering as an “inline hook” to authorize access and registering with Okta’s REST API to process session revocation events.
5. SGNL responds to signals received from Service Now, SailPoint, Azure, Security Information Event Management (SIEM, e.g., Splunk), etc. and notifies Okta of policy infractions that will force access revocation on AWS if policy dictates it must do so.

SGNL Within the TechVision IAM Reference Architecture

In the TechVision Research report titled “Architecting and Managing Hybrid and Cloud-based Identity Services”, we define and describe a comprehensive IAM architecture.  We generally advise our enterprise clients to determine their key required capabilities and map them to a template like the one illustrated below. This describes how such a deployment of SGNL would be represented in TechVision’s Reference Architecture for IAM:

Figure 6: SGNL and the fit within the TechVision IAM Reference Architecture

As can be seen, the deployment of the SGNL Policy Engine, CAEP Hub and Identity Data Fabric components resides between the Okta access control “front-end” and the source systems providing signals via CAEP (e.g., Splunk, ServiceNow, Endpoint Management) and the SailPoint IAM/IGA authoritative identity system. Note that SGNL may also perform both coarse- and fine-grained authorization in support of the Access Control mechanism’s Policy Decision Point (PDP) and Policy Enforcement Point (PEP). They have supplanted “legacy” access control mechanisms such as Okta OpenFGA (Fine Grained Authorization) in existing customers.

This architecture supports the key “requirements” from the original use case:

1. Single Sign On with MFA via Okta Verify
2. Session management/termination via the SGNL CAEP Hub and Policy Engine
3. Real time signals integration       with ServiceNow, Splunk and any other source systems in order to receive contextual signals regarding the user’s/admin’s real-time “status” using both open standards (CAEP, RISC, SSF) and proprietary ones where required
4. Elimination of “standing access” and any other policy definitions (e.g., location, time of day, etc.) via real-time contextual signals over CAEP.

As we can see, part of the value in this solution lies in the ability to leverage the existing infrastructure. Modern IAM solutions must increasingly be flexible and support a loosely coupled environment that easily includes existing products, services and data. The SGNL solution, if properly implemented should improve the usability and security posture of an enterprise IT environment.

Recommendations

Hopefully by this point it is apparent that the solution SGNL brings to the forefront of contextual access control for both administrative and workforce IT, cloud and DevOps functions. If your organization is faced with the many challenges associated with PAM, supporting multi-cloud environments, contextual access and support for both granular access and non-standing access, we think you would benefit from considering adding SGNL to your ecosystem.

That said, we recognize that a poorly designed or architected IAM/IGA infrastructure may need a more comprehensive overhaul to reach the objectives promised by any product. But if your organization has some semblance of stability, you should be able to capitalize on the capabilities that an SGNL deployment would enable. To this end, TechVision Research highly recommends that you establish and document your organization-specific Reference Architecture. We strongly encourage you to leverage our templates in our document titled “IAM Reference Architecture”, “Developing a Reference Architecture for PAM”, “Multi-Cloud Cybersecurity Reference Architecture”, and several other of our research reports that explain how to accomplish this. We will continue to update these documents over time, so check for the latest.

SGNL, though a relatively nascent company on the IAM scene, is fortified with some of the “biggest brains” in the space. They seem to “get it” and are prioritizing many of the capabilities TechVision believes will be critical in supporting modern IAM and security needs. The SGNL mission, as is ours, is to improve the cybersecurity postures of their customers with tools that allow incremental improvements initially, leading to a wholesale transformation over time.

We hope you have found this report useful. TechVision Research feels that access control is one of the more critical elements of an enterprise security posture. Zero trust architectures cannot exist without solid access controls that genuinely reflect the risk tolerance of the organization.

Hackers and thieves want your account access rights because that is the way to your data – whether in your data center or in the cloud. This is not fearmongering! We have seen a horrific rise in large-scale, nationwide ransomware attacks in the past 5 years. Both IT and OT environments are both at substantial risk. Contextually aware, granular access control is the most viable means to respond to these attacks.

Action Plan

No matter how far along you are (or aren’t) in your deployment, don’t delay moving the needle forward. IAM and PAM need to support better, faster, data-driven decisions and the stakes are higher than ever. If you’re a ways’ behind, don’t boil the ocean – start with the highest risk environments, solve the most pressing problems and keep moving forward. If you’re reasonably far along, keep it up by adding upgraded capabilities such as those provided by SGNL that will improve your multi-cloud cybersecurity, DevOps, automation capabilities and better knowledge worker access to sensitive organizational information. There is no longer any excuse for doing nothing. Not making a decision is making a decision, and in this area, delays could increase your risk profile, limit the usability of your digital programs (for employees, customers and other stakeholders), and limit your flexibility going forward.

Those organizations that strive to be prepared to protect their broad range of critical information assets in a secure-but-user-friendly ecosystem will be able to do this by developing a comprehensive IAM architecture and deployment strategy. TechVision recommends a structured approach to identifying key access control risks across this spectrum and has developed a Reference Architecture that is very useful in evaluating the set of capabilities necessary for your future state access control foundation. With over 30 years of helping our customers identify and mitigate these identity-centric risks, TechVision can help with this process.

 

About TechVision

World-class research requires world-class consulting analysts and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skillsets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

 

About the Authors

Doug Simmons brings more than 25 years of experience in IT security, risk management and identity and access management (IAM). He focuses on IT security, risk management and IAM. Doug holds a double major in Computer Science and Business Administration.

While leading consulting at Burton Group for 10 years and security, and identity management consulting at Gartner for 5 years, Doug has performed hundreds of engagements for large enterprise clients in multiple vertical industries including financial services, health care, higher education, federal and state government, manufacturing, aerospace, energy, utilities and critical infrastructure.

Gary Rowe is a seasoned technology analyst, consultant, advisor, executive and entrepreneur. Mr. Rowe helped architect, build and sell two companies and has been on the forefront the standardization and business application of core infrastructure technologies over the past 35 years. Core areas of focus include identity and access management, blockchain, Internet of Things, cloud computing, security/risk management, privacy, innovation, AI, new IT/business models and organizational strategies.

He was President of Burton Group from 1999 to 2010, the leading technology infrastructure research and consulting firm. Mr. Rowe grew Burton to over $30+ million in revenue on a self-funded basis, sold Burton to Gartner in 2010 and s