Governing Cloud Identities and Partner Access for Manufacturers

The access problem behind partner visibility

NIST's National Cybersecurity Center of Excellence describes the underlying concern plainly. In its attribute based access control project description, NIST says enterprises rely upon strong access control mechanisms so that resources such as applications, networks, systems and data are not exposed to anyone other than an authorized user. It adds that business requirements change and enterprises need access control that can adapt.

For a manufacturer, ask whether partner access fits this description in your own operation. A customer portal, a supplier portal and an ERP system may each hold records that belong to different parties. The access question is not only whether a person can log in. It is which party the person represents, which records that party may see, and who can change that rule.

Why the constraints are hard

CISA's Secure Cloud Business Applications guidance on hybrid identity solutions explains one source of difficulty. When organizations connect cloud solutions with on-premises systems, CISA says identity management can become significantly more complex. CISA also states that on-premises identity management solutions need to securely and efficiently integrate with cloud-based ones to achieve interoperability. CISA writes for federal agencies, so treat its architecture options as reference material for a manufacturer rather than a directive.

Two distinctions in that guidance are useful to an executive. First, CISA notes that a "user" can be a human or a non-human entity such as an automated administrative service. A governance model that covers only employees will miss the service accounts and automated connections that move data between a portal and the ERP. Second, CISA separates internal users, whose identities originate within the organization's system through a direct relation such as employment, from external users, who may be partners, contractors or other stakeholders. CISA notes those designations are in relation to the system rather than physical location. A supplier's employee is an external user even when working inside your plant.

CISA's guidance also distinguishes authentication from authorization. It describes authentication as the process of verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources. It describes authorization as the process of verifying that a requested action or service is approved for a specific entity. Partner governance has to define both: who someone is, and what that party is approved to do.

Supply chain security guidance adds a contractual constraint. NIST's cybersecurity supply chain risk management publication includes a checklist item to develop roles and responsibilities for suppliers, customers, and business partners to address shared responsibilities for cybersecurity risks and integrate them into policies and third-party agreements. It also lists establishing rules and protocols for information sharing and reporting processes between the organization and its suppliers.

Approaches to compare

The options below are choices to assess, not a ranking. The right one depends on your existing systems, data quality and who must support the result.

Extend the identity arrangement you already have. CISA describes federation, where the agency's user authentication process can continue to take place on-premises when a cloud identity service is federated with on-premises identity management. CISA says this is beneficial when an organization needs all authentication to be kept on-premises or does not want to transmit its authentication policies externally. CISA also says that with this setup each account only needs one record and policy management and logging can be central. The cost to weigh is whether your on-premises directory can reach the cloud applications and partners you now need.

Move toward a cloud-first identity arrangement. CISA's document covers both hybrid models in which on-premises services are primary and ones in which cloud-based identity services are deployed as the primary identity solution. CISA says it recommends agencies plan to migrate to cloud-based passwordless authentication through existing public key infrastructure investments or FIDO2 and the Web Authentication standard. That is a recommendation to federal agencies. A manufacturer would need to judge fit, partner readiness and support effort for itself.

Use attribute-based rules for partner sharing. In its project description, NIST's National Cybersecurity Center of Excellence says that attribute based policy definitions enable enterprises to accommodate a diverse set of business cases. Before relying on this approach for partner sharing, ask whether the attributes you would use, such as company, role or site, are accurate in your source records.

Contract and governance controls alongside technology. The NIST supply chain checklist includes security requirements for suppliers commensurate with their criticality and potential impact if compromised. It also lists defining security requirements in service level agreements for monitoring suppliers. Decide which partner duties belong in agreements and which you will enforce through access settings.

No platform change. Keeping the current setup is a legitimate choice when partners already receive adequate information. Test it against the symptoms of manual status reporting and permission risk in your own operation before concluding that change is needed.

Tradeoffs to weigh

Every option trades effort against control. Ask where credentials and policy would sit under each option you are considering. Attribute-based rules add flexibility, and they depend on the quality and ownership of the attributes that drive decisions. Hybrid identity, per CISA, will result in a future state in which agencies must securely architect, deploy, maintain, and update both on-premises and cloud identity services. In other words, ongoing support does not disappear when identity moves to the cloud.

Data ownership is a related tradeoff. In a NIST case study on supply chain traceability, the organization DUST Identity says it often sees the best solution as the creators of the data owning their data and monetizing access to that data by other parties. That is one company's view in a blockchain traceability context, and NIST states such perspectives are the authors' views. It does show that who owns a record should be decided before the access model is built.

Separating provider, platform and business responsibility

The guidance cited here does not allocate duties between a cloud provider and a customer, so settle that split in your contract and architecture review. We recommend writing down, for each system in the partner path, which tasks the provider performs and which remain yours. Assume that identities, configuration, data and application controls are yours until an agreement says otherwise.

A practical sequence for owners and executives

1. Inventory identities. List employee, partner and automated identities that touch the cloud platform, ERP, customer portal and supplier portal. Include service accounts and integrations.
2. Define party and record boundaries. For each portal, state which party may see which records, and which record source feeds it. Decide whether the ERP or another system is the record authority for each item; do not assume.
3. Set least-privilege roles. Give each role only the access its work needs. Require a named approver for privileged changes, and define how access is revoked when a person or contract ends.
4. Decide what evidence you need. Specify which actions the audit log must record and who reviews it, and how often.
5. Assign decisions to people. Name who escalates an incident, who runs access reviews, who approves recovery steps and who accepts a change as complete. Business leaders keep that authority; the platform records and enforces decisions, but does not make them.
6. Write partner duties into agreements. Use the shared-responsibility and information-sharing items above as a starting list.
7. Start narrow. Pilot one customer or one supplier before widening, and check data quality in the portal against the ERP before adding parties.

If your internal team lacks capacity for the identity design or portal integration, treat that as a staffing and scoping decision to make explicitly, rather than letting access rules emerge from whatever each tool permits by default.