Let's go back to 2008.
You're enterprise most likely had or a co-identity manager or CA identity manager or maybe a custom
IGA tool and you have spent 24 months implementing it.
You have connectors to active directory your SAP system and most likely your main frame and
your provisioning team is proud and honestly they should be.
And then someone somewhere in the company signs a contract with Salesforce.
Now you just identified that Salesforce has no connector with your IGA system or your IGA
system has no connector with Salesforce.
So no big deal custom integration is needed.
That would be 12 weeks of work statement of work likely from a system integrator and
a connector that works until Salesforce changes their API.
Then comes workday and then comes service now and then comes box and so on and so forth.
The IGA tools of that era were real.
They were powerful and they solved the problem for the systems they were built for.
IGA at that time was still mostly a compliance labor.
But SaaS didn't care about your connector framework.
Every new application was its own island.
Every integration was a one off and the number of SaaS applications in the average enterprise
was about to go from 10 to 100.
Now that gap between the on-premise word the old tools were built for and the SaaS word
that was arriving fast is what skim was born to close.
Welcome to the identity navigator.
I'm your host Rohit and today he go deep on skim.
But let's rewind to understand what the word looked like before skim existed because
we cannot appreciate a solution without first sitting in the pain of the problem.
So we go around the same timelines in the mid-2000s.
SaaS is exploding.
Salesforce has figured out that you don't need to install software to use software.
What a revolutionary thought.
Google apps which would ultimately become Google workspace is making noise.
One day is coming for HR and Box is coming for file storage and service now is coming
for ITSM.
Every single one of these applications is an island and we all know that islands are terrible
for enterprise security.
Because every island has its own idea of what a user looked like.
Some systems stored first name and last name as separate fields.
Others stored a display name as a single string.
Some had departments, others called a division and somebody else called it cost center.
An email was it the user name, was there a separate user name, was it case sensitive,
nobody really agreed on anything.
So what did the IGA vendors of the time did?
They built transformation and translational layers.
Gorgeous, elaborate, drag and drop mapping screens where you could say things like take
the value from department and the score code, run it through this lookup table, concatenated
with the first three characters of cost center, convert to lowercase and that becomes the
department field in the target system.
And it worked and honestly it still works, but until the source system changed their
field name or the lookup table got out of date or someone in HR decided that engineering
should now be called technology.
And suddenly half your users were landing in a department called null.
The transformation layer was essentially a full-time job dressed up as a configuration screen.
Some enterprise had people actual human beings with job title whose entire role was maintaining
attribute mapping logic across systems.
So what did everyone else do?
The people who couldn't afford the enterprise IGA suite, they wrote scripts.
Now honestly, the large enterprises, the ones running OIM or CA, weren't doing this for
the script.
They had connectors, they had workflows, they had transformational layers, and they had
spent millions to solve exactly this problem.
But here is what happened, SAS moved faster than the connector catalog.
I kid you not, sometimes when I used to work on OIM implementations, it probably took
from three to six months in setting up all the environments.
Five environments and non-prod systems and prod systems and databases and procurements.
It almost took three to six months.
Can you imagine it in today's word?
And then just connecting to HR system and active directory was probably another couple of
months.
So before even one user got terminated, which was the lowest hanging use case, you have
probably already spent a couple of million dollars and have been doing it for the past
seven to eight months.
And that was the reality of the time.
But SAS moved faster than the connector catalog.
Every new application that didn't have a certified connector became someone's weekend project.
And in made market companies, the one who couldn't justify a seven-figure IGA implementation
is scripts were absolutely the provisening engine.
These scripts were glorious and they were terrible.
For Shell or Python or shell scripts held together with the institutional knowledge of one engineer
who by the way left the company three years ago.
And these scripts mostly ran on cron jobs usually at 2 a.m.
Usually on a server nobody touched because everyone was afraid that if you looked at it
wrong, it would stop working.
And this servers always had a name, something like legacy-prove-01 or legacy that prov.02.
And hopefully, and most likely, there was a sticky note on it that said do not restart.
And the termination problem that cut across everyone, OIM shops included.
SAS Marked as terminated in the HR system was never the same as excess revoked in every
SAS application.
The IGA tool covered what it knew about.
Everything outside that perimeter, the new Slack workspace, the Zoom account, someone provisioned
directly, the GitHub or the dev team set up without telling ID.
None of that got cleaned up.
The word was divided in two groups, and neither of them were perfect, but neither of them
were wrong.
So these two groups were script and CSV word.
SMB and mid-market who couldn't afford OIM or CA, enterprise who had IGA for core systems,
but had SAS apps outside that perimeter and contractors, stems, non-employees, even
OIM shops, often had gaps.
And what OIM and CA were actually doing, they were solving the problem for sanctioned
connectors supported systems.
But the connector catalog didn't keep pace with SAS growth.
And the cost and complexity meant sprawl happened around the IGA tool, not through it.
Studies from this era consistently found that enterprises had 30 to 40% of SAS accounts
belonging to people who had already left ghost accounts sitting there quietly.
Now this is not a theoretical security problem.
That is how former employees retain access to Salesforce six months after they had, after
the last day, and that specific gap, the SAS parameter that existing tools couldn't reliably
cover is what a group of engineers decided needed a standard answer.
And that standard answer became skim.
Now, Scheme didn't emerge from a vacuum as we have seen and understanding where it
comes from will help you understand why it's built the way it is.
So this year was 2011, a group of engineers and architects primarily from large SaaS companies
started having conversations about a shared problem and this is why I believe in the
community information sharing across all the security domains.
Everyone was building custom integrations, everyone was reinventing the wheel, everyone
was spending engineering time on plumbing that had nothing to do with their core product.
Salesforce, Google, Ping Identity, they were among the early voices.
The conversation was essentially can we agree on a common way to represent users, groups
and the operation you do on them.
So the first version, Scheme 1.0 came out in 2011 under the IETF or the internet engineering
task force.
For those who are unfamiliar, the IETF is the body that gives us the standards that runs
the internet think STTP, SMTP, OAuth, DNS, these all went through the IETF.
So when Scheme landed in the IETF, it was being taken seriously.
Now, Scheme 1.0 was a start but like most 1.0, it was rough.
It had schema inconsistencies, some ambiguities or in behavior and it didn't have broad enough
adoption to prove itself.
So what happened next is nobody's, like everybody would guess it, the air came Scheme 2.0,
which was remarkably better than Scheme 1.0.
This was published in 2015 as RFC 7642, 7643 and 7644 and yes, I am going to break those
down because these actually matter.
If you have time, I would really advise you to go back and read them.
This is not an academic RFCs, they really are much nuanced and I think every identity
engineer could benefit from reading them.
So Scheme 2.0 was much more complete and much more coherent with specifications.
RFC 7642 is the definitions, overview, concepts and requirements document.
Think of it as why we are here document is explains the problem space and the design
goals.
7643 is the core schema.
This is the data model.
What does a user look like?
What does a group look like?
What attributes exist?
What are their types and cardinality?
And then 7644 is the protocol.
This is how you talk document, the STDP method, the endpoints, the filtering system, the
pagination model, the bulk operations.
You look at this flow, I am absolutely mesmerized for this.
That is why it is easy to remember 7642, 43 and 44.
The definitions, the core schema and the protocol.
Looking from why are we here to this is the data model and then this is how you talk.
So three RFCs are very deliberate separation of concerns and that separation concept, schema
and protocol is actually quite elegant.
Now here is something important to understand about Scheme 2.0.
It is built on two technologies that by 2015 were already well understood.
These two technologies were JSON and REST.
And this was a very intentional choice.
The predecessor to Scheme in spirit, not in direct lineage, was something called as SPML.
Service provisioning markup language.
I personally love the name SPML.
Service provisioning markup language has made sense to me.
SPML was an OS standard from the early 2000s, so much ahead of its time.
It used XML, it was so based and yeah, I kind of see why it was not popular.
But there is a reason you have probably never heard of SPML.
It was technically capable but practically so painful.
It was XML heavy, complex to implement and at a time when web services were still trying
to figure themselves out, it was just such a pain to implement.
Now Scheme 2.0, thankfully learned from that.
JSON is human readable, widely supported and every programming language has a JSON library.
And REST is the lingua franca of web APIs by 2015.
By building on these foundations, Scheme dramatically lowered the barrier to implementation.
The other major improvement in Scheme 2.0 was Schema Extensibility.
The core schema defines a set of standards attributes.
But Scheme allows you to define extension schema, name spaced attributes that are specific
to your use case.
So if your company has a custom attribute called clearance level, you can add it to the
Scheme schema without breaking the core script.
But as with all good things or with most good things, adoption wasn't instantaneous.
2015 to 2018 was the slow burn.
A handful of major identity providers like Octa, Azure AD or EntryD, one login, started
building Scheme Support, a handful of major SaaS apps, started building Scheme and points.
And then something happened.
The pandemic, it was a catalyst for so many different things related to identity.
And it was a catalyst for this identity protocol as well.
As you all know, the word went remote overnight.
The companies that were used to an on-premise Active Directory and VPN based access suddenly
found themselves needing to provision and deep provision employees at scale across dozens
of SaaS applications with no physical office to anchor anything.
So without going into it, you understood what pandemic change and this demand for automated
provisioning exploded.
And Scheme, which had been steadily maturing, was ready.
Thankfully so, Octa's Scheme integration catalog grew dramatically.
EntryD, Scheme Support, deep end, service now, work day, GitHub, Slack, Zoom, all of them
either built or improved their Scheme and points in this period.
And that is why I always feel like these companies are trying to do the right thing in most of
the cases.
But today in 2026, Scheme is table stakes.
If you are a SaaS vendor selling to enterprise and you don't have a Scheme and point, you
should be and are most likely to lose deals full stop.
Okay, so let's get a little technical here and not the kind of technical where I look
like a crazy person, hopefully not, but the kind of technical where by the end you could
explain Scheme to someone on a whiteboard, okay, let's see if I can make it happen.
So Scheme stands for system for cross domain identity management.
So let's parse that name system.
It's not just a data format, not just an API style, it's a complete system.
Cross domain is the whole point, different systems, different identity stores, different
vendors maybe, and my likely.
And then identity management, user, groups, and operations that keep the up and sing.
So at its core, Scheme is a rest API specification for managing users and groups.
That's all, that's it, that's the elevator pitch.
But if we go one level deeper, Scheme defines a resource model.
There are two core resources, users and groups.
And a user has a standard set of attributes like user name and name and email, phone numbers,
addresses, title, department, active, extended, whatever else, and ID, an ID like an identifier
assigned by the Scheme service provider.
And it also might have an external ID, the identifier from the authorative source system.
So this last distinction in the standard set of attributes for the user, the external
ID versus just the ID is important and often confused.
The external ID is your
identifier. It's the ID from the upstream system that's pushing data. So if
Workday is your HR system and Workday generates a unique employee ID, say
employee 00429, that becomes the external ID in the skim payload. Now the
second attribute, the ID is the target systems identifier. When you create a
user in octava skim, octa generates its own internal ID. Some opaque string
and returns it back. That is the ID. And on subsequent requests, you use that ID to
refer to that user in that system. This is a clean well thought out pattern.
It acknowledges that identities exist in multiple systems and that each system
has its own namespace. So we now understand what is the elevator pitch for
skim, skim and external ID and ID and things like this. Now let's talk about
the protocol layer for a second. What you actually do with skim? So skim uses
standard STTP method mapped to crud operations. So post to users creates a
user get to users slash ID reads a user and then puts is full replace and patch is
partially updated and delete is deleting a user right very intuitive. And for
groups post will create a group and patch to the groups slash ID will add or
remove members and delete will delete a group. So there is also a get with the
users endpoint with filtering and this is where skim filtering syntax comes in.
So you can actually say things like get on users endpoint and filter is equal to
user name equals Rohit or get users filter equal to email dot value equals
[email protected] and active equal to so a skim has its own filter syntax not
SQL not GraphQL but it has its own thing. It supports things like EQ that's
equal or any or CO that means contains or SW starts with or EW that ends with
PR presence GT LTGLE and it also supports logical operator like AND or and NOT.
It's reasonably expressive for the use case super simple to learn. It will
probably take you less than 30 minutes to understand the skim filtering syntax
and honestly don't even need to learn it you just need to know that something
like this exists out there. Now patch and skim is worth a special
mention because it's different from how you might think about patch in general
rest APIs. So skim patch uses a structure called a
patch of short for patch operations and each patch request contains an
operation array where each operation has an off field like add, remove or replace.
So it's like your operations adding, removing, replacing.
It has a path field or path field which has a skim attribute path
possibly with a filter and then the value field which is the new data.
So you can use the patch on the group resource to add a user to a group
or if you want to deactivate a user without deleting them
your operations could be replaced and path could be
active and value would be false so it would replace and the value of
active would be set as false. That's it you know with one patch
you can deprovision users across the system or user across the system.
There is also a service provider config endpoint. This is the skim discovery endpoint
where a service provider service provider is the system receiving skim calls
declare what it supports. Does it supports filtering? Does it support bulk
operations? Does it support patch or only port? What does it really support? Does
it support ETAP for optimistic concurrency? So this is genuinely useful. Before you
implement an integration you should always query
service provider config and understand the capabilities of the system you are
talking to. In practice it is underused because
implementations are inconsistent but the intent is good and then there is the
endpoint schemas endpoint and endpoint where the service provider
lets all the schema it understands including extensions. You can query this to see
the full data model including customer or custom enterprise
attributes. Now let's spend some time on something that trips people up
constantly and give it a second here like I want you to think through this
what is the difference between provisioning and skim?
So we really need to understand this. A skim is a mechanism for
provisioning. Provisioning is the outcome. They are not the same thing.
So let's understand with that just like provisioning it's like getting a
package delivered to your house that's provisioning. A skim is like
UPS not the only delivery service but a very
standardized well-known one that shippers and receivers have agreed to
support. For people who are not familiar with the UPS
thing like provisioning is like getting a package delivered to your house
and skim is like FedEx. So you could use any other service that's
native to your country. That's like a vendor specific API or you could use a
person driving a van with no tracking system. That's like a flat file
integration. All of them delivers package. A skim is just the standardized
career. So provisioning is in the identity context is the life cycle
management or digital identities. So all of us understand provisioning in
compasses, joiners, movers and levers. Where joiner is when somebody is
joining the organization, movers when somebody's or someone's role changes
and levers is when someone leaves. Their access needs to be removed.
So this is what we typically call as the joiner mover lever workflow or
GML for short. And arguably this is the most critical
function in enterprise identity. Getting GML wrong is how you fail audits.
It's how you get breached. It's how you boil at least privilege
principles. If I think deeply about it,
getting GML and your conditional access policies wrong are potentially two
biggest landmines that identity team creates.
Right, but I don't want to digress from the topic of GML. So now within provisioning
there are different methods. You could have manual provisioning where somebody
submits a ticket and human creates the account. You could have script based
provisioning like this. The do not restart server era. We talked about
you could have IGA based provisioning using an
sale point or save end or something like that to orchestrate provisioning based
on roles and policies. You could have IDP based provisioning using an
identity provider like author or enter or ping to push identity changes to
connected applications. And this is where skim faced fits most
naturally today. Also, you could have an HR driven provisioning.
So treating the HR system like your workday or success factor or bamboo HR
as the authoritative source of truth for identity and and having changes that
cascades downstream. And skim is increasingly used here too,
particularly in the octa workday and enter a workday integration.
So think about it. Let's repeat this a little bit here.
Provisioning is a mechanism for provisioning. Now how many different types of provisioning exist? We have manual script,
IGA based, IDP based and HR driven. And skim most likely fits most
naturally into an identity provider based provisioning or now increasingly
in HR driven provisioning. So when someone says we use skim for provisioning,
what they typically mean is their identity provider like an octa or
enter or ping is configured to push user lifecycle events to a target
application via the skim protocol. That's simple.
Now the flow looks like this typically. A new employee is created in workday.
Workday notifies the IDP through its own integration.
The IDP provisioning engine evaluates the user's attribute against
provisioning policies. The IDP pushes a skim post to the
user's endpoint to each application the users should have access to.
Each application creates the users and returns the system assigned ID.
the IDP stores that mapping
like User X in my system corresponds to IDY in this application.
And now future attribute changes trigger skim patch request.
And when the user is terminated, the IDP sends either a patch
to set active falls to lead something like this. You got the point.
That is automated provisioning via skim, which is clean,
auditable and fast. And when it works, it's genuinely beautiful.
Now one more distinction that that is worth making here is
about authentication versus provisioning. And you would be like,
"Row it really? Are you really going to differentiate
authentication versus provisioning to us?" And I would.
Now because there are completely separate concerns that often gets conflated.
So authentication is, can this person get in?
So think about it about like the IDP
paste provisioning is happening here. Right?
And that is where most people get confused. Authentication, as you all know,
is, can this person get in? It's about verifying identity at log-in time.
This is where SAML and OIDC live SSO federation identity.
Provisioning is, does this person accounts exist in the system?
And does it have the right attribute and access? This is where skim lives.
So think through this deeply. You can have SSO without skim.
The user logs in via SSO the first time and the application
creates an account on the fly through a process called as
just in time provisioning or Z. But Z has a problem.
It doesn't handle the provisioning. When someone leaves,
Z doesn't allow to go delete their account.
They just stop logging in the account lingers.
These are the type of distinctions that we need to understand
to work in our any capacity within the identity ecosystem.
You could be an identity analyst. You could be an identity engineer.
You could be an identity architect. You could be an identity leader.
You could be a business analyst or identity analyst or whatever.
But we need to understand these distinctions.
Now you can also theoretically have skim without SSO.
Think about it for a second. Can you theoretically have skim without SSO?
Though this is much rarer and usually transitional.
So think about skim and SSO and just in time
and create that mental picture in your head.
So in practice, the gold standard is SSO plus skim.
SSO handles authentication. Skim handles the account life cycle.
Together they give you complete control over who can access what
from day one to their last day.
Now let's make this a little bit more practical
because I get asked this question all the time.
When does skim become worth caring about?
My honest answer is if you have more than 15 employees
and more than 10 SaaS applications,
skim should already be on your radar.
If you have more than 200 employees and you are not talking about skim,
you have a problem brewing.
So let us talk through some concrete signals.
And these are the moments when skim goes from now nice to have
to we need this like yesterday.
So you get an audit finding or words you get a breach
and the investigation reveals that the former employee
still had active accounts in 358 SaaS applications.
Bonus points for irony.
One of those applications is your security platform.
This signal is unfortunately how many organizations first
get serious about provisioning.
They learn the hard way.
If you are listening to this and you haven't had that horror story yet,
consider this your warning shot.
The second signal is the IT ticket backlog.
New employees are waiting 2, 3, 5 days for access to the tools they need.
Like really do your IT team is drowning in provisioning tickets.
Please create an account in Slack, Salesforce, ServiceNow, Zoom,
GitHub, Confluence, ZeraBox and for Jane Doe who starts Monday.
If your IT team is doing this manually for every new hire,
for every mover you are spending human capital on something
that can be automated.
That's not a process problem which everybody likes to say.
This is our process. That's not a process problem.
That's an architecture problem.
And the third signal is your compliance.
The SOC 2, the ISO 27001, the HIPAA, the PCI DSS, the FedRAM.
Every one of this framework has requirements around access management.
They want access. Evidence that access is granted based upon business need.
That it's reviewed regularly and that it's reworked promptly upon termination.
Promptly in many frameworks means within 24 hours, sometimes sooner.
You cannot manually hit that SLA across 15 SAS applications.
You need automation and you need skin.
The fourth signal probably is someone in your organization does a shadow IT audit
and they discover that the company has subscription to 120 different SAS applications,
many of which the IT team didn't even know existed.
And when they start looking at users' account and these systems,
they find a graveyard of ex employees.
This is increasingly common.
The average enterprise today uses somewhere between 100 to 250 SAS applications.
And I'm saying average, right?
It could be very well in B1000s depending on size.
That's not manageable with manual processes or one of scripts.
So what does Schema adoption actually requires?
On the IDP side, you need an identity provider that supports Schema Provis thing.
You will opt-out, enter a ping, jump cloud, one login.
All of these supports outbound Schema Provis thing to target application.
If you haven't really looked into it, go and look at your identity provider
and go look at their Schema Provis thing documentation.
On the application side, you need the SAS vendor to have a Schema 2.0 endpoint.
Then this is increasingly common, right?
You need the SAS app, Slack, Salesforce, GitHub, Zoom, ServiceNow, Workday,
Snowflake, Box, Dropbox, Atlassian.
Most major enterprise SAS apps supports Schema today.
Actually, you know what?
You can use AI.
Look at all of the SAS applications within your enterprise
and try to identify how many of them supports a Schema 2.0 endpoint.
I would say close to 90 to 100%.
The integration itself is usually configured in the IDP.
So, you provide the Schema endpoint URL, a bearer token for authentication
and you define attribute mapping.
And that's it.
Then you test with a few users before you roll it out broadly.
Now, it's not zero work.
I don't want to minimize the work.
But it is dramatically less work than maintaining a custom integration.
And one, it's done.
It largely takes care of itself.
I have not seen too many Schema related on outages, honestly.
So, when you are thinking about Schema in an enterprise context,
you are usually dealing with three categories of tools,
your identity providers that push Schema,
your IGF platform that orchestrates at a higher level
and SAS applications that receive Schema.
So, let's walk through each of these categories so that we can,
you know, map it to our current tools ecosystem
and who plays in what space.
So, category one is identity providers with the Schema provisioning.
This is what we have been talking about.
These are the systems that sit in the middle that know your users
and they push changes to downstream applications.
So, Octa arguably the market leader in this space
with their unified universal directory, right?
Your Microsoft Enter ID and your jump cloud,
one log in, even cyber-arch identity,
and 402 are part of paying all of the prayers in this space.
And then category two, your IGF platforms,
your sales point identity now,
or identity security cloud, your identity IQ,
your Savient.
Savient is a strong competitor to sales point.
And especially or particularly in the cloud native space,
Savient has built deep support for Schema.
And it is known for being strong in application access governance,
not just infrastructure.
You also have IBM security,
verify governance and Omar identity,
and then your Schema service providers,
which are the apps and we have already spoken about them, right?
So, Schema 2.0 is a specification
and it tells you what should be supported.
It does not guarantee that every vendor implementation
is complete, correct or consistent.
So, in practice sometimes you will find implementations that support put but not patch, don't implement
filtering correctly, have unexpected behavior on delete, don't honor the external ID properly
and things like this.
Or could have undocumented rate limits that causes intermittent provisioning failures.
This is the practical reality of skim.
The protocol is solid, the implementations are a mixed bag, testing your skim integration,
thoroughly especially around edge cases like deprovising and attribute conflicts is not
optional.
And honestly there are tools to help with this, you can use go to skimvalidator.net, it's
a publicly available skim validator and opt-up publishes a skim test suite.
If you are a vendor building a skim and point, running against these test suites before
you claim skim 2.0 compliance is the responsible thing to do.
A skim is not a silver bullet though, I want to be clear about what it does not do because
misunderstanding this leads to failed implementations and disappointed stakeholders.
So, let me repeat this, skim is not a silver bullet, skim does not handle fine grained
entitlement, skim can tell a system this user exists and belongs to this group but it cannot
tell a system this user should have read access to the specific folder but not that one.
That level of authorization is application specific and typically has to be handled either
by the application itself or by a civilized access management layer or a policy based
access control layer.
Skim does not handle authentication and we covered this, right?
The skim is about provisioning, Samuel, YDC and Oath handles the authentication and token
flows.
Skim and SSO are complementary but not interchangeably.
Skim does not replace IGA for governance.
If you need access certification campaign where manages review and re-certify who has
access to what on a quarterly basis, Skim alone does not do that, you need an IGA layer
on top.
Skim is also not a real-time event stream, skim is a polling and push model, the IDP pushes
to application but it is not an event streaming architecture.
If you need real-time audit trails of every access event, that's seam territory, security
information and event management systems.
I've also seen that skim does not handle privileged accounts well, service account, shared
account, pre-gloss account, skim is designed for human user life cycle mostly.
The PAM tools handle the privileged account world and these two domains are increasingly
getting integrated but they are still distinct and I'm actually very excited about this
integration.
But understanding these gaps is not a criticism of skim, it's just the reality of how the
identity stack is built today.
Skim occupies a very specific, very important layer and knowing where its edges are helps
you design the right overall architecture.
So in closing, Skim was born from the chaos of enterprise sass crawl.
Standardized in 2015 as a clean, rest and gson based protocol for managing users and group
life cycle across systems.
Now this table takes for any serious enterprise identity program.
Let me leave you with a few mental model that I have used over the years and that I think
capture why skim matters.
Skim is the plumbing of the identity house.
Nobody frames a house and then admires the plumbing but try living a house without it.
Bathroom doesn't work, the kitchen is non-functional, everything you care about falls apart.
Skim is the same.
Nobody puts skim on their road map because it's exciting.
They put it on the road map because without it, everything downstream gets messy.
Skim turns identity from a snapshot into a continuous thing.
Without skim, identity is often captured once when someone joins and then slowly it becomes
a line.
With skim, identity is a line, it changes when the human changes, it reflects reality.
And finally with skim is the difference between we trust our IT team to we can prove our
excess controls.
In a word of increasingly regress compliance requirements, news sass applications being
brought into the enterprise every day and the amount of workload that is there on the
IG 18, a skim is non-negotiable.
It is not glamorous, it doesn't, it cannot be a flashy demo but you don't get to show
someone a skim dashboard and have them gasped.
But when someone joins your company and access to has access to everything they need on their
first morning, that is a skim working.
And when someone leaves your company and have every account even the sass applications,
all the sass applications, every account logged within the hour, that is skim working.
That is identity done right.
So this is all I know about skim, I have not told you everything, that's all, that is all
I know.
So you know all about skim right now, but I also want to discuss a little bit about
decision framework of when and how to think about skim.
But as I look over time, we are a little over 45-46 minutes up.
So let's discuss that in our next episode.
We will discuss a decision framework of when and how to think about skim.
Do let me know what you think about this episode and if it was worth your time, please
give a rating on whatever plate form you are on because it really helps and share it with
someone if you think it would help them.
Until next time, this is Rohit, your identity navigator.
PodcastTranscript AI