A delivered software archive does not settle who owns the access needed to operate it. For a UVH-PNP ground-side integration project, agree who provisions secrets, who authorizes access and who can revoke or replace that access after handover. Keep live credentials out of ordinary project archives and demonstrations. Ask for a secret-free responsibility record, then have the authorized engineering and security teams define the actual implementation.

The commercial problem is easy to overlook: the supplier can demonstrate an application, the source files arrive, and the buyer considers the work complete. Yet the account behind an external service may still belong to an individual, and nobody has agreed who handles the next access change. A successful demonstration is not evidence that the buyer has accepted operational ownership.

Scope this discussion to ground-side software

This article concerns procurement of separately specified software integration around a project, such as a ground-side data workflow or supporting service. It is not an instruction to alter flight-control software, recover credentials from a device or bypass an access restriction. Changes to real systems should follow the owner's authorization and the applicable engineering process.

The UVH-PNP product page identifies the modular platform for a configuration inquiry. It does not establish that a particular cloud account, software service, security feature or support arrangement is included. First confirm whether the contemplated ground-side integration is part of the proposed purchase at all. Do not turn a kit inquiry into an assumed software-service commitment.

Where the integration is included, list its boundaries. Identify which systems belong to the buyer, which remain with a supplier and which depend on another provider. The purchasing team needs a clear ownership map before it can compare commissioning and support terms. It does not need the actual secret values to perform that review.

Use security guidance as a starting point, not a certificate

The OWASP Secrets Management Cheat Sheet discusses controlled storage, provisioning, auditing and rotation of secrets, and the risks associated with credentials embedded in code or configuration. Its subject is a lifecycle, not merely a field in a handover form.

OWASP's guidance does not certify the proposed integration or prove that a platform supplies these controls. The questions below are original editorial procurement recommendations based on that general distinction. A qualified team should select the appropriate implementation for the actual systems, threat model and operating responsibilities. A completed checklist is not a substitute for a security assessment.

Assign responsibilities without exposing values

Create a responsibility record that names roles and assets without including passwords, tokens, private keys or recovery codes. A buyer can review who approves an account, who provisions access and who handles an incident without seeing a production credential in a shared spreadsheet. Ask the supplier to demonstrate that distinction in its proposed handover material.

The roles may be held by a small number of people in a small organization. That does not remove the need to distinguish the responsibilities. An individual can be both project manager and account administrator, but the handover should still say which decisions belong to each role and who provides cover when that individual is unavailable.

Record unresolved ownership as an open item rather than assigning it informally to whoever performed the demonstration. If a third-party service is essential, obtain its commercial and access requirements through the authorized owner. Do not let a supplier's temporary development arrangement quietly become the customer's permanent production dependency.

Separate the software package from the access handover

Ask for a package manifest that identifies the software and its supporting documentation without exposing secrets. Then ask for a separate description of the approved access handover process. The purpose is not to prescribe a particular vault or vendor. It is to make clear that source delivery and operational access are different acceptance items with different handling requirements.

The purchasing reviewer should be able to see which work is included. For example, the quote may include initial commissioning but exclude ongoing account administration. It may include documentation but require the buyer to provision its own service account. Those arrangements can be reasonable when stated clearly; they become troublesome when everyone assumes someone else owns the task.

Also distinguish possession of source code from permission to use connected services. A buyer may receive a complete archive while still needing a separately approved account or commercial agreement. Ask the supplier to identify those dependencies before purchase. Do not request another customer's credentials or assume that a supplier can transfer access it does not own.

Test the process with synthetic evidence

A handover rehearsal can use a dedicated, authorized test environment and synthetic values. Ask the technical team to demonstrate the agreed sequence without using a live production secret in slides, screenshots or a broadly shared document. The procurement objective is to confirm that roles, instructions and evidence are understandable, not to expose the sensitive material itself.

Have the buyer's nominated administrator participate. That person should be able to explain what they will own after acceptance and where approved instructions are stored. The supplier should identify which steps require its involvement and which are the buyer's responsibility. Record any unresolved prerequisite rather than declaring the process complete because the supplier's laptop connected successfully.

Agree what the rehearsal does not prove. It may demonstrate the documentation and ownership process without validating every production security control or failure condition. The technical team should define any separate assessment required. Procurement should retain the scope of the exercise so that a limited rehearsal is not later described as a full security audit.

If the demonstration fails, preserve a secret-free record of the issue and assign it to the responsible team. Do not repeatedly change production settings to make a sales demonstration pass. A planned acceptance process should have a clear stop condition, an escalation contact and a route for reviewing proposed changes before they affect real operations.

Prepare for the supplier's departure

Consider a hypothetical project in which a contractor has completed a ground-side application and is leaving the engagement. The application still depends on an account administered by that contractor. The buyer has the code but no agreed ownership transition. This is an editorial example of an incomplete handover, not a reported event involving a UVH-PNP customer.

The useful response is to compare the actual arrangement with the contract and have the authorized owners agree a transition. Do not assume that copying a configuration file transfers an account or resolves every permission issue. Identify the service owner, the commercial terms and the security review needed for the specific change.

Before the engagement closes, document who confirms the transition and where its evidence will be retained. The supplier may still need limited support access under an agreed arrangement, or access may end entirely. The contract should describe that outcome and its review owner. Avoid vague language that leaves the buyer dependent on an unnamed former contractor.

For recurring support, define how a new administrator learns the process. A named shared role with maintained instructions is more durable than a private conversation. Keep the record current when service ownership changes, while ensuring that the ordinary project file remains free of live secret values.

Connect access ownership to other acceptance questions

The UG73 guide to hosted COG delivery illustrates a related boundary: a usable file and a usable delivery endpoint require different evidence. When a project depends on hosted data, account ownership should be visible alongside file and endpoint responsibilities. That connection does not imply that the same software is supplied with both aircraft platforms.

The UIV2200 calibration-scope guide addresses another form of scope matching. A broad label, whether accreditation or complete handover, should be translated into the specific activity being purchased. The evidence differs, but the buyer's discipline is similar: identify the claim, its owner and the record that supports it.

Request a bounded integration quotation

Keep the acceptance record separate from marketing assurances. It should identify the reviewed arrangement, the people who approved it and any outstanding exclusions. A later expansion to a new service or site needs its own ownership review rather than inheriting approval simply because the project uses the same software name.

Describe the ground-side workflow, the intended system owners and the support period you need. Request a secret-free responsibility matrix with explicit inclusions and exclusions. Ask which commissioning tasks are separately priced and which prerequisites the buyer must provide. Do not send live credentials with an initial product inquiry.

Review the VTOL and fixed-wing drone collection, then contact UNITED UAV about the UVH-PNP platform and proposed integration scope. A useful answer should separate hardware availability from software development and access administration. The objective is a handover the buyer can own, not an archive that works only while the original supplier remains available.