Why does the independence of data sources call for a robust IAM system design, and what does robust mean in practice?

Because the source is autonomous, the IAM can be forgotten when it changes; a robust IAM tolerates missing, empty, malformed or suddenly changed deliveries without wrongly deleting identities or locking people out.

A data source is run by someone else, for their own purposes. However good the change management, sooner or later a delivery will be missing, empty, in a new format or full of unexpected values. The question is what the IAM does then. A naive design trusts every delivery: an empty HR file means "everyone has left", so it deactivates every account in the company overnight.

Robust design means, for example:

• Plausibility checks before applying a delivery: record counts, mandatory fields, value lists.
• Deletion thresholds: if a delivery would deactivate more than a set number of identities, stop and ask an administrator instead of executing.
• Grace periods: a person missing from one delivery is flagged, not immediately deleted.
• Monitoring and alerting on missing or late deliveries.
• Loose coupling: the IAM keeps working on its last good data if a source is temporarily unavailable.

These measures turn a source failure from a company-wide outage into an alert someone handles in the morning.

Go deeper:

• Microsoft Entra: accidental deletions prevention — a real deletion threshold that pauses provisioning when a sync would remove too many accounts.
• Robustness principle (Wikipedia) — the classic design rule for systems that consume input from others, and its known pitfalls.