OEM Factory Certificates for Tenancy Management

Andi Lamprecht ·2026-05-11· 6 min read· Draft

Decision Log

• Organization and Tenancy Concept approved by CCB on 2025-09-24
• Requirements approved by CCB on 2025-10-10
• Planning approved by CCB on 2025-10-10
• Testing approved by CCB on 2025-10-17
• Release (Stg) approved by CCB on 2025-10-17

Problem Statement

Currently, there is no tenant separation for operators and OEMs for their UAVs. All connected and trusted vehicles share the same public certification and are visible to all users across all tenants. This presents a critical issue for the planned onboarding of OEMs and UAVs for their 44807 testing and operations.

• Security and Data Integrity: DroneUp and Blueflite vehicles and operational data would be exposed to each other.
• Operational Conflict: Blueflite cannot conduct its testing without inadvertently exposing its vehicles and information to other users, which violates the fundamental need for tenant separation.

The immediate need is to ensure UAV visibility is restricted to the correct tenant which is associated to a unique identifier and create a logical separation between tenants.

Importance of Solving the Problem Now

We need to separate Blueflite’s UAVs and data from DroneUp’s UAV data via logical separation without incurring a large amount of technical debt. This is currently not the case as all vehicles share the same public certification and show up on the same list, regardless of the tenant. This is a hard blocker for the current integration as well as the future multi-OEM strategy.

1. Enabling Blueflite Onboarding and 44807 Testing

The primary driver is the need to onboard Blueflite as an OEM. We will not allow them to proceed with their required 44807 testing and learning of Uncrew until they can connect their vehicles to a tenant that is logically separated from DroneUp operations. The problem must be solved before they can begin their work.

2. Maintaining Security and Data Separation

Currently, all connected vehicles are visible across all tenants due to shared certification. This is a security and data integrity risk. Solving this immediately is necessary to:

• Prevent Blueflite from viewing our sensitive operational data and vice versa.
• Ensure that the OEM testing and validation data is isolated and protected.

Why Should the Business Pursue This?

• Based on the strategic decision to integrate Blueflite, support multi-organization OEM and operator functions, this allows us to implement a trust-based model on OEM factory certificates in the near future.
  • Note: this should not be considered the long-term strategy without more analysis.
  • The core of this plan is to associate each UAV’s factory-installed digital certificate with its manufacturer’s organization ID (unique identifier) within the Uncrew platform.
• This work is critical for satisfying DO-178C objectives related to software requirements and design, ensuring the system behaves as intended in a multi-tenant environment.

Requirements

Product Requirements

• Configure Tenant Data Segregation — The system shall ensure that all data belonging to one tenant organization that is not shareable is logically segregated from all other tenant organizations.
• Support OEM Tenant Account Creation — When an authorized user initiates OEM tenant creation, the system shall allow the creation of a new tenant organization designated as an ‘OEM type’ with appropriate basic access. (Rationale: this is part of a future iteration.)

System Requirements

• Tenant Data Isolation — The system shall be architected for multi-tenancy, ensuring strict logical and data isolation between tenants across all services, databases, and storage layers.

High and Low Level Software Requirements

Inventory Service

The Inventory Service shall support the logical separation of vehicles by distinguishing between tenant associations:

• An Uncrew internal OEM unique identifier field must be added to track the organization that manufactured the drone and owns the certificate.
• The Uncrew internal operator unique identifier field shall be used to identify the specific tenant that is currently authorized to actively operate the UAV.

New Factory Certificate Creation and Management

• A new dedicated factory certificate shall be created for a new OEM, and the unique identifier for the new OEM must be securely bundled inside the new certificate details.
• The Inventory Service shall support new factory certificates and correctly parse it to determine the drone’s initial OEM tenant association upon connection.

Visibility and Access Control

• Inventory Service API shall filter the list of visible UAVs based on the requesting user’s tenant ID against the Operator Tenant ID in the Inventory Service.
• Connecting a UAV using a certificate shall result in a registration request appearing on the UI of the corresponding OEM tenant.

Drone Movement / Assignment

• A back-office or administrative process will be used to manually update the Operator Tenant ID for a specific UAV from one tenant to another.
  • Note: This is a short-term solution until there is a more formalized process in place.
• Moving a drone between operators shall not require a new onboard artifact on the physical drone.

Risks

• The current factory certificates are created with a one-year expiration date, and there is no automated rotation or renewal process. When the certificates expire, all connected vehicles will lose the ability to communicate with the network.
• The immediate solution requires manual back-office support to transfer a drone from one tenant to another. This manual process is not scalable and will become a bottleneck as the number of OEMs and operators increases.
• This scope does not contain an answer to OEM certificates for M&A.
• Although we want OEMs to observe their drones across the entire fleet, and the plan separates operational control, there is still no RBAC for access to drones. The OEM will still have access to all of their drones. Future work will need to limit what the OEM can do to avoid exposing sensitive flight data.
• There is a dependency on Frontegg. If we want to migrate away from it in the future, this needs to be addressed for long-term scalability. There is assumed to be enough time to build a translation layer before this becomes a problem.
• UAV IDs/names are not restricted to be unique across tenants. A fast follow should include Uncrew providing the uavID.

Alternatives Considered

• Temporary API Endpoint for Manual Movement — Create a temporary endpoint in the Inventory Service that allows an authorized user to manually move a UAV between tenants. The user would provide the uavID and the target unique identifier. Although a quick temporary solution, it is very manual and not scalable as it would always require support from DroneUp every time an OEM needs to add a new UAV or transfer to an operator.

Planning

• Based on initial engineering evaluation of requirements, the LOE for this scoped work is estimated to be 1 week.
• At least 2 Jira stories would be required: one to update the Inventory Service and another to create a new onboard artifact with new factory certificates.