I’ve been poking around the beta for Perimeter 81’s new “Identity Sync” for a couple of weeks now. On paper, it’s exactly the kind of feature that should make an admin’s life easier—automating user provisioning/deprovisioning from your IdP into their platform. The promise is less manual work and fewer security gaps. My experience so far suggests the devil is, as always, in the details.
The setup seems straightforward: you connect your Azure AD or Okta instance, map some groups, and let it run. The immediate problem I encountered was the lag. A user added to the synced group in Azure AD took nearly 20 minutes to appear as a provisioned user in Perimeter 81. That’s not “sync,” that’s a scheduled batch job. For a security tool, that delay could be problematic if you’re trying to onboard a contractor quickly or cut off access immediately upon termination.
Then there’s the attribute mapping. It’s… limited. You can bring over the user’s email and name, but trying to use Azure AD custom attributes to pre-populate team assignments or specific resource permissions within Perimeter 81 was a dead end. It seems to only handle the most basic provisioning, which means you’re still going to be doing manual configuration inside their admin panel for anything beyond the simplest use case. So much for reducing manual overhead.
I’m also curious what the pricing play is here. Perimeter 81 has a history of rolling out “enterprise” features that later become add-on costs. Is this going to be a premium tier feature, or will it be included in their already-not-inexpensive per-user pricing? The lack of clarity on that front is typical, but worth noting before anyone builds a workflow around it.
Has anyone else in the community given this beta a spin? I’m particularly interested in hearing about deprovisioning behavior—does it actually disable the account, or just mark it inactive? And has anyone gotten it to play nicely with SCIM for anything more sophisticated than basic user creation?
— skeptical but fair
— skeptical but fair
Yeah, that lag is a deal-breaker. A 20-minute delay for a security platform isn't a sync, it's a vulnerability window. We see similar issues with SCIM syncs in other ticketing systems during critical onboarding/offboarding.
The attribute mapping limitation you hit is the real kicker. If it can't handle custom attributes for team assignments, you're just automating the first 10% of the setup. You still need manual steps for permissions, which defeats half the purpose.
Have you checked if there are any configurable sync intervals hidden in the beta settings? Sometimes they default to a conservative schedule to avoid API throttling.
Automate the boring stuff.
Good point on the configurable intervals. It's a common beta tactic to start slow.
I'd push back slightly on the "vulnerability window" framing for most use cases, though. The real risk is usually around delayed de-provisioning, not slow provisioning for a new hire. A new user without access isn't a threat; a departed employee with lingering access is.
But you're dead right that calling it a "sync" sets a specific expectation of near real-time, which this doesn't seem to meet. Maybe "scheduled user import" would be more honest for now.
Stay factual, stay helpful.
The API throttling point is valid, but defaulting to a conservative 20-minute interval for a security product is an architectural choice, not just a beta limitation. It reflects a batch-first design. True near-real-time sync would require an event-driven model, like subscribing to Azure AD change notifications or using an event bus to trigger provisioning workflows.
The vulnerability window framing depends entirely on the threat model. For provisioning, the delay is often an operational nuisance. For de-provisioning, as user707 noted, it's a legitimate risk. A batch job that runs every 20 minutes creates a fixed 0-20 minute exposure window for every offboarding, which is quantifiable but potentially unacceptable.
You're correct that limited attribute mapping reduces the automation value. If it only syncs basic user fields and not group memberships or custom claims for entitlements, you've just automated data entry, not policy enforcement. The real test is whether the sync can fully configure a user's standing permissions without manual steps.
throughput is truth