Identity Security

TL;DR

• Attackers typically follow seven steps to carry out an identity attack, and there are ways to protect yourself at each stage of the kill chain.
• Always check if your credentials have appeared in data leaks and change them, implement phishing-resistant MFA, take advantage of JIT for admin accounts, and use the principle of least privilege.
• Preventing attacks is just one piece of the puzzle; you should also take measures that limit the blast radius, ensure you can detect issues if they pass your prevention mechanisms, and leverage automated workflows that respond to issues.

Why Do Attackers Prefer Identity-Based Attacks?

Identity is now the fastest route to critical systems: Humans, non-human identities (like service accounts, workloads, and API keys), SaaS apps, cloud control planes, and AI agents all operate through permissions and tokens that can give attackers a dangerous foothold.

Raising the stakes, identity attacks are more likely to succeed than other attacks, and they’re also harder to detect. When a threat actor uses one of your credentials, they blend in with legitimate traffic, and most security tools miss the subtle signs that point to a compromise.

While it’s impossible to build perfect prevention against all of these attacks, you can implement ironclad defenses. The key is to take a layered approach. With defense–in-depth strategies in place, when one layer is compromised, another layer will block the attack, whether it stems from phishing, credential stuffing, token harvesting, or another identity attack vector.

In this article, we’ll explore the practical steps attackers take to compromise identities and provide hands-on advice for thwarting them at each stage of the identity kill chain.

What are the 7 Steps Attackers Use for Identity Breach?

Attackers typically follow these steps to carry out an identity attack:

1. Initial access
2. MFA or “friction” bypass
3. Privilege gain
4. Lateral movement via identity
5. Persistence
6. Taking action on objectives (data access, fraud, ransomware enablement)
7. Evasion and reentry

Each step links together, enabling the next step in the chain. As a result, a minor compromise can lead to widespread breaches because of privilege escalation, lateral movement, and persistent actions.

Let’s take a look at each step in detail.

Step 1: Initial Access (Credentials or Foothold)

An attacker can obtain access to credentials through phishing campaigns, reused passwords, accidentally exposed secrets in VCS systems or CI/CD pipelines, or by purchasing compromised accounts on the dark web. 

Reused passwords are especially problematic. Despite security training programs, many employees continue to use the same passwords across personal and professional accounts. This practice creates a domino effect: Compromised access to one service compromises access to many others.

What’s a Real-World Example?

In 2021, attackers gained access to Colonial Pipeline’s systems by using a compromised password for a VPN account that didn’t have MFA enabled. This account actually belonged to a former employee, but it was never disabled after their termination. The threat actors used this foothold for a ransomware attack against the company, which provides fuel for about half of the East Coast. System outages cascaded into fuel shortages, and a state of emergency was declared in 17 states and Washington, D.C. Restoring operations took a $4.4 million ransom payment.

How Can Organizations Keep Systems Safe?

• Prevent: Identify and disable all inactive accounts, as they can also pose security risks if compromised. Ensure MFA is enabled for all your users.
• Limit the Blast Radius: Reduce the number of externally accessible services, and require additional passwords and MFA for anything important.
• Detect: Monitor for unusual activity, like authentication attempts from unfamiliar locations or devices or numerous failed login attempts that signal credential stuffing.
• Respond: Leverage automated workflows to immediately disable compromised accounts.

Step 2: MFA or “Friction” Bypass

MFA is just the first line of defense, and it’s not a silver bullet. When attackers encounter MFA, they can employ tactics to get around it. For example, fatigue attacks involve sending a flood of MFA approval requests to your users until they accept.

Social engineering isn’t the only risk, though. Phone-based MFA is vulnerable to SIM swap attacks, which could allow attackers to intercept your SMS codes.

What’s a Real-World Example?

In 2022, Uber experienced a data breach that began when a hacker purchased an employee’s credentials on the dark web. After encountering MFA, the attacker impersonated a security employee, initiated a fatigue attack, and asked the compromised user to accept the MFA requests he sent. Once the fatigue attack proved successful, the attacker gained access to Uber’s VPN; from there, he moved laterally, ultimately gaining full admin privileges.

How Can Organizations Keep Systems Safe?

• Prevent: Use strong MFA mechanisms (Authenticator Apps, Hardware keys or Passkeys) for all accounts if possible, otherwise at least for privileged ones. Implement phishing-resistant MFA, and establish strict proof-of-identity requirements for help desk employees.
• Limit the Blast Radius: Require multiple approvals for high-privilege account resets; require additional passwords for sensitive services.
• Detect: Implement MFA monitoring that automatically denies a flood of requests, and require human approval (with identity verification) before users can add a new authentication device.
• Respond: Whenever you detect suspicious MFA activity, temporarily restrict access for your user until verification is complete.

Step 3: Privilege Escalation

Accounts with permanent administrative rights are exactly what malicious actors are looking for. Instead of standing privileges, a better move is to grant temporary admin privileges through a mechanism like just-in-time access. 

Another problem to look out for? When secrets hygiene is not implemented consistently, and secrets like API keys are stored in VCS systems or wikis, there are simple opportunities for privilege escalation.

What’s a Real-World Example?

In October 2023, Okta experienced a breach after an attacker compromised a customer support engineer’s account. This account had administrative rights, allowing the attacker to view HTTP Archive (HAR) files containing cookies and session tokens uploaded by customers during support troubleshooting sessions. By stealing session tokens, the attacker was able to impersonate legitimate users across different organizations.

How Can Organizations Keep Systems Safe?

• Prevent: Implement just-in-time (JIT) access for administrative accounts.
• Limit the Blast Radius: Ensure admin accounts are specific to a single service and don’t have cross-service privileges.
• Detect: Implement alerts for role changes or permission modifications.
• Respond: Build in automation that responds to a suspicious account by revoking elevated access and reviewing recent actions.

Step 4: Lateral Movement via Identity (SSO, SaaS, Cloud Control Plane)

It goes without saying: When attackers gain elevated privileges, what they’re really gaining is the ability to move laterally through your connected systems. For example, a compromised SSO can unlock access to dozens of applications, and cloud control planes can be easily accessed from anywhere if you have valid tokens.

What’s a Real-World Example?

In 2023, an attacker known as Storm-0558 leveraged forged Microsoft authentication tokens to access enterprise email accounts. The mechanism of attack? Lateral movement from MSA (customer) keys to the Azure AD enterprise system. The breach affected approximately 25 organizations, primarily government agencies, including U.S. State Department email accounts. 

How Can Organizations Keep Systems Safe?

• Prevent: Avoid creating “super admin” accounts that can access all your systems.
• Limit the Blast Radius: Remove unnecessary permissions that might offer access to systems your users don’t actually need access to.
• Detect: Implement monitoring for unusual access patterns, especially accounts accessing systems they’ve never accessed before.
• Respond: When you detect lateral movement, isolate the compromised identity and review access logs.

Step 5: Persistence (Tokens, OAuth Apps, Service Principals, Backdoor Identities)

As soon as an attacker gains access to your systems, they’ll look for ways to maintain it if the original entry point is detected and blocked. Persistence techniques include the creation of OAuth applications, service principals, and API keys. These mechanisms are highly effective because they are often mistaken for legitimate administrative objects and can even survive password resets.

What’s a Real-World Example?

In 2025, Salesforce warned customers that a group called ShinyHunters was using vishing (voice phishing) to trick help desk staff into resetting MFA on privileged accounts. Once they got a foothold in a Salesforce instance, the attackers created malicious OAuth applications that allowed them to maintain persistent access.

How Can Organizations Keep Systems Safe?

• Prevent: Control who can create OAuth applications, and establish lifecycle governance for service principals to ensure they have expiration dates.
• Limit the Blast Radius: Restrict the permissions that can be granted to OAuth applications (for example, in AWS, use permission boundaries or service control policies to limit what IAM roles your OAuth apps can assume); ensure your service principals respect the principle of least privilege (PoLP).
• Detect: Alert on the creation of new applications that require extensive permissions.
• Respond: Maintain an inventory of authorized OAuth apps and service principals, and remove any new apps that are created outside of your process.

Step 6: Action on Objectives (Data Access, Fraud, Ransomware Enablement)

Identity compromise is rarely the final objective for an attacker. Usually, it’s only a stepping stone on the way to accessing data, committing fraud, or enabling ransomware.

What’s a Real-World Example?

In September 2023, MGM Resorts experienced a devastating ransomware attack that led to more than a week of operational problems across 30 resorts, like shutdown slot machines, offline ATMs, and locked-out guests (the downside of digital hotel keys). Attackers gained access by researching employees on LinkedIn, then calling the help desk to request a password reset in their names.

How Can Organizations Keep Systems Safe?

• Prevent: Implement PoLP on both the infrastructure and data layer; require additional verifications before a user can perform sensitive actions (e.g., ask users to reauthenticate with MFA or ask them for a manager’s approval).
• Limit the Blast Radius: Prevent the creation of “super admins.” If any exist in your systems, downgrade their privileges. 
• Detect: Alert on mass downloads or unusual queries against sensitive databases.
• Respond: Implement automation that can quickly restrict access when suspicious data is detected.

Step 7: Cover, Repeat, Expand (Defense Evasion + Re-Entry)

Powerful attackers try to reduce their visibility as much as possible by altering audit logs and disabling security tools. They also wreak havoc by creating multiple re-entry points. Many times, this goes unnoticed: In the wake of a breach, organizations can get tunnel vision and focus only on the initial entry point.

What’s a Real-World Example?

In 2023, a threat group called LockBit demonstrated impressive defense-evasion techniques, accounting for $91 million in ransomware payments in the U.S. alone. The secret to their success? They played the long game. When they gained access to their victims’ systems, they didn’t deploy ransomware right away; they first covered their tracks and expanded their foothold. Malware deployment and ransom demands came weeks or months later.

How Can Organizations Keep Systems Safe?

• Prevent: Implement audit logging, and forward logs to immutable storage.
• Limit the Blast Radius: Ensure that no one can disable security monitoring, not even for testing purposes.
• Detect: Alert on log-retention policy changes and treat them as high-priority security incidents.
• Respond: Implement automation that can quickly revoke access for a compromised identity across all systems.

What Are Best Practices for Reducing Identity Breaches?

Follow this checklist to cut your identity risk:

• Start by Gaining Visibility: You can’t protect what you don’t see, so inventory your identity sprawl and identify password-only external access.
• Review Admin Privileges: Determine who has admin rights, and analyze if they actually need all those permissions.
• Test How Fast You Respond to Issues: Identify how much time it takes to revoke all access for a specific identity. Use this test result as a baseline for improvement.
• Deploy Phishing-Resistant MFA: Phishing-resistant MFA needs to be implemented everywhere, as attackers often compromise lower-priority systems first and then move laterally.
• Eliminate Exposed Credentials and Leaked Secrets: Scan your code repositories, wikis, and shared documents for exposed credentials. Implement automated scanning in your CI/CD pipelines to prevent secret leaks.
• Protect Audit Logs: Audit logs should be stored in immutable storage to ensure they cannot be altered after creation.
• Create Alerts: Alert on role changes, app consents, unusual MFA behavior, and federation changes.
• Implement JIT Elevation: You don’t need persistent admin permissions. Administrative access should be granted on demand for a specific time period.

Conclusion

Identity breaches are the easiest way in for attackers, and they usually follow a predictable pattern.

To disrupt this pattern, shifting left with stronger prevention is a start, but it’s not enough. You’ll also need to build powerful detection capabilities and automate quick responses to threats. Your motto should be, “Make it harder to get in, harder to escalate, harder to persist, easier to detect, and faster to contain.”

At Linx Security, we help organizations build robust identity security that addresses each stage of the attack chain. Book a demo with one of our engineers to learn more about how we can keep your systems safe from identity breaches.

TL;DR

Any identity-related question you ask once, might be worth asking again. What contractors have admin access to company apps? How many AI agents are currently in use? How many partially offboarded users do we have? AI-scheduled reports let you turn any question into a recurring report that runs on your schedule.

The Linx AI Agent

The Linx AI Agent sits on top of your connected identity graph (users, non-human identities, entitlements, resources, and the relationships between them) and uses reasoning to help you find insights and take action. You use it by asking plain-English questions (for example, who has admin access in a given system, or where risky access is coming from), and it returns answers plus context-based recommendations for common workflows like access requests, user access reviews, access profiles, and custom reporting. Where you’ve granted permission, it can also trigger the next step, like kicking off remediation options or executing an approved action, so investigations and cleanups don’t die in tickets and spreadsheets.

AI-scheduled reports

Using the Linx AI agent, you can turn any question into a recurring scheduled report.  For example, one customer recognized a pattern of questions he always gets on a weekly meeting, so he automated the answers for those into reports that land in his inbox every week before the meeting. 

To set up a scheduled report, start by asking a question:

You can keep investigating until you get the data you want, once you do, tell the agent to turn it into a scheduled report:

And that’s it! You’re also able to configure the report to add additional recipients, change the frequency, or manually run the report now. Once you set it up, the report will show up on the configured inboxes on the schedule you set:

Example use cases

Any question that can be answered with data neatly arranged in a table can be turned into a report. Here are some of the most common questions we see our customers use:

1. “List dormant admin accounts” - The AI Agent will find accounts with elevated privileges that haven't been used recently, as these could potentially present a security risk. Customers often run a recurring check for these accounts.
2. “Detect partially offboarded users” - A partially offboarded user is someone whose lifecycle status indicates they should be fully deactivated, but they still have active accounts in some applications. This represents an incomplete offboarding process and poses a security risk. Large companies tend to have more churn, so identity teams regularly run this check to reduce their attack surface as part of their identity lifecycle management process.
3. “List all orphaned accounts” - This reveals accounts that exist in your applications but have no corresponding identity in your authoritative identity sources (HR systems or Identity Providers like Okta/Azure AD). These "orphaned" accounts often result from incomplete offboarding processes, manual account creation, or integration gaps. Orphaned accounts are a significant security risk because they exist outside your normal identity governance processes and are unmonitored, unmanaged, and often forgotten.
4. “List all AI agents with their permissions and resource access” - With AI agents on the rise, we’re seeing identity teams prioritizing visibility and governance over them. This report provides a complete inventory of all AI agents in your environment, showing their names, associated applications, tools and permissions they have access to. As AI agents are autonomous software entities that can interact with critical systems and data, they represent a growing security and governance challenge. 

Get Started

Linx customers typically get valuable insights on day one. To learn more about how Linx can work for you, book a demo with one of our specialists. 

Most organizations still deal with a lot of standing access. A user gets elevated access and we forget to revoke it, or someone switches roles and keeps their access from the old one. Our attack surface grows with each standing permission. Just-in-time access flips that default. You grant only what is needed, exactly when it is needed, and you remove it as soon as the work ends.

In this article I hope to give identity and security teams a practical path to make JIT access the standard operating model. We define JIT, show how it fits with RBAC and ABAC, explain where it works best, explore how agents change the picture, and outline how to build, roll out, and measure a program that improves both productivity and security.

What is JIT (Just-In-Time)?

Just-in-time access issues time-bound and scope-bound permissions on demand, then revokes them automatically. Think of it as least privilege with a clock and a clear scope. Unlike a standard access request, expiry is part of the grant. No one needs to remember to remove anything later.

JIT began as an emergency scenario, like when an admin needs elevated access quickly to resolve an urgent issue. Modern identity platforms and cloud controls now support it across a much wider set of tasks. JIT can be the default for any permission you do not use daily, including sensitive SaaS roles, database privileges, cloud consoles, CI pipelines, and internal admin functions.

How JIT Works With RBAC and ABAC

Role Based Access Control assigns access based on membership in a role. You define a role once and map it to entitlements. For example, everyone with the Marketing role gets HubSpot and Canva.

Attribute Based Access Control grants access when a policy evaluates to true across attributes of the user, resource, action, and environment. The policy defines who qualifies, not a static group. For example, grant HubSpot and Canva to users whose role is Marketing, employment type is FTE, location is US, and manager is John Smith.

Just in time adds duration and task. Keep the baseline role small. Use ABAC to narrow eligibility and conditions. When a task requires elevation, issue a short-lived entitlement tied to a specific action and resource. ABAC decides who qualifies under current conditions, and JIT limits how long and how broadly the grant applies. You can also use ABAC to block requests outright if the requester does not meet basic requirements like MFA or compliant device.

When is it Time for Just-In-Time?

JIT fits two patterns. The first is routine elevation on a predictable cadence. Consider quarter-close finance tasks, maintenance windows, or periodic schema changes. The second is ad hoc work where someone needs temporary rights to unblock an incident or enable a deployment.

Ownership matters in both cases. Requestors should not need to be security experts. Application and entitlement owners define what can be JIT-granted, under which conditions, and for how long. Security teams codify guardrails and step in for high-risk changes or separation of duties checks. Approvals start with the owner who understands the operation, with security engaged when risk or policy requires it.

A simple example illustrates the idea. A product manager occasionally needs admin rights in a support tool to add a contractor. Today that person might keep admin forever because it is convenient. With JIT, they request a task-scoped admin profile that expires in X minutes. The system records who, what, why, and for how long access was granted. The job gets done, and the background risk stays low.

Agents And Non-Human Identities

AI agents are now autonomous actors inside the enterprise. They make decisions, access systems, and execute tasks with little human oversight. That makes them identities in their own right, not just wrappers around service accounts or API keys. Treat them as first-class identities with owners, clear purposes, and explicit scopes.

Most teams cannot answer three basic questions today. Which agents are running in our environment. What systems can they access? What permissions do they actually hold? This visibility gap is the core risk as adoption accelerates.

Agents behave differently from traditional NHIs. A service account follows fixed logic. An agent interprets context, adapts, and tries alternate paths until it completes the task. It operates at high speed and at scale. If it inherits broad standing rights, the blast radius grows quickly.

The model that works looks a lot like how you govern people, with tighter controls and shorter windows. Start with an agent registry. Record owner, purpose, allowed tasks, baseline scopes, and last activity. Link each agent to the machine credentials it may use and to the data it can touch. Represent these relationships in your identity graph so every request is evaluated in context.

Just-in-time access is essential for agents. Give the agent only the permission it needs for the specific task and for a short period. Do not let it reuse a human sponsor’s standing rights. When the timer expires, revoke tokens, sessions, and keys.

Round out the guardrails with a small set of practices that scale:

• Identity profiles that define purpose, baseline permissions, and ownership
• Human-in-the-loop approval for any elevation beyond the baseline
• Continuous monitoring for unused rights, anomalous behavior, or scope creep
• Automated identity risk remediation that revokes excess, suspends risky agents, and notifies owners

This approach keeps autonomy without losing control. You gain clear accountability, smaller blast radius, and audit-ready records for every decision. Most important, you align agent productivity with least privilege by default, not as an afterthought.

A JIT Architecture That Scales

JIT thrives when four layers work together and feed one another.

1) Visibility

Start with an accurate catalog of identities, entitlements, applications, resources, and owners. Include people, service accounts, workload identities, and agents. Map who can grant what. Assign ownership for every entitlement and admin function. Integrate data from your IGA, directories, cloud accounts, SaaS admins, and data platforms. Without this map you cannot know what you are granting or who should approve it.

2) Policy And Decision

Define who can request what, under which conditions, and for how long. Use ABAC to enforce basic security requirements. Link higher risk actions to change records. Tier approvals by risk (what gets auto-approved vs. what needs human review). 

3) Intelligence

Add context to each request. Does the request align with the requester's job title and team? Do other team members have this access? Does the user have a history of violations? Present recommendations that reduce cognitive load for approvers. The goal is not to replace judgment. It is to give the resource owner structured context so they can decide quickly and confidently.

4) Fulfillment And Audit

Provision at the smallest practical unit. Prefer ephemeral roles, short-lived tokens, and session policies rather than group adds. Revoke everything when the timer expires, including sessions and keys. Write a durable audit trail that captures requestor, approver, reason, scope, and duration. Index every grant so user access reviews become faster and more meaningful.

Rolling Out JIT

Start where the impact is highest. Choose a sensitive SaaS app and a production cloud account. Inventory admin actions, define owners, and mark which actions are JIT-eligible. Set short default durations and clear approval paths. Run a small pilot with people who understand the tasks and can provide actionable feedback.

Limit the audience at first. You can hide the JIT entry point from general users until owners and security are comfortable with the flow. As confidence grows, expand who can request JIT and add more actions and teams.

Make audit an explicit outcome. Every JIT grant should produce an easy to read record for compliance. This reduces manual effort during periodic reviews and gives auditors clear evidence of least privilege.

Guardrails For Agents

Agents need the same rigor as people, plus a few extras. Maintain a registry of agents with owner, purpose, allowed tasks, and data sensitivity. Use short-lived credentials with narrow scope. Avoid reusable keys and prefer brokered, time-bound tokens. Require human initiation for scope changes. Agents may request within their allow list but cannot extend it on their own. Build a kill switch that revokes all agent tokens at once. Connect it to anomaly detection so you can respond quickly without guesswork.

Measuring JIT Success

A focused set of metrics shows progress. Track the percent reduction in standing high-risk entitlements. Measure mean time to elevation and approval success rate. Watch median JIT session length and the share that end by auto revoke. Monitor reviewer load during access reviews and incidents linked to stale permissions.

The target state is clear. Elevation for legitimate work is fast. Background risk trends down. If both lines move in the right direction, your model is working.

Common Failure Modes And Fixes

Approval fatigue is the most common failure. Owners and security get overwhelmed by noisy requests. Reduce volume with clear task packs and strong defaults. Use recommendations so owners see a simple approve or deny with the right context.

Temporary group adds are another trap. Groups linger and create blind spots. Prefer ephemeral roles or policy attachments that expire automatically. When groups are unavoidable, require an expiry and verify revocation after the window closes.

Agent inheritance is a quiet risk. Do not let agents reuse human standing rights. Bind them to their own service principals and JIT policies.

How Linx Implements JIT

Linx treats identity as a security problem first. The platform builds a graph that unifies people, non-human identities, and agents across SaaS and cloud. Every request consults this graph in real time. Risk signals and peer comparisons help owners decide quickly. Policies blend RBAC, ABAC, task context, and separation of duties.

Provisioning is granular. The system attaches the smallest scope required for the task, issues short-lived credentials, and tears them down on expiry. The same flow works for human users, workload identities, and agents. Approvals start with the resource owner and escalate by risk, which keeps security focused on the reviews that matter most. Every action writes a complete audit trail so access reviews and certifications become faster and more accurate.

Customers tell us the difference is the security-first lens. The goal is not only faster approvals or cleaner audits. The goal is safe productivity. JIT captures that goal by cutting background risk while keeping teams moving.

Bringing It Together

Standing access is quiet exposure that grows over time. Just-in-time and just-enough access, paired with dynamic access profiles is how you ensure that exposure stays at a minimum. You grant only what is needed, when it is needed, and you remove it on time.

Most identity teams have done the responsible work. You set up an IdP for SSO, enforced MFA, rolled out IGA, and protected admin paths with PAM. Yet privilege-creep lingers, offboarding is inconsistent in the details, and blind spots show up across SaaS, cloud, on-premise, and internal systems. That outcome is not a bad strategy or a failure to follow best practices. It is the natural result of growth and complexity. People move roles, apps multiply, automation creates new access edges, and non-human identities are on the rise. Meeting that reality calls for a new way to understand and act on identity.

That is the point of an Identity Visibility and Intelligence Platform (IVIP). An IVIP is a single place that unifies identity data, models how permissions actually relate to resources, and presents decisions you can carry out in the flow of work. It does not discard what you already have. It helps you run it better. In some organizations it also starts to absorb work that once lived in a legacy IGA suite. The goal is simple - make identity management easier and safer for admins, security teams, and end users.

The challenge with today’s stack

Identity programs grew up in a world of clearly bounded systems. Today the edges are fuzzier. A single user can participate in or hold a mix of IdP groups, application roles, inherited permissions, and temporary tokens. A single workload can carry keys and service principals that unlock powerful APIs. None of these are bad on their own. The problem is that the important questions are relational. Who can do what on which resource. What breaks if we remove this group? Which rights are unused and could be reduced?

Tabular inventories struggle with relational questions. They are good at counting, not at explaining. When decisions depend on how objects connect, you need a model that treats connections as first class citizens. That’s the gap I see IVIP stepping into.

Model relationships, not rows

Identity is a network of relationships. Human to account. Account to group. Group to role. Role to permission. Permission to resource. Owner to business unit. A platform that understands these links can answer the questions that matter and can do it in near real time. That is why a graph model is the right foundation. It makes it cheap to ask hard questions and safe to automate the obvious ones.

Here is a scenario that plays out every week: A senior engineer moves into a product role. HR updates the employee record. Some IdP groups change. On the surface, access looks correct. Yet a handful of admin privileges remain through inherited groups and application-local roles. The person no longer needs elevation but still holds write or admin rights in systems that touch production. A graph reveals the full path that keeps those rights alive. An IVIP should tie the HR event to identity edges, highlight the drift, show the exact inheritance that matters, and propose a safe remediation plan. You remove the unneeded entitlements, convert any remaining elevation to just-in-time, and keep the evidence for audit. No spreadsheets. No guesswork. No surprises six months later.

Intelligence that gets work done

Dashboards summarize. Intelligence drives change. Useful identity intelligence has three traits. It is explainable, precise, and actionable.

Explainable means you can see the path that produced the score or the alert. Breadth of access matters, but so do signals like inactivity, weak factors, external ownership, or exposure to sensitive resources. If you can explain and understand the calculation, you can defend the decision.

Precise means the recommendation is specific. Remove entitlement A and group B. Usage has been zero for 90 days. Peers in the new role do not hold either. Residual rights still allow task C. That is a decision a manager or owner can approve quickly.

Actionable means you close the loop in the same place you saw the issue. Revoke or reduce with one action. Time-bound a role and move on. Route a minimal approval to the true owner with context attached. The cost of doing the right thing needs to be low. 

Coverage that matches how people and systems actually work

Coverage is not a list of connectors. It is a promise that the model reflects reality. That means human and non-human identities with clear ownership. SaaS, cloud, and on-prem applications with resource-level permissions, not just role names. Accounts inside and outside SSO, including application-local identities that bypass centralized controls. Peer and behavioral context so least privilege can be achieved with confidence. Segregation of duties checks that cross systems rather than living inside a single suite.

If one of these dimensions is missing, you introduce governance gaps or create an audit headache. An IVIP should bring them together so you can reason across them without stitching exports by hand.

What impact should an IVIP have?

Teams that adopt an IVIP, or a set of features that amount to the IVIP promise, should feel the impact in their first quarter. The first change is clarity. Dormant accounts, unused admin roles, overprivileged accounts, and other risks surface with owners attached and suggested fixes ready to go. The second change is decision quality. Right-sizing stops being personal and becomes a repeatable pattern. The platform shows the path, explains the risk, and proposes the minimal safe change. Approvals get shorter because the context is built in. The third change is operational momentum. Mean time to remediate identity risk becomes a real metric. Access becomes both safer and faster because defaults are designed to unblock work without widening blast radius.

There is also a cultural effect. Security and IT work from a single source of truth. Less time is spent reconciling spreadsheets. More time is spent making clear reductions that everyone understands.

A pragmatic way to start

Start by unifying what you already own. Ingest IdP, HRIS, IGA, PAM, the major SaaS applications, cloud providers, and the internal systems that carry the most risk. Normalize identities and connect both human and non-human principals to owners and resources. Then turn on opinionated detections. Focus on partially offboarded users, inherited admin rights, application-local accounts, orphaned service identities, risky factors, unused entitlements, and cross-system SoD. Require each finding to ship with owner, impact, and a proposed remediation.

From there, move to continuous right-sizing. Use usage data and peer baselines to convert standing privilege into least privilege. Prefer time-bound or approval-bound elevation over permanent admin. Simple policies go a long way. For example, remove any entitlement unused for a set number of days unless the owner opts out with a reason.

Close the loop with one-click actions and lightweight approvals. Record evidence automatically. Measure what matters: privileged account count, accounts outside SSO, time to remove unused admin access, percentage of time-bound elevation, and the number of automated right-sizing actions. These measures tie identity work to risk reduction and business velocity.

Use AI as an accelerator with guardrails. Summarize context, propose candidate roles, and prioritize onboarding. Keep data scoped to the task, respect privacy, and admit uncertainty rather than guessing. AI should help you move faster on correct work, not cover up missing data.

Where this leaves IGA

IGA remains useful for identity lifecycle management, certifications, and policy. IVIP complements that mission by providing full-fidelity visibility, trustworthy analytics, and closed-loop execution. In some environments IVIP will take over most decisioning and remediation while IGA handles specific compliance workflows. In others, teams choose to consolidate further. The point is not to keep every tool. The point is to meet today’s complexity with a model and workflow that can keep up.

The bottom line

You do not need to master every application’s permission model. You need a platform that understands them, unifies them, and gives you the fastest safe decision for each situation. That requires a relationship-aware model, explainable analytics, disciplined use of AI, and an operational loop that ends in a real change. Build IVIP on those principles and you will find issues sooner, fix them faster, and keep people moving without widening risk. That is what good identity looks like at modern scale.

The holiday season brings unique challenges for enterprises. While employees take time off, cybercriminals ramp up their efforts, targeting organizations during periods of reduced staffing and increased operational flexibility. For identity and access management (IAM) teams, this period requires heightened vigilance.

At Linx Security, we’ve observed that holiday periods often lead to an uptick in security incidents linked to access mismanagement. From rushed access approvals to inactive accounts being exploited, the risks are significant—but they can be mitigated with the right strategies. Here’s how enterprises can stay secure while embracing the holiday spirit.

1. Increased Third-Party Access During the Holidays

The Risk:

During the holiday season, many enterprises rely on contractors, temporary staff, or third-party vendors to maintain operations. These third parties often require access to critical systems, yet their onboarding and offboarding processes are frequently rushed or incomplete.

A Ponemon Institute study revealed that 59% of organizations experienced a data breach due to third-party access mismanagement. Implementing stricter controls during high-risk periods like the holidays is essential.

Actionable Strategy:

• Automate Onboarding and Offboarding: Use IAM tools to streamline and enforce consistent processes for third-party access.
• Set Temporary Access Windows: Limit access duration to the holiday period, ensuring credentials expire automatically.
• Monitor Third-Party Behavior: Continuously track and analyze activity from third-party accounts to detect anomalies.

2. Reduced Staffing and Security Oversight

The Risk:

Reduced staffing during holidays often leads to delayed threat detection and response times. Attackers exploit these gaps, knowing incident response teams are operating with skeleton crews.

According to Cybersecurity Dive, security incidents spike by 30% during major holidays. Having automated systems in place ensures you’re not reliant solely on human intervention.

Actionable Strategy:

• Implement ITDR Solutions: Identity Threat Detection and Response (ITDR) tools can automate threat detection and take preemptive actions, such as locking compromised accounts.
• Set Up Holiday-Specific Policies: Configure your IAM platform to enforce stricter authentication requirements during off-hours.
• Leverage AI for Continuous Monitoring: Use AI-driven tools to identify unusual access patterns, such as logins from new geolocations or at odd hours.

3. Temporary Role Changes and Privilege Escalations

The Risk:

Holiday schedules often lead to role changes, such as managers temporarily delegating access rights to team members. This increases the risk of privilege creep and misuse.

In a 2023 report, Forrester emphasized the importance of JIT access as a zero-trust best practice, particularly during periods of organizational disruption.

Actionable Strategy:

• Enforce Just-in-Time (JIT) Access: Use JIT provisioning to grant temporary elevated privileges that automatically revoke after a set period.
• Audit Privilege Escalations: Regularly review changes to access permissions during the holiday season.
• Use Adaptive MFA: Add extra layers of security for accounts with newly escalated privileges.

4. Stale and Inactive Accounts

The Risk:

Inactive accounts, such as those of employees on extended holiday leave, are prime targets for attackers. These accounts often go unnoticed during routine security checks.

Gartner estimates that 30% of breaches are linked to inactive or orphaned accounts. Proactively addressing these risks during the holidays can prevent exploitation.

Actionable Strategy:

• Suspend Unused Accounts: Temporarily disable accounts for employees on extended leave.
• Automate Dormant Account Detection: Use your IAM platform to flag accounts that haven’t been used within a set time frame.
• Audit Orphaned Accounts: Ensure no accounts are tied to departed employees or contractors.

5. Increased Remote Work Risks

The Risk:

Many employees work remotely during the holidays, often from unsecured personal devices or public networks. This creates vulnerabilities, particularly when accessing sensitive systems.

A 2024 report by CSO Online found that 75% of organizations experienced a surge in remote work-related security incidents during the holidays. Strengthening remote access policies is a critical defense.

Actionable Strategy:

• Enforce Device Trust Policies: Require that only pre-approved and compliant devices can access enterprise systems.
• Deploy Adaptive Access Controls: Use geolocation, device type, and behavioral patterns to adjust authentication requirements dynamically.
• Educate Employees: Run holiday-specific security awareness campaigns, reminding staff about secure access practices.

6. Phishing Campaigns Targeting Holiday Chaos

The Risk:

Cybercriminals exploit the holiday rush with targeted phishing campaigns. Emails disguised as holiday deals, time-sensitive HR notices, or even fake holiday greetings can trick employees into revealing credentials.

The Anti-Phishing Working Group (APWG) reported a 38% increase in phishing attacks during the 2023 holiday season. Proactive training and strong IAM measures can mitigate these risks.

Actionable Strategy:

• Implement Email Filtering: Use advanced email security tools to block suspicious messages before they reach employees.
• Enforce MFA Across All Accounts: Ensure compromised credentials cannot be used without secondary authentication.
• Conduct Simulated Phishing Tests: Run holiday-themed phishing tests to raise awareness among employees.

7. Ensuring Business Continuity

The Risk:

While securing systems is a top priority, excessive restrictions can hinder productivity and disrupt holiday operations.

Balancing security with usability ensures operations continue smoothly while maintaining robust defenses.

Actionable Strategy:

• Implement Role-Based Access Controls (RBAC): Ensure employees only have access to the tools they need, reducing unnecessary friction.
• Create a Holiday Access Playbook: Define clear protocols for granting, revoking, and monitoring access during the holiday season.
• Monitor in Real Time: Use IAM platforms with real-time dashboards to track access activities without delays.
  

Conclusion: Staying Secure Without Sacrificing Holiday Spirit

The holiday season doesn’t have to be a time of heightened risk for enterprises. With proactive planning, robust IAM practices, and the right tools, organizations can navigate this challenging period securely. At Linx Security, we specialize in helping enterprises implement adaptive, scalable IAM and Modern IGA solutions that minimize risks and enhance operational resilience.

As the holidays approach, now is the time to evaluate your IAM strategy. Are your systems prepared for the unique challenges of this season?

Stay ahead of holiday access risks with Linx Security. Contact us or explore how our IAM solutions can safeguard your enterprise during the busiest time of the year.

Offboarding employees has always been a crucial process in maintaining a secure environment, but as organizations grow, the complexity of managing user access increases significantly. One of the biggest yet often overlooked vulnerabilities occurs when users are only partially offboarded. This scenario happens when employees leave the company, but some of their access to cloud applications, internal tools, or shared resources remains intact. 

The risks posed by this oversight are numerous, spanning both security and governance:

Security Risks

1. Unauthorized Access: Partially offboarded users may retain access to sensitive data or systems, either unintentionally or through deliberate misuse. If their credentials remain active, these former employees can still access critical applications like email, file storage, or CRM systems.
   
2. Insider Threats: In some cases, employees who have left on negative terms could use their still-active accounts to leak data or disrupt operations. Even in cases where the departure was amicable, having unmonitored, lingering access opens doors to potential misuse.
   
3. Compromised Credentials: Former employees may become an easy target for attackers. If a hacker compromises their inactive but still valid credentials, they gain entry to the organization's systems undetected, as the user may no longer be closely monitored.
   
4. Audit and Compliance Failures: Regulatory frameworks like GDPR, HIPAA, and PCI DSS require organizations to demonstrate control over user access to sensitive data. Partially offboarded users represent a significant non-compliance issue that can lead to audits, fines, or legal penalties.

Governance Risks

1. Lack of Visibility: When offboarding isn't fully automated or governed by a centralized identity management solution, it becomes difficult for IT or security teams to have a clear view of which users still retain access to which systems. Shadow IT often arises, leaving unmanaged access risks.
   
2. Policy Enforcement Failures: Identity governance frameworks require a consistent application of policies across user identities. In the case of partially offboarded users, those policies are often bypassed due to poor oversight, leading to a lack of proper controls around access and data security.
   
3. SaaS Sprawl: Cloud environments are highly dynamic, and as more SaaS applications are introduced, the chances of users retaining access to unmonitored resources increase. Without clear governance, users with orphaned accounts across applications represent a significant security gap.

How Linx Security Solves This Problem

At Linx Security, we understand the challenge of managing user access throughout an employee’s lifecycle, especially when it comes to the offboarding process. Here’s how we help organizations mitigate the risks associated with partially offboarded users:

1. Comprehensive Identity Lifecycle Management: Linx Security ensures that user identities are centrally managed from onboarding to offboarding. Our solution automates deprovisioning processes across all integrated applications, ensuring that no lingering access is left behind.
   
2. Real-Time Access Visibility: We provide security teams with real-time dashboards that offer complete visibility into every user’s access across cloud applications, infrastructure, and shared resources. This allows for immediate detection and remediation of orphaned accounts or partially deprovisioned users.
   
3. Automated Policy Enforcement: With Linx Security, organizations can enforce access policies consistently across their entire ecosystem, ensuring that when an employee leaves, all their permissions and credentials are immediately revoked. This aligns with governance and compliance requirements to prevent unauthorized access.
   
4. Risk-Based Access Reviews: To further strengthen governance, Linx Security enables periodic, risk-based access reviews. This ensures that even accounts that might have been missed during the initial offboarding are caught and deactivated before they become a threat.
   
5. Audit-Ready Compliance Reporting: Our platform generates audit-ready reports that demonstrate your organization’s ability to control and govern user access, helping you stay compliant with industry standards and regulations like PCI DSS, SOX, and HIPAA.

Conclusion

Partially offboarded users present a serious threat to security and governance, but with the right tools in place, organizations can effectively mitigate these risks. Linx Security’s comprehensive identity and access management solution ensures that no user is left with unintended access to sensitive systems and data. By automating offboarding and enforcing strict governance, we help you protect your organization from the hidden dangers of incomplete de-provisioning.

In today’s evolving business landscape, companies are increasingly reliant on a workforce that extends beyond traditional, full-time employees. Temporary workers, contractors, partners, and even vendors now play critical roles within organizations. This trend towards a hybrid workforce brings additional flexibility but also challenges, particularly in managing and governing the access of these non-employees. According to Gartner, 45% of security breaches involve non-employee users, underscoring the need for greater visibility and oversight in managing their access.

What makes access for non-employees so challenging?

1. Complex and diverse access needs - Unlike employees, non-employees often have unique and variable access needs. Contractors may require temporary access to specific systems, while vendors may need ongoing access to certain resources, albeit with fluctuating levels of permission. Governing this diverse set of access requirements can be complex, especially when access requests frequently change over time.
   
2. Limited visibility and oversight - Non-employees often exist outside of standard HR processes and systems, making it difficult to track their access lifecycle—onboarding, access management, and offboarding. Limited visibility into who has access to what increases the risk of unauthorized access, especially if permissions aren’t terminated promptly. 
   
3. Increased security risks - Since non-employees are often not fully integrated into the organization’s culture or familiar with its security practices, they could inadvertently compromise sensitive information and neglect the security processes implmented in the organization. According to Forrester, 63% of breaches are due to compromised access credentials, including those of contractors and other third-party users. 
   
4. Regulatory compliance challenges - Governing non-employee access is crucial not only for maintaining security but also for meeting regulatory requirements. Regulations like GDPR, HIPAA, and SOX mandate stringent controls over access to sensitive data. Without a structured process for managing non-employee access, organizations risk failing audits and incurring fines.
   
5. Operational inefficiencies - Manual access management processes can be time-consuming and error-prone. For organizations that rely heavily on non-employees, the administrative burden can become overwhelming, leading to delays in granting necessary access or, worse, lingering access for users who no longer need it. According to the Identity Management Institute, 51% of organizations experience operational inefficiencies due to fragmented and manual access management processes for non-employees, further stressing the need for identity governance automation.

The key to solving for non-employee access

To effectively govern non-employee access, organizations need a modern approach that goes beyond traditional access management capabilities and provides the following essential capabilities:

1. Discovery and management for non-employees - It’s crucial to keep non-employee accounts accurate and up-to-date. Without regular oversight, entitlement creep or orphaned accounts can occur—non-employees may accumulate unnecessary access over time, or accounts may remain active even after a contract ends. Having your solution serve as a dedicated repository for non-employee identities allows easy input and monitoring of relevant details while enforcing the necessary controls for close management. 
   
2. Follow the principle of least privilege - No employee or non-employee should have more access than needed to get their job done. This is best achieved through role-based access, which provides permissions based on roles instead of individual entitlements.  Roles can easily be applied to well-managed non-employees as well as employees.
   
3. Comprehensive identity lifecycle management - Manual provisioning can be labor intensive and take weeks before new employees have the access they need. This can lead to a frustrating experience for both the employee and non-employee and will cost the organization time and money. However, sloppy onboarding for the sake of speed can lead to security risks. While off boarding does not seem as time sensitive since no one is waiting on access, it is even more important from a security perspective.
   Your solution should facilitate end-to-end access lifecycle management for non-employees, including automated onboarding, real-time access provisioning and de-provisioning, and tracking access over time. By automating these processes, organizations can ensure that access is consistently managed and immediately terminated when it is no longer needed.
   
4. Automated access reviews and certifications - Periodic access reviews and certifications are critical for ensuring that non-employees only have access to the resources they need. Your solution should provide automated access review workflows that facilitate timely review and re-certification processes. This reduces the administrative burden on IT teams while ensuring compliance with security policies.

Conclusion

Effectively governing non-employee access requires a modern solution. As the workforce continues to evolve, organizations must prioritize non-employee access governance to maintain security, meet compliance requirements, and reduce operational inefficiencies. By investing in a solution that meets these needs, organizations can not only manage non-employee access effectively but also enable a more agile, secure, and compliant digital environment.

Ready to manage non-employee access?

Contact us today to learn how we can help.

Software as a Service (SaaS) applications have become essential in the modern business landscape, offering incredible flexibility, rapid deployment, and scalability. They allow teams to work more efficiently, improve productivity, and access the best tools the market has to offer. However, with great convenience comes significant security challenges—specifically, the rise of "SaaS sprawl."

SaaS sprawl occurs when departments and employees adopt SaaS applications independently, often without IT oversight or a clear strategy. This unchecked growth creates a tangled web of overlapping tools, unmanaged permissions, and a larger attack surface. When SaaS apps proliferate without a centralized strategy, organizations face mounting security, compliance, and financial risks.

The solution? Effective identity and access management (IAM). By focusing on identity-first strategies, organizations can control SaaS growth, manage permissions, and enhance security—ensuring that SaaS remains an asset rather than a liability. In this article, we’ll explore what drives SaaS sprawl, its potential risks, and how identity management can help tame this growing challenge.

Understanding SaaS Sprawl and Its Identity Implications

What is SaaS Sprawl?‍

SaaS sprawl refers to the uncontrolled adoption of cloud-based applications within an organization without proper management or oversight. Often, this happens when departments or individual employees independently subscribe to SaaS tools without consulting IT or obtaining centralized approval. This fragmented approach leads to multiple tools performing similar functions, increased spending, and a lack of visibility into who has access to what.

Identity’s Role in SaaS Sprawl

‍When SaaS sprawl occurs, the identity component becomes fragmented as well. Each SaaS application typically comes with its own set of users, access controls, and permissions. Without central oversight, managing who has access to which apps—and more importantly, managing privileges—becomes a daunting task. This ultimately results in "permission sprawl," where users accumulate more permissions than necessary, creating vulnerabilities that attackers could exploit.

What Drives SaaS Sprawl?

1. Lack of Centralized Procurement and Identity Governance
   The absence of a unified procurement process and identity management system is a key driver of SaaS sprawl. When IT lacks visibility, employees and teams can freely acquire tools that suit their immediate needs without considering the broader security and compliance implications. This not only results in redundant applications but also makes managing identities across these tools highly challenging.
   
2. Complex Access Controls Across SaaS Apps
   Access control is a fundamental aspect of security, but when it comes to SaaS, each application often has its own complex system of permissions, roles, and access rules. Without consistent identity governance, managing these disparate systems becomes nearly impossible, leading to overlapping permissions and unrevoked access—especially when employees change roles or leave the organization.
   
3. Easy Availability of SaaS Applications
   The vast array of SaaS applications available makes it easy for employees to find solutions that address their specific needs. Unfortunately, this often leads to duplicate tools being used across departments, each with its own access and identity parameters, which contributes to identity-related risks and inefficiencies.
   
4. Insufficient Employee Training
   Without proper training on security best practices, employees are more likely to adopt unauthorized SaaS applications. They may be unaware of the risks associated with using these tools, such as inadvertently exposing sensitive company data or failing to manage permissions properly.
   
5. Onerous Procurement Processes
   Complex procurement processes can deter employees from following official procedures. Acquiring a new tool requires multiple layers of approval, so employees may instead opt for a "quick fix" by signing up for a SaaS solution independently, bypassing identity governance altogether. This makes tracking and managing access a much more difficult endeavor for IT teams.

The Impact of Unchecked SaaS Growth

1. Expanding Attack Surface and Increased Security Risks
   As the number of SaaS applications grows, so does the potential attack surface. Each SaaS tool represents a potential entry point for attackers, especially when there is no unified system to manage access and permissions. The more fragmented the environment, the more difficult it becomes to identify and mitigate risks.
   
2. Privilege Sprawl and Identity Challenges
   When employees are granted excessive permissions across multiple applications, it results in privilege sprawl. This occurs when users accumulate more access rights than they need—often due to a lack of revocation processes or decentralized app adoption. Excessive privileges are a significant security concern, as they can be exploited to gain unauthorized access to sensitive systems and data.
   
3. Financial Waste and Operational Inefficiencies
   Duplicate or unnecessary SaaS tools result in wasted financial resources, while fragmented SaaS adoption leads to inefficiencies in managing those applications. Departments that use different tools for similar tasks may struggle with interoperability, reducing productivity and complicating IT oversight.
   
4. Compliance and Regulatory Challenges
   Regulatory compliance requires strict control over who has access to sensitive data. With SaaS sprawl, data is spread across multiple applications, making compliance auditing difficult and time-consuming. Managing identities and permissions effectively is critical for meeting standards like SOC 2, GDPR or HIPAA.

How Identity Management Can Help Control SaaS Sprawl

1. Conduct Regular SaaS Audits with a Focus on Identity
   Conducting regular SaaS audits helps IT teams identify which applications are in use, who has access, and whether those applications align with organizational needs. Audits that focus on identity ensure that permissions are appropriate, outdated accounts are deprovisioned, and redundant apps are eliminated, helping reduce the risk of unauthorized access.
   
2. Implement Centralized Identity and Access Management (IAM)
   Implementing a centralized IAM system is key to controlling SaaS sprawl. With IAM, organizations can manage identities across multiple SaaS applications from a single platform, ensuring that access permissions are consistent, monitored, and controlled. IAM also provides visibility into user activities and can enforce the principle of least privilege, reducing the risk of excessive permissions.
   
3. Simplify SaaS Procurement with Integrated Identity Control
   By integrating identity management into the SaaS procurement process, companies can ensure that every new application is vetted and that access is managed from the outset. Streamlined procurement processes, where employees can easily request new tools through a central system, reduce the likelihood of shadow IT while ensuring IT maintains control over access and identity.
   
4. Train Employees on Identity and Access Security
   Regular training sessions can help employees understand the risks of using unauthorized SaaS applications, as well as the importance of following best practices for identity and access management. Employees should be made aware of the processes in place to obtain new SaaS tools and how to ensure those tools are used securely.
   
5. Establish Identity Governance Committees
   To prevent SaaS sprawl, organizations should establish identity governance committees that include representatives from IT, security, and different business units. These committees can evaluate SaaS needs, assess the impact on identity management, and ensure compliance with organizational policies. By coordinating efforts, organizations can avoid unnecessary duplication and ensure a consistent identity governance strategy.
   
6. Identity-Based Access Reviews and Permissions Cleanup
   Identity-based access reviews allow organizations to identify dormant or excessive permissions across their SaaS stack. With tools like identity access analytics, security teams can quickly visualize which identities have access to what and determine if those permissions align with current job roles. By continually cleaning up permissions, organizations reduce the risk of privilege sprawl and limit their exposure to security threats.

Conclusion: Taming SaaS Sprawl with an Identity-First Approach

SaaS has transformed the way organizations operate, bringing agility, scalability, and efficiency. However, without proper oversight, the uncontrolled adoption of SaaS apps can introduce significant risks—from privilege sprawl to non-compliance. An identity-first approach is the key to managing SaaS growth effectively, providing the visibility, control, and security needed to harness the benefits of SaaS while minimizing the risks.

By leveraging identity and access management tools, centralizing procurement, simplifying processes, and conducting regular audits, organizations can tame the SaaS beast—ensuring that each tool serves the company’s goals securely and efficiently.

Ready to regain control over your SaaS environment? Linx Security offers comprehensive identity and access management solutions that give you the visibility and control you need to manage your SaaS ecosystem effectively. Contact us today to learn how we can help secure your growing SaaS stack with confidence.

After a little over a year of relentlessly hard (and fun!) work alongside my co-founder, Niv Goldenberg, I’m excited to share that today Linx Security is emerging from stealth.

Already working with large-scale companies across a large variety of industries such as financial services, retail, real estate, technology companies and others, Linx is helping them dramatically shrink their identity attack surface and close major gaps in compliance—by enabling them to finally get control over their whole identity lifecycle.

Here is how we got to where we are today.

From physics to 8200 to identity security

Niv and I go back a long time. Twenty years back, in fact.

We first met while working together in the army’s cybersecurity unit (8200, the NSA equivalent). The sheer urgency and complexity of the projects we were tasked with played a critical role in molding our approach to problem-solving. And we found a mutual passion for tackling challenges head-on—especially, the types of challenges that others had already given up on.

Our shared passion continued through university, where we collaborated on physics and computer science projects. And it carried through to our professional roles—myself as the Director of Engineering at Checkpoint Security, and Niv as the VP of Product at Transmit Security. But we always knew that one day, we would tackle some of the world’s most complex issues together.

From our origins in physics to 20+ years in the cybersecurity space gave us dual abilities: one, the ability to ask the right questions (which is never as straightforward as it seems), and two, the ability to find the most practical way to resolve the problem—quickly. “Who should have access to what?” is such an easy question to ask, but so difficult to resolve. But as soon as this problem is solved, it would significantly relieve the pressure from enterprises where most of them have moved to having identity as their main perimeter. A complexity that we feel fortunate to have the opportunity at Linx to solve.

The evolution of identity security

Identity Authorization used to be simple. It was a closed system, on-prem, based on one source of truth—the Active Directory.

Meaning the biggest problem for companies was authentication and verification. Ensuring only authorized users had access to your systems, assets, and information.

But just as the law of conservation of momentum states, momentum is constant in an isolated system unless an external force is applied.

And that’s exactly what happened to identity. In a very short period of time, it had multiple, external forces thrown at it—which significantly increased its momentum, causing identity management and security to spin out of control.

First, it was the shift of infrastructure and applications to the cloud—beyond the control of on-prem solutions. Second, this shift to the cloud led to a rapid increase in the scale of human identities—we see this today, with one person owning multiple online aliases and login credentials. And third, the fast introduction of machine identities to organizations.

Further complicating matters, at large organizations, identity is fractured across three siloed teams: identity, security, and IT. Each team tackles identity from a different perspective, using their own tools for their specific responsibilities within the lifecycle. This fragmented approach creates a complex mess, filled with security and compliance risks – even with the wealth of existing solutions available.

And even though countless solutions existed for identity verification, authentication, and security, companies were still struggling to get identity under control.

We thought—why? Why does it have to be so hard? Why does it have to be so complicated?

That was the moment we knew we had found the challenge we wanted to solve.

So we rolled up our sleeves and got to work.

Uniting security, identity, and IT teams to get control over identity security

The result is what you see today: Linx, a refreshingly different identity security platform that is a significant departure from existing solutions.

Linx enables organizations to finally get the whole identity lifecycle under control with a radically modern approach that unites identity, security, and IT ops teams—by mapping the hidden relationships between employees, their digital identities, and the apps, software, platforms, and programs they have access to.

By providing the right tools, visibility, and understanding, along with deeply contextual insights and automated workflows, Linx allows these teams to work together efficiently and seamlessly to control and secure identity. Enabling organizations to ultimately shrink their identity attack surface and close gaps in compliance.

To our customers, we thank you for your ongoing support and trust. And to Index and Cyberstarts, and to our advisors—your guidance has been instrumental in making this product a reality.

To my co-founder, Niv, and the rest of our amazing team—I'm incredibly proud of what we've accomplished so far, and I can't wait to share even more details about our product and vision as the months unfold.

We are excited for what the future holds as we untangle the complexity of identity security. Once and for all.