How to Govern Applications Without SCIM or Provisioning APIs

You do not need SCIM to govern an application. You need a clear read path, a clear change path, and disciplined control over approval, fulfillment, and verification. Governing applications without SCIM is entirely achievable; what changes from one target to the next is the mix of connector automation and governed manual fulfillment. For a CIO or Head of IT, that is the lever that cuts service-desk work and closes offboarding gaps without forcing the replacement of a business-critical application.

Citadel Identity360, from Astranova Labs, is built for exactly these applications. Its connector framework goes well beyond SCIM—REST, SOAP, LDAP, JDBC, flat files, SFTP, scheduled batch, mainframe, and custom connectors—so the legacy, in-house, and vendor applications that never shipped a provisioning API still come under central governance. Where a target accepts writes, Citadel provisions and revokes directly. Where it does not, Citadel runs governed manual fulfillment: a tracked task to the accountable administrator, a due date, and verification evidence read back from the target. Configuration is no-code-first, and the estate-specific work—schema mapping, file layouts, a custom connector for an in-house system—fits inside roughly 400 hours of included customization.

The six steps below show how Citadel takes an application without SCIM from unknown access to verified, certified, audit-ready governance.

Step 1: Inventory the application and set its Citadel control level

Start by identifying what the application actually supports. Citadel onboarding captures the business owner, the technical owner, who can grant access, the authoritative source of workforce status, which roles or permissions are sensitive, whether access is inherited from a directory or local to the application, and how account data can be extracted.

The key question is simple: can you read the account state, and can you write changes back? Those are different capabilities, and Citadel records them separately in each application’s connector configuration—read, write, and verify. A directory connection may show membership without the application accepting role changes through that same path; the same distinction applies to JDBC, file feeds, and administrator exports. Making it explicit from day one means coverage is never assumed.

Citadel assesses the read path in this order:

1. Existing Citadel connector (REST, SOAP, SCIM, or LDAP)
2. Directory or database interface over LDAP or JDBC
3. Scheduled flat-file export delivered over SFTP or batch
4. Administrator-produced export ingested through Citadel’s file connector
5. Owner attestation captured in Citadel where technical data is not yet reliable

For the change path, Citadel tests each option in turn: connector writes, approved file or batch imports, directory writes, a mainframe interface, custom connectors, or governed manual fulfillment. Custom connectors and SQL write-backs pass through security review and are built within the included customization scope, so automation lands where it is safe and maintainable, and every other change is still governed.

Common interface patterns and what Citadel automates

Available interface	What Citadel Identity360 automates	How Citadel governs the remaining step
Account or entitlement export, such as CSV, over SFTP or batch	Import, correlation, exception detection, review campaigns, workflow, evidence	Feed-health monitoring; target-side changes routed as tracked tasks unless the application accepts a supported change file
JDBC-accessible tables	Account and entitlement reads; reconciliation of observed state	Schema mapped once in no-code configuration; write-back delivered as a reviewed custom connector where the vendor supports it
LDAP-backed identities or groups	Directory reads and, where permitted, directory group changes	Local application permissions mapped and governed alongside directory-derived access
Mainframe or in-house application	Reads and writes through mainframe or custom connectors built within roughly 400 hours of customization	Connector ownership and change control tracked in Citadel
No dependable machine-readable interface	Requests, approvals, fulfillment tasks, escalation, certifications, documented exceptions	Administrator performs the grant or removal; Citadel captures verification evidence and owner attestation

Citadel is built for this model: one governance layer across flat files, SFTP, batch, JDBC, LDAP, mainframe, and custom connectors, with the same decision, owner, and evidence trail whether the final step is automated or manual.

Step 2: Establish a dependable account and entitlement feed

If the application can produce a file export, make that export dependable before anything else. Agree with the application owner on what the export represents and how often it is produced. At minimum, Citadel’s file connector expects a stable account identifier, account status, login, owner or correlation attributes, role or entitlement values, extraction time, and a marker that distinguishes a full snapshot from a partial export. File layouts are mapped through no-code configuration, so a new column or a renamed field is an administrator change, not a development project.

Do not silently exclude privileged accounts or service accounts; they matter most from a risk perspective. Define up front how null values, duplicate identifiers, renamed users, multiple roles, and departed staff are handled. Citadel applies those rules on every import, so the governance workflow never inherits ambiguity from the source system.

For transfer, Citadel ingests over SFTP or scheduled batch with an access-restricted drop location, protection in transit and at rest, validation of file structure and record counts, and alerts on stale or failed feeds. Those safeguards matter because a missing or truncated snapshot is not an instruction to remove every absent account. Citadel’s feed validation flags a short or failed file for review rather than processing absent records as removals.

If the source is JDBC-based, Citadel maps the tables or views that represent accounts and entitlements, uses stable identifiers and change timestamps where the source provides them, and runs on a read-only credential. Reading a database is not the same as provisioning, so Citadel never writes to undocumented application tables; write-back, where the vendor supports it, is delivered as a reviewed custom connector.

If the source is LDAP-based, Citadel’s LDAP connector is configured with the directory, search base, user and group object classes, membership attributes, identity-matching keys, and separate permissions for import and for provisioning. Onboarding also verifies whether the application’s authorization model actually derives access from the directory objects being read, so directory-derived and locally granted access are each governed correctly.

For mainframes and other long-lived systems of record, Citadel’s mainframe and batch connectors bring account and entitlement data into the same model, so the oldest systems in the estate are no longer the least visible.

Step 3: Match observed accounts to accountable identities

Once account data flows, Citadel correlates each account to a known employee, contractor, or other accountable identity using reliable identifiers. An email string is never assumed to be unique or current.

This is where many programs quietly fail. An unmatched account is not automatically malicious, but it is never safe to ignore. Citadel’s identity graph links every account to the person or workload behind it and gives service, shared, privileged, and other non-human accounts a separate path, so each one has an accountable owner and a documented purpose. Contractors run on Citadel’s contractor lifecycle, with sponsors and end dates, so accounts created for a temporary engagement do not outlive it.

Citadel surfaces these conditions first:

• Uncorrelated accounts
• Accounts attached to departed people or expired contractors
• Unexpected privileged grants
• Identities whose access does not fit their current role, flagged by SoD and risk scoring

When many accounts come back unmatched, check the matching rules before jumping to conclusions. Misspelled attributes and earlier incorrect mappings create correlation errors, and in Citadel those rules are adjusted in no-code configuration and re-run immediately. The goal is not merely “find accounts,” but “find accounts that can be defended in audit and actioned in operations.”

Citadel turns that into an operating queue rather than a spreadsheet exercise: one identity graph across every connected and disconnected application, with risk scores that tell owners which exceptions to resolve first.

Step 4: Route access requests through governed fulfillment

Govern every request even when the target cannot be changed automatically. Citadel captures the requester, beneficiary, application, requested entitlement, business justification, decision maker, approval or denial, assigned fulfiller, and resulting status, and applies application-owner and separation-of-duties checks according to policy before anything is granted.

For a joiner, Citadel requests the right role. For a mover, it defines both the new access and the access to remove. For a leaver, it initiates removal immediately and tracks every outstanding application task until each one is verified closed.

When the target lacks a usable change interface, Citadel assigns a fulfillment task to the application administrator with the specific account, the requested action, and a due time. The administrator makes the change through the approved procedure and records completion in Citadel, which then verifies the result against the target. That is governed manual fulfillment: the same policy, approval, and audit trail as an automated grant, applied to a system that has no API.

This is where Citadel separates itself for organizations with legacy systems. It coordinates the decision and the task even when the target-side work is manual, so service-desk follow-up drops, approvals are standardized, and the record is complete without waiting for every application to support direct provisioning.

Where the application supports a vendor-approved batch import, a directory update, or Citadel custom connectors, grants and removals move from task to automation. Citadel establishes that capability target by target and promotes each application as its change path is proven, so automation grows without any gap in governance.

Step 5: Verify fulfillment and keep the audit trail separate from the request

A completed ticket is not proof that the target changed. After each grant or removal, Citadel obtains a fresh target export, JDBC query, directory read, or independently reviewed administrator evidence and reconciles actual access against the approved outcome.

Citadel records:

• The request and approval
• The target action
• The actor
• Timestamps
• Verification result
• Any unresolved exception

Where the target cannot yet provide repeatable evidence, Citadel applies compensating controls: application-owner attestation, sampled administrator evidence, a second-person check for sensitive removals, automatic escalation of overdue actions, and an exception register with an owner and review date. Each is materially stronger than assuming a manual change happened because someone closed a ticket, and Citadel keeps them in the same evidence chain as direct target readbacks.

Prioritize leaver and privileged-account exceptions. Citadel’s risk scoring sets the order, and review intervals and service levels are configured per application to match its risk and your internal policy.

Citadel’s strongest advantage here is evidence continuity. It retains the request, approval, task assignment, fulfillment record, and the follow-up verification needed for audit readiness. That is the difference between “we think it was removed” and “we can show what happened.”

Step 6: Run recurring certifications and expand automation over time

Once the flow is in place, Citadel runs recurring access certifications. Reviewers see the person or account owner, application, observed permissions, business purpose where known, last reliable observation, earlier exceptions, and the SoD and risk context for each grant. Revoke decisions flow straight into tracked change tasks, and Citadel verifies that the next target observation reflects the removal.

Citadel also triggers event-based reviews when an employee transfers, departs, changes owner, or is found to hold newly privileged or unowned access. A scheduled campaign alone will not catch those events in time.

The management measures Citadel reports are operational, not cosmetic:

• Percentage of in-scope applications with an accountable owner and a usable access feed
• Feed age and failed-import count
• Proportion of accounts successfully correlated
• Unresolved and overdue manual fulfillment tasks
• Time from departure notification to verified target removal
• Percentage of revoke decisions verified in the target

Those metrics show whether governance is improving and where to invest next.

The improvement path in Citadel is clear: stabilize exports and manual evidence first, then move each application onto a directory operation, a vendor-approved import, or maintainable custom connectors as soon as that path is proven. Because configuration is no-code-first and connector work fits inside roughly 400 hours of included customization, every step toward automation reduces fulfillment effort without adding an open-ended services bill.

Why Citadel Identity360 is the right fit for applications without SCIM

Citadel Identity360 is not limited to a single integration style. Its connectors span REST, SOAP, SCIM, LDAP, JDBC and SQL, CSV and other flat files, SFTP and scheduled batch feeds, mainframes, enterprise and SaaS applications, and custom patterns—so every application in the estate has a governed path, whether or not it has a provisioning API.

For connected applications that support lifecycle actions, Citadel provisions and revokes directly. For batch-file and manually administered legacy systems, it still governs the access decision, assigns and tracks the task, verifies the outcome, runs certification, and preserves evidence. You get control over the applications that run the business without replacing them first.

The same model extends to non-human identities. Service accounts and AI agents are owned and reviewed alongside people in the identity graph. For agents, Citadel provides MCP server and agent registration, accountable ownership, tool-level authorization, and a kill switch for immediate revocation. Citadel’s AI governance also produces a governed MCP access configuration file that agent platforms and MCP clients can consume.

Citadel also delivers the operating model CIOs and Heads of IT need: centralized ownership, no-code-first workflows, SoD and risk scoring, audit-ready evidence, and a path to automate more of each application as its change path is proven.

Closing the governance gap with Citadel Identity360

The conclusion is simple: the absence of SCIM rules out one integration method, not accountable governance. Governance succeeds when you can say who has access, who approved it, who must change it, and how the completed change is verified.

That is what Citadel Identity360 delivers. It governs applications without SCIM by matching each one to the right connector—JDBC, flat file, SFTP, batch, mainframe, or custom—and by running governed manual fulfillment with verification evidence wherever a direct write is not available.

To start, pick one high-risk application and map its read path, change path, owner, and verification path in Citadel. Then request a Citadel Identity360 demonstration against it: one file or JDBC feed, one unmatched account, one leaver carried through a manual fulfillment task, and one verified removal.

FAQ

Can an application be governed without SCIM?

Yes. Citadel Identity360 ingests its accounts through JDBC, flat files, SFTP, batch, LDAP, mainframe, or custom connectors, matches them to owners in the identity graph, and governs them through approvals, certifications, and tracked fulfillment. Where the target needs a manual change, Citadel assigns it, tracks it, and verifies it.

Does importing a CSV provision or remove users?

Not by itself. A file export supplies observed state. Citadel uses it for correlation, review, and verification, and pairs it with a supported inbound change file, a custom connector, or a governed fulfillment task to make the change.

Does LDAP or JDBC make a legacy application fully automatic?

Not on their own. LDAP can manage relevant directory objects, and JDBC can expose database records. Citadel configures read and write permissions separately for each, verifies the application’s actual authorization model, and covers anything those interfaces cannot change with a custom connector or a governed fulfillment task.

How can IT prove a leaver was removed when an administrator did it manually?

Citadel keeps the approved removal request and the fulfillment record, then verifies the target with a subsequent export, directory read, or other independently reviewed evidence. Any unverified or overdue removal is escalated automatically rather than treated as closed.

How much customization does a disconnected application need?

Most applications are onboarded through no-code configuration of existing Citadel connectors. Estate-specific work—file layouts, schema mapping, or a custom connector for an in-house system—fits inside roughly 400 hours of included customization.