Joining CyberArk, SailPoint, and Entra into one answer

You do not yet have an answer, because the verb is described in three places that do not share a language. Entra will say one thing. The governance platform, SailPoint or whatever does that job for you, will say another. CyberArk, or the vault in its place, will say a third, or it will say nothing, and nothing will be briefed as "not privileged".

Joining is not integration. Integration is a project in which connectors sync accounts and everyone celebrates a percentage. Joining, here, is a reading. The same identity, the same verb, three stories. Where they agree, you have a fact you can brief. Where they disagree, the disagreement is the finding. Programmes that wait for the stacks to agree before they will talk about access will wait out the incident.

One identity, three stories

Pick a row from the Chapter 2 table that is awkward. Awkward means it appears in more than one stack, or it appears in one stack and in a local store, or two stacks claim it and describe different verbs. Do not pick the clean employee with one group and a completed certification. That row will teach you nothing about joining.

Write the identity as you found it, the string from Chapter 1, not the display name each product prefers. Then write three short statements, forced into the same shape.

Entra says: this object exists or does not, this permission or role is assigned, this state is active or eligible, this sync or this app role is what would make the verb succeed.

The governance platform says: this entitlement is what we call it, this campaign last decided it, this identity is correlated to this account or is an unmatched account or was never aggregated.

The vault says: we hold a secret for this account, or we do not, and if we do, a checkout and a recording are or are not required. If there is no secret because the identity is a managed identity or an application permission, the vault's silence is expected. Write "no credential to vault" rather than "not in CyberArk" as if that were a pass. Expected silence and unexpected silence are different findings. Unexpected silence is a password that should have been vaulted and was not.

Under the three statements, write a fourth, which is yours. The verb that would succeed this morning is this, because of these objects, and the stack that is telling the truth about the grant is this one. The fourth statement is the answer. The first three are evidence. Reviews that brief the first three and skip the fourth have produced a status report. Figure 3 is that join.

Figure 3. Three stacks, three stories, and the fourth statement. CyberArk, SailPoint, and Entra each describe the row. The fourth statement is the one answer to who can do what: which story still grants the verb when the other two are closed. No score sits on the join.

On the Billing-Readers row the three stories can be written. Entra says the group holds an application role that can reset credentials on the billing user store. The governance platform says the entitlement is Billing read. The vault says there is no credential to vault, which is expected silence, not a pass. The fourth statement is the only one that answers: the reset would succeed this morning, the object is that application role, and Entra is the description that wins.

What agreement is worth

Agreement is pleasant and weaker than it looks. All three stacks can agree and still be wrong, if they all ingested the same incomplete source. A user federated from Entra into the governance platform, with a vaulted additional account, can be perfectly joined and still not be the identity that runs the batch job. Joining the onboarded estate more tightly describes the visible estate with three pens.

If all three describe the same object and the same verb, you may treat that row as governed for the ratio, provided the who-cell is a person you could call and you have looked for a second object that would keep the verb alive. Agreement without those two checks is correlation. Do not promote it to an answer.

A disagreement has a type. Name the type, or the row will be debated as "data quality" and sent to a backlog called "identity sync exceptions". Sync exceptions are how this chapter dies.

Five disagreements worth naming

The permission the directory has and the entitlement the platform does not. Entra shows an app role or a directory role. SailPoint has no entitlement, or has a different one, because the aggregation did not include that application, or the entitlement catalogue was last mapped when the permission was narrower. The grant is the directory's. The action is to treat the direct ory as the answer and the platform as behind, not to wait for a recertification that will not see the row.

The entitlement the platform has and the directory no longer grants. The campaign will ask a reviewer to approve a ghost. Approving it feels like control and changes nothing. Rejecting it feels like a finding and also changes nothing, until someone removes the entitlement from the model or restores the object. Write "stale model" on the row. Stale model is not access. It is a lie that wastes a reviewer's afternoon.

The vault holds a secret for an account the other two describe as unprivileged. The account can still be used with that secret. Unprivileged in the directory and powerful in practice is an old pattern: a local admin, a database login, a vendor account, a break-glass identity that was never given a directory role because it does not sign in through Entra. The vault's possession of the secret proves the account is operational. It does not prove the verb is small. You still have to say what the account can do on the resource.

The directory shows a privileged assignment and the vault has nothing, when the assignment is a password-bearing account. Someone is checking that password out of a spreadsheet, a repository, or a head. Joining makes it visible because the vault's "no" beside the directory's "yes" is the whole finding. If the assignment is a managed identity or an eligible role with no password, the vault's "no" is the expected silence. Mark it expected. Do not raise a vault-onboarding ticket for an identity that has no secret.

The cloud story and the on-premises story disagree, and sync will make them disagree again tomorrow. Joining Entra to SailPoint without joining both to the on-premises source is a two-stack answer to a three-directory problem. The third stack in this chapter is the vault only when the vault is in the path. When the path is sync, the third description is Active Directory, and pretending CyberArk is the missing voice will send you to the wrong console. Say which three you actually mean for the row. The book's three are the common enterprise set, not a law.

There will be other disagreements. A governance platform correlated two accounts that are different people. A vault rotated a password and a pipeline still has the old one, so both secrets work until the old one is revoked at the resource. File them by which description, if the others were closed, would still let the verb succeed.

A join on identifiers

You do not need an identity-fabric product to do this for one neighbourhood. You need the table you already have, and a rule for identifiers. The join belongs in the monthly brief.

Pick the identifier you will trust. For an Entra object, the object id, not the display name and not the user principal name alone. Names are edited. Mail nicknames collide. Object ids are what the permission is actually stuck to. For a vault account, the vault's own account id plus the address of the target system. For a governance identity, the native identifier it stores for the correlated account, and the application account id when the row is an application account rather than a cube identity. Write these in columns. A join on display name will look successful and be wrong often enough to brief a fiction.

Match object id to the governance platform's stored native id first, then the account id the connector uses. A name match is only a hypothesis for a person to confirm. Record who said the objects are the same. An unconfirmed name match briefed as a join sticks two people's access together.

For each matched row, copy the three statements and the fourth, your answer, into columns. You already defined the statements. Do not paraphrase them differently per row or you will be unable to filter. Entra's verb, the platform's entitlement, the vault's secret state, your verb, the disagreement type if any, which description wins.

Rows that do not match are not failures of the exercise. An Entra service principal with no governance identity is an identity the catalogue missed, if it can act, or an unaggregated identity if it is only a registration with no permission. A vault account with no directory object is a local or infrastructure account. A governance identity with no directory object and no vault account is either a stale cube record or an application you have not found the store for. Sort the unmatched into those piles before anyone calls them exceptions. Exceptions go to a backlog. Piles go to an owner.

Do this for the neighbourhood you already chose. Do not widen. A month of joining one neighbourhood will produce more disagreement than a quarter of connector work across the estate, and you will believe it because you can open each row.

What not to automate yet

Do not automate the fourth statement. The three descriptions can be pulled by connectors. The sentence "the verb that would succeed is this, and this stack is the one telling the truth" is a judgment. If you let a rule write it, the rule will prefer the stack you already trust, which is usually the governance platform, because that is the stack whose job is to be the system of record. The system of record is the catalogue. A rule that sets the answer equal to the catalogue undoes the join.

Do not automate unmatched rows into deletion. An unmatched vault account may be the only copy of a credential for a system that still runs. An unmatched service principal may be the production deploy. Joining's job is to show the row. It is not to tidy it.

Do automate, when you are bored of copying, the collection of the three descriptions into the table. Export role assignments, app role assignments, entitlement lists, and vault account lists into the columns. Keep the match on identifiers. Keep a person on the name matches and on the fourth statement. Boredom at copying is a good reason to script the extract. Boredom at thinking is not a reason to script the answer.

Joining a sponsor into the who-cell is not joining the permission. A row with a sponsor and an empty permission list is a person attached to a blank verb. Collect the app role assignments in the same pass or the sponsor will be briefed as if they had stood in for the object. The exit stays the empty cell.

Reading a disagreement to a sponsor

Sponsors do not want five types. They want the row that frightened you, and the count.

The count is: how many rows in this neighbourhood have a winning description that is not the governance platform. That count is how many verbs the campaign is not the authority for, and it should change how much comfort a completed certification is allowed to give. The platform is behind the grant.

The frightening row is one disagreement, told in four sentences. What we found. What Entra says. What the platform says. What would still work if we did what the platform is suggesting, and why that would leave the verb in place. If you cannot get it into four, you do not yet understand the row. Take it back to the objects.

Do not bring a connector architecture diagram to this briefing. The diagram is how the stacks might one day share an identifier. The table is whether they share a truth today. You cannot substitute it for the count.

Where CyberArk is in the path, and where it is not

This book is for the lead who already has the stack, so CyberArk is named. It is not in every path, and pretending it is will distort the join.

CyberArk is in the path when the verb is unlocked by a credential a person or a workload retrieves, or by a session the vault brokers. In that path the vault's story is a primary description. "We did not onboard it" is a finding. "We onboarded it and a second copy remains" is a finding. "We onboarded it, the password rotates, and the account is still standing admin" means the vault did its job and the privilege is still standing. Do not make the vault team the owner of a verb the directory granted and the vault merely stores.

CyberArk is not in the path when the verb is an application permission, a managed identity, or an eligible directory role with no password. The vault's silence is expected. The join is between Entra and the governance platform, and the third voice is the resource's own access list. Forcing a vault column to "compliant" on those rows is how privileged-access programmes report coverage they do not have and do not need. Leave the cell as "no credential to vault" and spend the time on the app role.

Some rows are both. A workload uses a managed identity for one verb and a vaulted client secret for another. Those are two rows. Joining them into one "privileged workload" cell sands the join. For each object, say whether the vault is even in the conversation.

SailPoint gets the same courtesy. It is in the path when it has aggregated the application and modelled the entitlement. It is not in the path when the application was never onboarded. An unaggregated application marks a boundary of the catalogue. Do not apologise for it in the briefing as if SailPoint had broken. Say the boundary. The alternative is a sentence like "SailPoint shows no toxic access", which is true because SailPoint was not looking.

Correlation is not identity

Governance platforms talk as if correlation were solved. Underneath, a set of rules guesses which account belongs to which person, and the guesses have a blast radius.

A rule that matches on employee id will split one person into two identities when a contractor is rehired and the id changes, or when the application stores a badge number the HR system has never seen. The access did not split. The model did. Certifying both cubes, or neither, is a guess. The verb is on the account, not on the cube.

A rule that matches on name will join two people. The reason it survives is that the errors are quiet. Nobody clicks a button labelled "merge these two humans". The merge happens inside a successful connector run, and the run is reported as health.

A rule that matches a service account to the human who requested it will put a workload's verbs on a person's cube. The person leaves. The leaver process disables the person. The workload keeps its secret and its permission, now hanging off a disabled cube that the campaign skips because disabled identities are excluded from review. You have joined the access to a corpse. The who-cell looks handled. The object is alive.

Write the correlation rule on any row where a person and an account were joined by the platform rather than by an object id you checked. If you cannot name the rule, the who-cell is platform-asserted, not confirmed. Platform-asserted owners fill the who-cell with someone who has never heard of the account.

Service principals and managed identities should not be correlated to a human at all, except through an explicit sponsorship field you trust. Sponsorship is a who. Correlation is a guess. Do not let a guess occupy the sponsor cell. If there is no sponsorship field, the who-cell stays empty. Empty is the true state. A guessed owner is a false one, and false owners get briefed.

What "single view" usually means

Vendors, and internal architecture slides, promise a single view of identity. The single view on offer is almost always one product given authority over the other two. Authority does not change which object grants the verb.

Ask for something smaller and ruder. For this neighbourhood, can we store, against one identifier, the three descriptions and the name of the description that wins? Can we store a disagreement without opening an incident? Can we stop a certification percentage from overwriting the winning description?

If the answer is yes, the single view is worth building later, and not as a rule that writes the sentence. If the answer is "the governance platform will be the source of truth", you have been offered the catalogue again. Decline it politely. Keep the sheet.

A useful single view has to tolerate a blank. Products that require every cell before they will save the identity will force analysts to type "n/a" or "TBD owner" into the blank, and those strings will be briefed as data. A blank kept blank is information. A blank filled to satisfy a schema is contamination. Prefer the tool, including a spreadsheet, that lets the cell stay empty.

Recount the same neighbourhood next month, on the same identifiers. A disagreement that remains has either not been touched, or was touched in the stack that does not win. A disagreement that disappeared because the grant was removed is a change in the estate. A disagreement that disappeared because someone deleted the row is a change in the notes. Keep the evidence pointer so you can tell those apart.

Count what the neighbourhood grew. Pipelines create principals between briefs. Ignore them and the ratio improves while the estate gets worse beside it. Only then consider a second neighbourhood: oldest, last acquired, or fastest shipping. Not the place where the connector is already healthy.

Products rename themselves. If the join key includes a product name, the next marketing cycle breaks it. Keep the key as the object identifier and the system address. In the briefing you may say Entra, SailPoint, and CyberArk, because that is this reader's stack. In the sheet store directory, governance model, and vault.