TL;DR
Lab, clinical, quality, manufacturing, and diagnostic applications may not expose the interfaces needed for standard identity automation. A controlled execution layer can extend approved IAM and IGA workflows through APIs or managed UI automation, but each application requires explicit scope, testing, verification, exception handling, and change control. Automation should support the organization's regulated processes, not replace them.
Why are critical applications at pharmaceutical, medical device, and diagnostics companies still outside standard access controls?
Where identity changes still rely on manual execution, the issue extends beyond technical debt. It creates a control dependency that becomes harder to govern as applications, users, and operational requirements grow.
Across pharmaceutical, medical device, and diagnostic environments, identity work can span laboratory systems, clinical applications, quality platforms, manufacturing tools, diagnostic systems, and the business applications around them. Some support modern identity standards. Others offer only local administration, a limited API, or no user-management interface beyond the application UI.
That creates a specific engineering problem. The identity program can define the right account and role state, but it cannot automatically apply that state to the application. The default bridge becomes a ticket, spreadsheet, script, bot, or administrator. The goal is not automation at any cost. It is controlled execution that preserves policy, produces evidence, and behaves predictably when the application changes.
SCIM is useful, but it is not the only execution path
SCIM gives identity platforms a standard way to create, update, and deactivate users and groups. When an application implements it well, you should use it. The problem is that many important applications do not support SCIM, expose only part of the required lifecycle, or provide no user-management API. Waiting for every vendor to add a standard interface leaves the manual process in place.
An organization can still govern a non-SCIM path if it separates policy from execution. The IGA or IdP determines the approved action. The execution layer carries out that action through the best supported interface, then verifies and reports the result. That model keeps the identity system authoritative without requiring the application to become a modern identity client.
UI automation changes the connector design
Traditional connectors depend on a documented API or standard endpoint. UI automation uses the same administrative controls a person would use. This expands the set of reachable applications, including apps with no API, but it also creates different engineering obligations. The automation must reliably identify controls, handle navigation and multi-step flows, protect administrative credentials, and detect interface changes.
Cerby describes managed connectors that combine APIs and patent-pending UI automation, with drift detection and repair capabilities for changing interfaces. The relevant claim is that the platform is designed to maintain supported workflows as applications change. It is not a claim that every interface change can be repaired without review or that every application is automatically in scope.
A controlled workflow needs more than a successful click
For each application, the control design should define the identity event, policy source, target object, allowed action, expected state, verification method, evidence, and failure path. That is especially important where the application participates in a regulated or validated process.
- Scope the exact user, role, group, permission, credential, or session action.
- Require the same approvals the organization uses today; automation should not bypass policy.
- Use least-privilege administrative access and protect any service or shared credential.
- Capture pre-change and post-change state where the application permits it.
- Define deterministic success criteria and route ambiguous outcomes to human review.
- Version, test, and approve workflow changes under the organization's applicable change-control process.
- Retain logs in the systems and for the periods the organization has approved.
How Cerby works with IAM and IGA
Cerby acts as an execution and augmentation layer for supported disconnected apps. It can listen to approved lifecycle events from existing identity systems, create or disable accounts, update roles and groups, rotate credentials, and send user, entitlement, and completion data back to the governance platform. For on-premises browser and thick-client applications, Cerby's current materials describe an on-premises agent as the connectivity path.
This architecture avoids duplicating governance logic. The existing IGA remains the place for access requests, certifications, policy decisions, and remediation instructions. Cerby supplies application coverage and execution where native integration is absent.
Regulated context changes the implementation, not the need
A regulated environment does not make manual identity work inherently safer. It does make scope, testing, documentation, traceability, change control, and operational ownership more important. An automated workflow should be evaluated within the organization's own quality and validation framework where applicable.
Cerby should not be positioned as a blanket GxP, FDA, or regulatory compliance guarantee. The defensible product statement is narrower: for supported applications and workflows, Cerby can automate identity actions, return access data and completion status, and produce centralized logs. The organization determines how that capability fits its controlled process.
Evaluate one workflow end to end
Choose a bounded workflow with a clear owner and measurable manual burden. A role change is often more informative than a simple new-account flow because it tests identity mapping, entitlement logic, removal of prior access, assignment of new access, verification, and evidence.
Run the current and proposed paths side by side. Record approvals, execution time, wait time, error handling, evidence, and behavior after an application-interface change. That produces a technical basis for expansion without assuming every lab, clinical, quality, manufacturing, or diagnostic application behaves alike.