Introduction
Most teams think of identity as a thing that is simply true: a user is in a group, the group has a permission set, therefore the user has access. Clean, logical, instantaneous. The reality underneath is messier and more mechanical than the mental model suggests. Between your identity provider (Google Workspace, Okta, Entra ID, whatever you use), AWS IAM Identity Center, and the tools that govern access on top of them, identity information doesn’t flow continuously. It flows on a schedule — a sync that runs periodically and reconciles what each system believes about users, groups, and permission sets.
That scheduled sync is one of the most underappreciated sources of operational pain and security surprise in cloud access management. When it runs on time and everything agrees, nobody notices it exists. When a change hasn’t synced yet, or a sync surfaces a conflict, you get a very specific class of problem: access that should work but doesn’t, permissions that should be gone but linger, and identities that behave differently from what the configuration screens say they should.
This post is about understanding sync timing as a first-class concern — why it causes the symptoms it causes, how to reason about it, and how to design your access processes so the sync schedule is a known quantity instead of a recurring mystery.
The Mental Model: Identity Doesn’t Flow in Real Time
Start with the architecture, because the symptoms only make sense once you see the plumbing. In a typical modern setup:
- Your identity provider (IdP) is the source of truth for who exists and who belongs to which group.
- AWS IAM Identity Center receives that information — often through a sync mechanism — and holds the users, groups, and permission sets that federate into your AWS accounts.
- Your access-governance layer (the tool that handles just-in-time grants, approvals, and audit) reads from Identity Center to know what’s requestable and by whom.
Each hop is a sync, and syncs run on a cadence. A common pattern is a scheduled reconciliation every 12 hours, with a manual, on-demand refresh available when you can’t wait for the next scheduled run. In large environments, even the manual refresh isn’t instant — reconciling a big population of users and groups can take several minutes, and up to about an hour for very large directories.
The single most important consequence of this architecture: a change you make in one system is not visible everywhere the instant you make it. You add a user to a group, or create a new permission set, or map a group to an account — and there is a window, bounded by the sync cadence, during which the downstream systems don’t know about it yet.
Symptom 1: “I Was Granted Access, But It Doesn’t Work Yet”
The most common sync-timing symptom is the frustrating one for engineers: the configuration says they have access, but when they try to use it, it isn’t there.
Here’s the sequence that produces it. An administrator makes the right change — adds the user to the correct group, maps the group to the account, assigns the permission set. Everything on the configuration screen is correct. The engineer goes to use their access and finds the role missing from their SSO page, or the request simply doesn’t resolve. Nothing is misconfigured. The change just hasn’t propagated through the next scheduled sync yet.
To the engineer, this looks like a broken tool. To the administrator who just made the change and can see it’s correct, it looks like gaslighting. Both are reacting to the same thing: a correct configuration that hasn’t synced. The fix is almost always “trigger an on-demand refresh” or “wait for the next scheduled sync” — but if you don’t understand the sync model, you’ll spend that waiting period opening support tickets and re-checking a configuration that was right the whole time.
Symptom 2: Permissions That Should Be Gone, But Linger
Sync timing cuts the other way too. When access is removed — a user taken out of a group, a mapping deleted, a permission set withdrawn — that removal also has to propagate. Until it does, the downstream systems may still believe the access exists.
For a security team, this is the more worrying direction. You revoke someone’s access because they changed roles, left a project, or left the company — and for the length of the sync window, the systems downstream of your change may still honour the old state. The gap is usually short and usually harmless, but “usually” is not a word security teams like applied to revocation. Understanding that removal is subject to the same sync cadence as granting is what lets you reason about it: for high-sensitivity revocations, you trigger a refresh rather than trusting the next scheduled run, and you verify the removal took effect rather than assuming the configuration change was sufficient.
Symptom 3: Identity Churn — When the Sync Source Itself Causes Problems
The subtlest category of sync problem isn’t about timing at all — it’s about the sync mechanism changing identities in ways you didn’t expect.
A real-world example: some teams use an open-source tool to sync users and groups from Google Workspace into AWS IAM Identity Center. These tools work well, but under certain conditions a sync can refresh a user’s identifier in Identity Center — effectively re-creating the user from the downstream system’s perspective. Anything that was keyed to the old identifier (including in-flight access grants or tooling that remembers the user by ID) can suddenly behave as though the user is a different person. Access that was working stops working, not because anyone changed a permission, but because the thing the permission was attached to got a new ID underneath it.
This is a nasty failure mode precisely because it’s invisible in the configuration screens. The group looks right. The permission set looks right. But the user’s identity got churned by a sync, and everything downstream that cached the old identity is now pointing at a ghost. Diagnosing it requires knowing that the sync mechanism can do this — which is exactly the kind of plumbing knowledge the real-time mental model hides from you.
Why This Matters More as You Scale
Sync timing is a minor annoyance in a small environment and a genuine operational risk in a large one, for a few compounding reasons:
- Bigger directories mean slower syncs. Reconciling thousands of users and groups takes longer than reconciling dozens. The on-demand refresh you reach for during an urgent change gets slower exactly as your environment gets more important.
- More changes mean more in-flight windows. A large org makes identity changes constantly. At any given moment, more of them are mid-propagation, so the probability that someone is hitting a sync-timing symptom right now approaches certainty.
- Shared organizations multiply the surface. When many teams share one AWS Organization, an unscoped sync tries to reconcile everyone’s identities on every cycle — slowing every refresh and widening the window for everyone. Scoping what synchronises (so a given team’s tooling only reconciles the identities that matter to it) is both a performance fix and a sanity fix.
How to Make the Sync Schedule a Known Quantity
You can’t make identity propagation instantaneous — the architecture is fundamentally eventual-consistency. But you can stop being surprised by it. A few practices turn sync timing from recurring mystery into managed reality:
1. Treat “just configured” and “actually live” as different states. After any identity change, assume it is not effective everywhere until the next sync completes. Build that assumption into your runbooks so nobody declares a change done the moment they click save.
2. Know where the manual refresh is — and its cost. For changes that can’t wait for the scheduled cycle, use the on-demand refresh. But know that in a large environment it isn’t instant; plan for minutes, not seconds, and communicate that to whoever is waiting on the access.
3. Verify, don’t assume — especially for revocations. When you remove access that matters, confirm the removal propagated rather than trusting the configuration change. The sync model means “I deleted the mapping” and “the access is gone everywhere” are two different claims.
4. Scope what synchronises. If your tooling reconciles far more identities than it needs to — because you share a large organization — constrain the sync to the identities that are actually relevant. Smaller sync scope means faster refreshes and a narrower window for every symptom above.
5. Understand your sync mechanism’s quirks. If you use a tool to bridge your IdP and Identity Center, learn what it does under edge conditions — particularly whether it can churn user identifiers. The identity-refresh failure mode is only diagnosable if you know it’s possible.
6. Separate approver configuration from sync state. A frequent false alarm: a request that goes nowhere gets blamed on sync, when the real cause is that the group has no approvers configured. A synced group with no approver is a dead end that looks like a sync problem. Check both.
Where Just-In-Time Access Fits
Just-in-time access doesn’t eliminate the sync model — it rides on the same identity plumbing — but it changes your relationship to it in a helpful way. Because JIT governs access at the identity layer and makes grants explicit, time-bound, and audited, the questions sync timing raises become answerable: you can see when a grant actually took effect, confirm when it revoked, and trace a stale-permission symptom to a specific sync window rather than guessing. And because good JIT tooling supports both scheduled and on-demand refresh with scoped sync, you have the levers to make propagation fast and bounded instead of opaque.
The deeper point is that JIT reframes access from a standing configuration you set and forget — where sync drift accumulates silently — into a lifecycle you observe: request, approve, grant, revoke, each event recorded. In that model, the sync schedule stops being an invisible source of surprise and becomes just another timed step you can see and reason about.
Conclusion
The belief that identity is instantaneous is a comfortable fiction. Underneath every “the user is in the group, so they have access” is a scheduled sync doing eventual-consistency reconciliation between your IdP, Identity Center, and your access tooling. That schedule is why correct configurations sometimes don’t work yet, why revoked access sometimes lingers, and — in its subtlest form — why a sync can churn an identity and break access nobody touched.
None of this is a flaw you can remove. It’s the nature of distributed identity systems. What you can do is stop being surprised by it: treat “configured” and “live” as different states, know where your refresh button is and what it costs, verify revocations, scope your sync, and understand your mechanism’s quirks. Do that, and the sync schedule moves from the list of things that mysteriously break your access to the list of things you simply account for. For teams that want that lifecycle made explicit and observable, JIT access is the layer that turns identity propagation from a black box into a timeline you can read.
