Specification: BetterFleet OCPP Profile 3 and ISO 15118 Certificate Lifecycle Management¶

TLDR (Solution Summary)¶

• Build a single BetterFleet certificate lifecycle capability that manages charger, EVSE, vehicle, and provisioning certificate records with one canonical inventory, status model, and audit trail.
• Extend Certificate Inventory from the existing IoT hub pattern to charger identity certificates, vehicle VAS identity certificates, ISO 15118 provisioning artifacts, and trust anchor bundles, so every managed certificate purpose is visible and governable in one place.
• Add Operator Certificate Administration View that exposes the new certificate purposes through one operator-facing inventory and action surface, so rollout, renewal, and incident handling remain operationally manageable.
• Add Certificate Lifecycle Service commands for issue, install, activate, deactivate, renew, revoke, and delete, so OCPP Profile 3 and ISO 15118 flows reuse the same operational model already familiar from IoT hub management.
• Add OCPP Certificate Orchestration for SignCertificate, CertificateSigned, InstallCertificate, GetInstalledCertificateIds, DeleteCertificate, GetCertificateStatus, Get15118EVCertificate, SecurityEventNotification, GetLog, and LogStatusNotification, so charger and EVSE interactions align to OCPP 2.0.1 responsibilities.
• Add Profile 3 Migration Policy that stages chargers from the current connection model into mutual TLS with pending, active, rollback, and quarantine migration states, so fleet migration stays controlled and observable.
• Add Vehicle and ISO 15118 Provisioning Orchestration that keeps vehicle backend identity separate from ISO 15118 contract or provisioning material, so VDV 261 or similar value-added-service flows do not collapse into charger identity management.

1. Summary¶

• Problem statement:
  • BetterFleet needs to introduce certificate-based trust across two adjacent but distinct operational domains: charger or EVSE connectivity for OCPP Profile 3, and vehicle or Plug and Charge identity flows for ISO 15118 and value-added services such as VDV 261.
  • These domains use different protocols, actors, and trust boundaries, but the business still needs one coherent way to issue, install, activate, rotate, revoke, audit, and support certificates across the fleet.
  • Without a shared lifecycle model aligned to existing BetterFleet IoT hub management and OCPP requirements, BetterFleet risks inconsistent operator workflows, duplicated implementations, harder incident response, and slower rollout of secure charging and vehicle-service capabilities.
• Goal and success criteria:
  • Define one BetterFleet certificate-management specification that clearly separates charger and vehicle domains while reusing a shared lifecycle model.
  • Success means stakeholders can point to one source of truth for certificate state, one set of lifecycle actions, and a clear mapping from BetterFleet actions to OCPP 2.0.1 certificate operations.
  • What will be built in this phase:
  • Certificate Inventory + extend the existing BetterFleet certificate inventory pattern to charger, vehicle, ISO 15118, and trust-anchor records + all managed certificate states become visible and auditable in one place.
  • Operator Certificate Administration View + extend the existing IoT hub operator pattern to charger, vehicle, ISO 15118, and trust-anchor records + operations can inspect state, expiry posture, failures, and permitted actions in one surface.
  • Certificate Lifecycle Service + standardize issue, activate, deactivate, renew, revoke, and delete actions across certificate purposes + operator and backend workflows use one common lifecycle contract.
  • OCPP Certificate Orchestrator + implement standards-aligned OCPP 2.0.1 certificate message handling and policy checks + charger and EVSE certificate flows are executed through BetterFleet-controlled lifecycle state.
  • Profile 3 Migration State Machine + stage charger rollout through install, pending activation, active, rollback, and quarantine migration states + BetterFleet can migrate charge points without all-at-once cutovers.
  • Vehicle VAS Identity Management + manage backend-facing vehicle certificates for VDV 261 or similar services as a separate certificate purpose + vehicle identity is lifecycle-managed without reusing charger assumptions.
  • ISO 15118 Provisioning Tracking + model ISO 15118 provisioning or contract certificate delivery as a separate orchestration flow + external scheme, OEM, and EVSE steps remain auditable without becoming the source of truth.
• Scope (in/out) for this phase:
  • In:
  • Shared lifecycle model for managed certificates and trust anchors.
  • Charger certificate management for OCPP Profile 3.
  • OCPP 2.0.1 message responsibilities for certificate installation, certificate signing, certificate status, and ISO 15118-related orchestration.
  • Vehicle backend identity certificate management for VDV 261 or similar value-added-service use cases.
  • ISO 15118 provisioning state tracking where BetterFleet participates in the delivery path.
  • Out:
  • Full restatement of the licensed VDV 261 standard.
  • OEM-specific bootstrap contracts and certificate-subject rules not yet available to BetterFleet.
  • Firmware-signing PKI, firmware-signing workflows, and firmware artifact-verification design, except for the requirement to keep firmware-signing trust separate from operational certificate trust.
  • Detailed schema, database, or deployment design.
  • Commercial selection of PKI vendors beyond the already assumed BetterFleet platform choices.
• Current baseline:
  • As of March 10, 2026, BetterFleet already has a live IoT hub certificate lifecycle pattern with certificate inventory, status display, and operator actions such as add, activate, deactivate, and delete in bf-manage-web/src/pages/Settings/DepotPower/devicesTab/DeviceCertsTable.tsx and corresponding backend logic in bf-manage-core/src/iot_stream/devices/device_aws_iot_thing.py.
  • As of March 10, 2026, local OCPP 2.0.1 schemas for the required certificate messages exist in bf-manage-connect/docs/OCPP-2.0.1/OCPP-2.0.1_part3_JSON_schemas.zip, but bf-manage-connect does not currently support those handlers in production flow.
  • As of March 10, 2026, BetterFleet rollout planning still assumes mixed-version charger fleets and a controlled migration period where Profile 2 compatibility may remain necessary for some cohorts while Profile 3 capability is introduced.
• Future evolution guardrails:
  • This phase must keep it easy to add new certificate purposes without creating a new service for each domain.
  • This phase must not assume that ISO 15118 provisioning certificates and vehicle VAS identity certificates are interchangeable.
  • This phase must keep the lifecycle source of truth in BetterFleet even when the physical install or exchange happens over OCPP.
• Not in scope:
  • Technical internals such as table schemas, queue topology, or detailed PKI template definitions.

2. Users and Use Cases¶

• Primary personas:
  • Platform engineer
  • Charger or OCPP integration engineer
  • Security or PKI engineer
  • Operations team managing deployed chargers and vehicles
  • OEM or external provisioning integration team
• High-level user stories:
  • As operations, I want every managed certificate to have a visible lifecycle state so I can govern rollout, rollback, and incident response consistently.
  • As an OCPP engineer, I want charger certificate flows to map to OCPP 2.0.1 messages while keeping BetterFleet as the policy authority.
  • As a PKI engineer, I want charger identity, vehicle identity, and ISO 15118 provisioning trust to stay separate so trust decisions remain correct and auditable.
  • As an integration team, I want vehicle VAS identity and ISO 15118 provisioning to be modeled separately so OEM and contract-certificate dependencies do not distort the charger lifecycle.
• Edge cases and failure modes:
  • CSR does not match the authoritative charger or vehicle identity.
  • Charger installs a certificate but does not reconnect successfully with mutual TLS.
  • ISO 15118 provisioning material is delivered by an external actor and BetterFleet must track completion without owning issuance.
  • Trust-anchor installation succeeds on some EVSEs and fails on others in the same rollout wave.
  • A certificate is revoked centrally while the device remains physically online.

3. Conceptual Model Terms and Decisions¶

Key Terms¶

Decision Ledger¶

4. Domain Model and Eventstorming (Conceptual)¶

• Bounded context and ubiquitous language:
  • Certificate Lifecycle owns inventory, state transitions, audit, and policy for all managed certificates.
  • EVSE Security Orchestration owns charger Profile 3 rollout, trust-anchor distribution, and OCPP message execution.
  • Vehicle Provisioning Orchestration owns vehicle backend identity and ISO 15118 provisioning state tracking.
• Aggregates and entities:
  • ManagedIdentity: subject type, authoritative identifier, owner, allowed certificate purposes.
  • CertificateRecord: certificate purpose, lifecycle state, validity window, linked subject, activation policy.
  • TrustAnchorBundle: bundle purpose, target cohort, install state, active version.
  • CertificateJob: requested action, actor, correlation id, status, resulting record changes.
  • MigrationCase: charger, rollout wave, migration state, failure counters, exception reason.
  • ProvisioningCase: vehicle, provisioning path, prerequisite state, completion state.
• Value objects:
  • LifecycleTransition
  • CertificateFingerprint
  • TrustBundleVersion
  • OcppCertificateAction
  • ProtocolAdapterMapping
• Domain events and triggers:
  • CertificateRequested when BetterFleet decides a new certificate or renewal is needed.
  • CSRValidated when submitted key material matches policy and identity.
  • CertificateIssued when the CA returns signed material.
  • CertificateInstallRequested when BetterFleet has dispatched a certificate install job to the target execution path before the endpoint has confirmed receipt.
  • CertificateInstalled when the charger, EVSE, or vehicle confirms install.
  • CertificateActivated when BetterFleet records the activation verification required for that certificate purpose.
  • CertificateDeactivated when an active certificate is intentionally removed from service.
  • CertificateRenewalStarted when BetterFleet begins a renewal cycle for an existing active certificate that is approaching its renewal threshold.
  • CertificateRevoked when BetterFleet blocks future use of a certificate.
  • TrustAnchorReleaseRequested when BetterFleet initiates a new trust-anchor bundle rollout to a target cohort before any individual endpoint install is attempted.
  • TrustAnchorInstalled when a new trust bundle is confirmed on a remote endpoint.
  • MigrationQuarantined when automated rollout is halted for a charger pending manual review, exception handling, or family-specific action.
  • Iso15118ProvisioningStateChanged when provisioning moves between prerequisite, delivery, pending activation, and active states.
• Commands, actors, and policies:
  • IssueCertificate may be initiated by policy, operator action, or device request.
  • InstallTrustAnchor is initiated by BetterFleet and confirmed by OCPP or another integration path.
  • ActivateCertificate completes only after purpose-specific activation verification evidence is recorded.
  • RevokeCertificate is a policy or operator command that immediately affects BetterFleet authorization state.
  • QuarantineMigrationCase stops further automated rollout for a charger while preserving the current certificate and access state until an operator decides the next action.
  • RecordProvisioningOutcome updates vehicle or EVSE state without implying BetterFleet itself issued the underlying material.
• Invariants and business rules:
  • BetterFleet holds at most one active certificate per managed identity and certificate purpose.
  • A certificate cannot move to active without a verified installation or successful use signal.
  • installed_pending_activation means BetterFleet has evidence of installation, delivery, or acceptance, but has not yet recorded the activation verification required for that certificate purpose.
  • Quarantine is not a certificate lifecycle state; it is a migration-orchestration state on the charger or migration case.
  • Vehicle VAS identity and ISO 15118 provisioning artifact are always different certificate purposes, even if they are delivered in related business flows.
  • Trust-anchor bundles are versioned and rolled out separately from end-entity certificates.
  • Revocation in BetterFleet immediately changes authorization policy even if remote revocation checks lag.
• External systems and integrations:
  • OCPP chargers and EVSEs provide transport for certificate requests, certificate installation, certificate status inspection, security events, and log-upload outcomes.
  • Protocol compatibility adapters normalize supported OCPP 1.6J security-extension flows, ChangeConfiguration(SecurityProfile=3) transitions, and vendor-equivalent capabilities into the same internal lifecycle commands used for OCPP 2.0.1 orchestration.
  • Existing BetterFleet IoT hub device management provides the baseline operator pattern for certificate inventory and lifecycle controls.
  • OEM or external certificate authorities may supply bootstrap or ISO 15118 material for vehicles.
  • The platform CA issues BetterFleet-managed certificates and returns signed chains asynchronously.

Interaction Flow¶

flowchart LR
  Policy["Lifecycle policy or operator action"] --> Request["IssueCertificate / RenewCertificate"]
  Request --> Validate["Validate CSR and identity binding"]
  Validate --> Issue["Issue certificate"]
  Issue --> Install{"Install path"}
  Install -->|OCPP charger or EVSE| Ocpp["Run OCPP certificate orchestration"]
  Install -->|Vehicle or external flow| Vehicle["Run vehicle or OEM provisioning orchestration"]
  Ocpp --> Confirm["Record install outcome"]
  Vehicle --> Confirm
  Confirm --> Activate{"Verified use or activation?"}
  Activate -->|Yes| Active["CertificateActivated"]
  Activate -->|No| Pending["Remain pending or rollback"]

Event Timeline¶

timeline
  title Shared Certificate Lifecycle
  CertificateRequested : BetterFleet creates lifecycle job
  CSRValidated : Subject and key material pass policy
  CertificateIssued : Signed chain is returned
  CertificateInstalled : Remote endpoint reports installation
  CertificateActivated : BetterFleet verifies successful use
  CertificateRevoked : BetterFleet blocks authorization

Event Dictionary¶

• CertificateRequested: BetterFleet has created a lifecycle job | starts auditable work | managedIdentityId, certificatePurpose, requestReason, requestedBy | triggers validation and issuance policy.
• CSRValidated: Submitted key material and subject binding passed policy | allows signing to continue | jobId, csrFingerprint, identityBindingResult | triggers issuance.
• CertificateIssued: Signed certificate material is available | creates pending install work | certificateRecordId, issuerRef, validFrom, validTo | triggers install path selection.
• CertificateInstallRequested: BetterFleet has dispatched a certificate install job to the target execution path | creates trackable delivery work | certificateRecordId, executionPath, targetIdentity | triggers OCPP, vehicle, or brokered delivery.
• CertificateInstalled: Target endpoint confirms receipt or installation | allows activation checks | certificateRecordId, installationChannel, installedAt | triggers activation or rollback timer.
• CertificateActivated: BetterFleet has verified the purpose-specific activation evidence required for operational use | completes lifecycle rollout | certificateRecordId, activatedAt, replacedCertificateId, activationEvidenceType | retires prior active certificate for that purpose.
• CertificateRenewalStarted: BetterFleet has begun a renewal cycle for an existing active certificate approaching its renewal threshold | creates renewal job and links it to the current active certificate | certificateRecordId, existingCertificateId, renewalReason, thresholdTriggered | triggers issuance of a replacement certificate.
• CertificateRevoked: BetterFleet has blocked certificate use | starts incident or recovery handling | certificateRecordId, reason, revokedAt | updates authorization and monitoring.
• TrustAnchorReleaseRequested: BetterFleet has initiated a trust-anchor bundle rollout to a target cohort | creates trackable rollout work before individual endpoint installs | bundleId, bundleVersion, targetCohort, certificatePurpose | triggers per-endpoint install jobs.
• TrustAnchorInstalled: New trust bundle version is present on the endpoint | unblocks dependent certificate rollout | bundleId, targetIdentity, bundleVersion | enables issuance or activation waves.
• MigrationQuarantined: BetterFleet has halted automated rollout for a charger | prevents repeated unsafe or noisy automation | managedIdentityId, migrationCaseId, quarantineReason, failureCount | triggers manual review, exception path, or vendor-specific remediation.
• Iso15118ProvisioningStateChanged: Provisioning case moved between tracked states | keeps audit and business flow aligned | vehicleId, oldState, newState, provisioningPath | drives follow-up actions and visibility.

5. Standards Fit and Crosswalk¶

• Intent:
  • Show how the four standards or guidance sets sit at different layers of the solution and where BetterFleet requirements are derived, constrained, or only informed by them.
  • Distinguish between directly supported protocol requirements, public-summary assumptions, and items that still require licensed-standard validation.

Source Confidence¶

Layering View¶

flowchart LR
  BF["BetterFleet certificate lifecycle service"] <-->|charger/EVSE management| OCPP["OCPP 2.0.1 or OCPP 1.6 + Security Whitepaper uplift"]
  OCPP <-->|station-side control and certificate transport| EVSE["Charging station / EVSE"]
  EVSE <-->|EV charging communication| ISO["ISO 15118"]
  ISO <-->|vehicle-side charging and certificate-based session context| EV["Vehicle"]
  EV <-->|value-added-service backend path, complementary to ISO 15118| VDV["VDV 261 or similar VAS integration"]
  VDV <-->|vehicle/backend identity and provisioning coordination| BF

Standards Crosswalk¶

Crosswalk Conclusions¶

• OCPP 1.6 Security Whitepaper Ed. 3 is the transition guide for current OCPP 1.6-J fleets and should shape migration and uplift behavior, not the long-term canonical protocol contract.
• OCPP 2.0.1 is the canonical CSMS-to-charger or EVSE protocol source for certificate orchestration and should drive BetterFleet’s charger-side API and state-machine design.
• BetterFleet therefore needs an explicit compatibility layer for OCPP 1.6J fleets so current rollout paths can map into the same internal lifecycle commands and migration states used for OCPP 2.0.1-capable chargers.
• ISO 15118 is the canonical EV-to-EVSE communication domain and should be treated as the source of charging-session and Plug and Charge context, not as BetterFleet’s fleet lifecycle model.
• VDV 261 sits above or alongside ISO 15118 for vehicle/backend value-added-service behavior in the current working assumptions and must remain a separately modeled certificate purpose and provisioning flow.
• BetterFleet is the integrating lifecycle authority across all four layers: protocols define message boundaries, while BetterFleet defines shared inventory, policy, authorization, and audit.

6. Requirements and Constraints¶

• Functional requirements:
  • FR-001: BetterFleet shall maintain a certificate inventory record for every managed certificate and trust-anchor bundle used in IoT hub, charger, vehicle, or ISO 15118 flows.
  • FR-001a: BetterFleet shall provide an operator-facing certificate administration view for in-scope certificate inventory records and trust-anchor bundles that exposes, at minimum, the managed identity, certificate purpose, lifecycle state, validity or renewal posture, latest relevant install or activation outcome, and the authorized lifecycle actions available to the current operator.
  • FR-002: BetterFleet shall expose a canonical lifecycle state model that, at minimum, supports requested, issued, installed_pending_activation, active, inactive, retired, revoked, and deleted, with platform-specific statuses mapped into these canonical states.
  • FR-002a: BetterFleet shall define and apply activation-verification rules per certificate purpose so a certificate record moves from installed_pending_activation to active only after the required operational evidence for that purpose has been recorded.
  • FR-003: BetterFleet shall support lifecycle commands for issue, activate, deactivate, renew, revoke, and delete, and shall apply policy-controlled validity, renewal, and escalation rules with authorization and audit requirements consistent across managed certificate purposes.
  • FR-004: BetterFleet shall enforce at most one active certificate per managed identity and certificate purpose at any time.
  • FR-005: BetterFleet shall validate certificate requests against authoritative subject records and shall reject issuance or activation when identity binding fails.
  • FR-006: BetterFleet shall orchestrate charger certificate issuance and activation using OCPP certificate messages for certificate signing, certificate installation, certificate listing, certificate deletion, certificate status inspection, and security-event reporting where the charger or EVSE supports them.
  • FR-006a: BetterFleet shall provide a protocol compatibility adapter for supported OCPP 1.6J security-extension and vendor-equivalent charger flows so they map into the same internal lifecycle commands, migration states, and audit model used for OCPP 2.0.1 orchestration.
  • FR-007: BetterFleet shall treat Get15118EVCertificate and related ISO 15118 OCPP messages as orchestration for provisioning delivery, not as the authoritative certificate lifecycle state.
  • FR-008: BetterFleet shall manage vehicle VAS identity certificates and ISO 15118 provisioning artifacts as separate certificate purposes with separate lifecycle state and policy.
  • FR-009: BetterFleet shall stage charger rollout to mutual TLS through explicit pending, active, rollback, and quarantine migration behavior rather than a direct fleet-wide cutover, and shall keep any required Profile 2 fallback path dependent on hardened and rotated AuthorizationKey credentials.
  • FR-009a: BetterFleet shall model quarantine as a charger migration-orchestration state on the managed identity or migration case, not as a certificate lifecycle state, and shall require manual review or an approved exception path before automated rollout resumes.
  • FR-010: BetterFleet shall record security events and installation outcomes relevant to certificate lifecycle failures, including invalid certificate use, failed install, failed reconnect, and trust-anchor mismatch.
• Non-functional requirements:
  • NFR-001: Every lifecycle transition shall be auditable with actor, reason, timestamp, target identity, and resulting state.
  • NFR-002: Long-running issuance, revocation, and install workflows shall execute asynchronously so message-handling paths do not block charger or vehicle session processing.
  • NFR-003: Only the designated certificate lifecycle service may issue or revoke BetterFleet-managed certificates.
  • NFR-004: Lifecycle policy shall remain purpose-aware so trust decisions for charger identity, vehicle identity, and ISO 15118 provisioning cannot be accidentally merged.
  • NFR-005: Remote install or activation failures shall become visible to operations quickly enough to support controlled rollout and rollback decisions within the same deployment wave.
• Constraints and assumptions:
  • Existing BetterFleet IoT hub lifecycle patterns are the baseline for operator-facing lifecycle behavior, but charger and vehicle private keys are assumed to be generated on the endpoint rather than centrally delivered.
  • OCPP 2.0.1 schemas in the local BetterFleet workspace are treated as the normative local standard reference for message names and payload classes in this specification.
  • VDV 261 and OEM-specific vehicle certificate semantics remain subject to validation against licensed standards and integration agreements.
• Build item coverage mapping:
  • Certificate Inventory -> FR-001, FR-002, FR-002a, FR-004, NFR-001.
  • Operator Certificate Administration View -> FR-001a, FR-002, FR-002a, FR-003, FR-010, NFR-005.
  • Certificate Lifecycle Service -> FR-002a, FR-003, FR-005, NFR-002, NFR-003.
  • OCPP Certificate Orchestrator -> FR-006, FR-006a, FR-007, FR-010, NFR-002.
  • Profile 3 Migration State Machine -> FR-009, FR-009a, FR-010, NFR-005.
  • Vehicle VAS Identity Management -> FR-008, NFR-004.
  • ISO 15118 Provisioning Tracking -> FR-007, FR-008, FR-010, NFR-004.
• Verification notes:
  • FR-001, FR-001a, and FR-002 to FR-004 should later be validated with lifecycle inventory, operator-view, purpose-specific activation checks, and state-transition tests.
  • FR-006, FR-006a, and FR-007 should later be validated with OCPP integration tests covering both canonical OCPP 2.0.1 paths and supported OCPP 1.6J compatibility mappings.
  • FR-009, FR-009a, and FR-010 should later be validated in staged rollout simulations with forced install, reconnect, quarantine, and revocation failures.

7. Interaction and Flow¶

• Process overview:
  • BetterFleet receives a policy trigger, operator action, or remote certificate request.
  • The lifecycle service validates whether the target identity, certificate purpose, and transition are allowed.
  • BetterFleet issues, installs, and activates the certificate through the correct bounded context.
  • BetterFleet records success or failure and updates the canonical inventory state.

Activation Verification by Certificate Purpose¶

• Interpretation:
  • BetterFleet should use direct runtime proof where the platform can observe the credential in use, such as charger mTLS reconnect or vehicle-to-backend authentication.
  • Where BetterFleet cannot directly observe later runtime presentation, such as externally managed ISO 15118 provisioning material, activation is based on authoritative acceptance or readiness evidence rather than waiting for a later charging session.
  • The exact evidence type remains policy-controlled by certificate purpose, OEM program, and operating model, but the state transition contract is fixed: installed_pending_activation means delivered but not yet verified for operational use.

Flowchart Charger Profile 3 Lifecycle¶

flowchart TD
  Start["Need charger certificate"] --> Trust{"Trust anchor installed?"}
  Trust -->|No| InstallAnchor["Install trust anchor bundle"]
  InstallAnchor --> RequestCSR["Await or request SignCertificate CSR"]
  Trust -->|Yes| RequestCSR
  RequestCSR --> ValidateCSR["Validate charger identity and CSR"]
  ValidateCSR --> Issue["Issue charger identity certificate"]
  Issue --> SendSigned["Return certificate via OCPP CertificateSigned or equivalent"]
  SendSigned --> Installed{"Installation confirmed?"}
  Installed -->|No| RetryBudget{"Retry budget exhausted?"}
  RetryBudget -->|No| Retry["Retry installation or activation path"]
  Retry --> RequestCSR
  RetryBudget -->|Yes| Quarantine["Quarantine migration case for manual review"]
  Installed -->|Yes| Activate["Require reconnect with mTLS"]
  Activate --> Verified{"Verified active connection?"}
  Verified -->|Yes| Active["Mark active and retire previous certificate"]
  Verified -->|No| Rollback["Hold pending state or rollback window"]

Sequence Diagram OCPP Certificate Orchestration¶

sequenceDiagram
  participant Policy as BetterFleet Policy
  participant CLS as Certificate Lifecycle Service
  participant OCPP as OCPP Integration Service
  participant EVSE as Charger or EVSE

  Policy->>CLS: Issue or renew charger certificate
  CLS->>OCPP: Create charger certificate job
  OCPP-->>EVSE: InstallCertificate (trust anchor if required)
  EVSE->>OCPP: InstallCertificate response
  EVSE->>OCPP: SignCertificate (CSR)
  OCPP->>CLS: Validate identity and CSR
  CLS-->>OCPP: Signed chain and activation policy
  OCPP-->>EVSE: CertificateSigned
  EVSE->>OCPP: Reconnect with mTLS
  OCPP->>CLS: Activation confirmed
  CLS-->>Policy: CertificateActive

Sequence Diagram ISO 15118 Provisioning Orchestration¶

sequenceDiagram
  participant App as BetterFleet Application
  participant CLS as Certificate Lifecycle Service
  participant OEM as OEM or External Provider
  participant OCPP as OCPP Integration Service
  participant EVSE as EVSE

  App->>CLS: Start ISO 15118 provisioning case
  CLS->>OEM: Request or validate provisioning material
  OEM-->>CLS: Provisioning artifact or status
  CLS->>OCPP: Run EVSE-assisted delivery if required
  OCPP-->>EVSE: Get15118EVCertificate / InstallCertificate / status flow
  EVSE->>OCPP: Delivery outcome
  OCPP->>CLS: Report delivery result
  CLS->>CLS: Verify acceptance or readiness evidence
  CLS-->>App: Update provisioning state to pending activation or active

8. Non-Technical Implementation Approach¶

• Approach overview:
  • Start by defining and agreeing the shared lifecycle language, because the current gap is primarily conceptual and ownership-related rather than implementation detail alone.
  • Build the shared certificate inventory and lifecycle controls first, because both charger and vehicle domains need the same governance baseline.
  • Add charger and EVSE orchestration next, because OCPP certificate handling is the most concrete standards-aligned path and is already represented in local BetterFleet OCPP references.
  • Add vehicle VAS identity management and ISO 15118 provisioning after the shared lifecycle contract is in place, because those flows depend more heavily on OEM and licensed-standard assumptions.
• Design considerations:
  • Optimize for one operational model, not one protocol implementation.
  • Keep policy, audit, and operator visibility centralized even when transport execution is distributed across chargers, EVSEs, vehicles, OEMs, and certificate authorities.
  • Treat standards messaging and business ownership as separate concerns: OCPP messages define transport responsibilities, while BetterFleet defines lifecycle truth and authorization.
• Dependencies and prerequisites:
  • Agreement on canonical lifecycle states and how existing IoT hub states map into them.
  • Agreement on which OCPP versions and charger families must be supported first.
  • Validation of vehicle-side assumptions against purchased VDV 261 material and OEM-specific guidance.
  • Completion of the certificate-purpose ownership matrix for BetterFleet-managed, BetterFleet-brokered, and externally managed but BetterFleet-tracked ISO 15118 and VDV paths.

9. Open Questions¶

• Which existing IoT hub backend components should be extended directly, and which should remain specific to IoT-only certificate handling?
• Which charger families in scope actually support the full OCPP 2.0.1 certificate-management message set versus vendor-specific or older-profile equivalents?
• For VDV 261 or similar value-added-service integrations, what contractual, OEM, or standards constraints determine whether BetterFleet issues the operational vehicle identity certificate directly or manages third-party-issued material?
• For Plug and Charge programs, which certificate purposes must remain eMSP-, OEM-, or scheme-managed even when BetterFleet provides the operational lifecycle and validation path?
• Which external PKI-manager and OCPI interaction patterns must BetterFleet support in phase 1 when BetterFleet is acting as broker or validator rather than issuer?
• For ISO 15118 provisioning flows, which artifacts must BetterFleet store as authoritative inventory versus evidence-only metadata and audit history?
• Should the required operator-facing certificate administration view extend the current IoT hub certificate screens or be delivered as a new cross-domain certificate administration surface?

10. Appendices¶

• Consolidated design baseline:
  • The existing IoT hub management pattern already gives BetterFleet a useful baseline for inventory, status visibility, and lifecycle actions.
  • Local OCPP 2.0.1 schemas confirm the message set this specification must align to, while current bf-manage-connect code confirms those flows are still to be implemented.
  • BetterFleet needs one consolidated lifecycle design spanning charger security migration, charger certificate orchestration, vehicle value-added-service identity, and ISO 15118 provisioning tracking.
• Local references reviewed:
  • bf-manage-core/src/iot_stream/devices/device_aws_iot_thing.py
  • bf-manage-web/src/pages/Settings/DepotPower/devicesTab/DeviceCertsTable.tsx
  • bf-manage-connect/src/ocpp_handlers/v2_0_1/handler.py
  • bf-manage-connect/docs/OCPP-2.0.1/OCPP-2.0.1_part3_JSON_schemas.zip
• External standards references reviewed:
  • OCPP 1.6 Security Whitepaper (3rd edition), Open Charge Alliance: https://openchargealliance.org/ocpp-info-whitepapers/ocpp-1-6-security-whitepaper-3rd-edition/
  • OCPP download page, Open Charge Alliance: https://openchargealliance.org/my-oca/ocpp/
  • ISO 15118-2:2014, ISO abstract page: https://www.iso.org/standard/55366.html
  • ISO 15118-20:2022, ISO abstract page: https://www.iso.org/standard/77845.html
  • VDV publication catalogue entry for Recommendation 261 Edition 2, VDV: https://www.vdv.de/schriften---mitteilungen.en.aspx?coriander=v3_8b2c6044-cf4f-4ce4-af76-d6971128c2d1
• Alignment to current IoT hub lifecycle:

OCPP 1.6J to OCPP 2.0.1 Transition Compatibility Retained for Design¶

• Intent:

  • Preserve the fact that BetterFleet’s current charger fleet and source migration design are OCPP 1.6J-oriented, even though the canonical lifecycle contract in this specification targets OCPP 2.0.1 semantics.
  • Make the compatibility layer an explicit design element so mixed-version rollout does not accidentally create two separate lifecycle models.

• Retained design position:

  • BetterFleet should keep one internal charger-certificate lifecycle model.
  • OCPP 2.0.1 remains the canonical internal contract for charger certificate orchestration concepts.
  • OCPP 1.6J security-extension flows, including security-profile switching behavior and vendor-equivalent message paths, should be translated by a compatibility adapter into the same internal commands and migration states.

• Compatibility layer responsibilities:

  • Normalize supported OCPP 1.6J charger requests and responses into canonical lifecycle actions such as trust-anchor install, CSR submission, signed-certificate delivery, activation verification, security-event recording, and migration-state transition.
  • Represent ChangeConfiguration(SecurityProfile=3) or equivalent 1.6J security-profile cutover steps as migration actions inside the same rollout state machine used for OCPP 2.0.1-capable devices.
  • Use a charger-family capability matrix to determine whether a charger can use native OCPP 2.0.1 paths, 1.6J security-extension paths, vendor-specific equivalents, or must remain outside the rollout cohort.
  • Preserve one audit trail and one inventory model regardless of which wire-protocol path was used.

• Practical implication for rollout:

  • Near-term production rollout may be dominated by 1.6J-compatible flows.
  • The platform design should still avoid baking 1.6J-specific message shapes into the core lifecycle service, because that would make later 2.0.1 convergence harder.
  • Chargers that cannot be mapped safely into the canonical lifecycle through a supported adapter path should remain exception-managed rather than forcing ad hoc protocol behavior into the rollout.

• Relationship to the main requirements:

  • This appendix preserves the bridge implied by D-006, D-007, FR-006, and FR-006a.
  • It also supports FR-009 because migration sequencing depends on the compatibility path used by each charger family.

Security Event Logging and Observability Retained for Design¶

• Intent:

  • Preserve the security-event and log-handling concerns as a first-class part of the lifecycle design so rollout observability is not lost.
  • Keep security-event handling attached to certificate lifecycle and migration operations rather than treating it as an unrelated diagnostics feature.

• Retained conceptual expectations:

  • Chargers should maintain a dedicated security log separate from general diagnostics logging where the device platform supports that distinction.
  • Security-relevant failures should be reported centrally, including invalid certificate use, authentication failure, trust-anchor problems, certificate-install rejection, repeated reconnect failure, and security-log clear events.
  • BetterFleet should support remote security-log retrieval and status tracking using protocol-native mechanisms such as GetLog and LogStatusNotification, or approved equivalents where charger support differs.
  • Event ingestion should be asynchronous so certificate issuance, activation, and session handling are not blocked by downstream storage or alert-routing work.
  • High-severity certificate and TLS failures should flow into central alerting or SIEM processes quickly enough to support the same rollout wave and incident-response window.

• Retained event categories:

• Relationship to the main requirements:
  • This appendix preserves the operational intent behind FR-010.
  • Asynchronous handling and central visibility directly support NFR-002 and NFR-005.

Platform and Cloud Assumptions Retained for Design¶

• Intent:

  • Preserve the current platform and deployment assumptions behind the lifecycle design so they are not lost when the specification stays conceptual.
  • Keep the logical architecture stable even if specific infrastructure choices are later mapped differently.

• Retained platform assumptions:

  • BetterFleet should have a dedicated internal certificate lifecycle service rather than embedding issuance and revocation logic directly in session-handling code.
  • BetterFleet-managed operational client certificates should be issued through a private CA control plane with policy-controlled issuance and revocation.
  • Backend-facing server certificates for central-system endpoints should continue to use the platform’s managed server-certificate path where available.
  • Certificate inventory, migration state, audit history, and policy state should be stored in a transactional backend store under restricted access.
  • Long-running issuance, revocation, renewal, and security-log workflows should run through asynchronous jobs or event-driven processing.
  • Security-log artifacts and other rollout evidence should be stored in durable object storage with lifecycle and access controls.
  • IAM, secret handling, and key-protection boundaries should prevent charger-facing session services from having unrestricted CA permissions.
  • Central metrics, dashboards, and alerting should cover issuance, expiry, install failure, activation failure, revocation, and rollout-wave health.

• Current cloud-oriented examples retained for continuity:

• Relationship to the main requirements:
  • This appendix preserves the operational assumptions behind FR-001, FR-003, FR-005, and NFR-003.
  • It also supports FR-010 because security-log and event handling depend on these platform capabilities.

CA Root and Trust Anchor Requirements Retained for Design¶

• Intent:

  • Preserve a short, explicit view of the root-certificate and trust-anchor requirements so they remain visible in the design alongside end-entity certificate lifecycle requirements.
  • Keep root and intermediate CA handling aligned to the shared BetterFleet trust-anchor model rather than treating PKI roots as an external detail.

• Overview:

  • BetterFleet shall model CA root and intermediate certificates as managed TrustAnchorBundle content, with inventory, versioning, rollout state, and audit separate from end-entity certificates.
  • Trust anchors shall remain purpose-specific, so charger identity trust, ISO 15118 trust, vehicle VAS trust, backend server trust, and future firmware-signing trust do not collapse into one combined root set.
  • Trust-anchor rollout shall be staged and verified before dependent leaf certificates are activated for a cohort, charger family, vehicle program, or external integration path.
  • Root and intermediate CA lifetimes shall be treated as long-lived PKI policy objects governed by corporate or scheme policy, not by the shorter renewal cadence used for charger or vehicle operational certificates.
  • BetterFleet shall keep trust-anchor inventory operator-visible, including active version, target cohort, install status, and any rollout or mismatch failures relevant to operations.
  • BetterFleet-managed runtime services shall not hold unrestricted root-CA or private-CA control; trust issuance and trust-bundle governance must remain behind restricted PKI control-plane permissions.
  • BetterFleet shall support controlled trust-anchor replacement and emergency trust-anchor withdrawal where compromise, expiry, standards migration, or scheme change requires root-set updates.

• Practical interpretation:

• Relationship to the main requirements:
  • This appendix sharpens the trust-anchor aspects already implied by FR-001, FR-006, and FR-010.
  • It also aligns with D-005 by keeping root trust separated by certificate purpose and trust domain.

ISO 15118 and VDV Ownership Decision Framework Retained for Design¶

• Intent:

  • Preserve the ownership and operating-model decisions needed for ISO 15118 and VDV certificate handling so the design does not stall on a vague "BetterFleet-owned versus external" question.
  • Turn the remaining ambiguity into a certificate-purpose matrix that can be completed per program, OEM, customer, or scheme relationship.

• Working position to retain:

  • BetterFleet should own as much of the certificate lifecycle as contractually and technically possible.
  • BetterFleet should build full ISO 15118 operational capability for orchestration, validation, lifecycle tracking, support, and audit, even where an external PKI manager remains the issuer for some certificate purposes.
  • BetterFleet must be able to facilitate or broker Plug and Charge certificate workflows when certificate validation or issuance happens on behalf of an eMSP or another PKI manager, including OCPI-mediated integration paths where required by the business model.
  • For VDV 261 or similar vehicle-to-backend value-added-service programs, BetterFleet is expected to operate the backend or CSMS-side integration and therefore needs direct certificate-management capability for vehicle identity, even if some programs also require acceptance of third-party-issued material.

• Operating-model categories to preserve:

• Certificate-purpose decision matrix to complete:

• Immediate questions this framework is intended to answer:

  • For Plug and Charge, which certificate purposes must BetterFleet manage directly and which must remain eMSP-, OEM-, or scheme-managed even though BetterFleet needs end-to-end operational visibility?
  • When BetterFleet validates Plug and Charge certificates on behalf of an eMSP or interacts with an external PKI manager, what OCPI roles, endpoints, and trust assertions are required?
  • For each externally governed certificate purpose, does BetterFleet need the full certificate and chain in inventory, or only proof of provisioning status, expiry, fingerprint, and audit evidence?
  • For VDV 261 programs, is BetterFleet authorized to issue the vehicle-facing operational certificate, or must it support both BetterFleet-issued and externally issued variants?
  • Which incident paths must BetterFleet resolve itself, and which must be escalated to an eMSP, OEM, or scheme authority?

• Design implication to retain:

  • BetterFleet should not treat ISO 15118 as an all-or-nothing ownership decision.
  • The platform should be designed so the same lifecycle service can operate in all three modes: BetterFleet-managed, BetterFleet-brokered, and externally managed but BetterFleet-tracked.
  • FR-007 remains the rule that OCPP ISO 15118 messages are orchestration rather than the lifecycle source of truth.
  • FR-008 remains the rule that vehicle VAS identity certificates and ISO 15118 provisioning artifacts are separate certificate purposes with separate policy and lifecycle handling.
  • Any later implementation or customer onboarding should complete the matrix before a new certificate purpose or program is treated as production-ready.

• Relationship to the main requirements:

  • This appendix sharpens the intended operating model behind FR-007 and FR-008.
  • It also constrains future implementation of FR-001, FR-003, and NFR-004 by requiring BetterFleet to stay purpose-aware and role-aware rather than assuming one ownership mode for all ISO 15118-related certificates.

Profile 2 AuthorizationKey Hardening During Migration¶

• Intent:
  • Preserve a controlled Profile 2 path during migration without leaving legacy shared or weak credentials in service.
  • Make AuthorizationKey hygiene an explicit prerequisite for Profile 3 rollout waves, not an implicit operational assumption.
• Scope:
  • Applies only while BetterFleet still allows any charger cohort to connect using OCPP Profile 2 during migration, rollback, quarantine, or approved recovery scenarios.
  • Does not replace the target-state requirement for charger mutual TLS under Profile 3.
• Conceptual policy:
  • Every charge point that remains eligible for Profile 2 connectivity shall have a unique AuthorizationKey.
  • BetterFleet shall treat AuthorizationKey rotation readiness as a migration-readiness check for any charger entering a Profile 3 pilot or rollout wave.
  • BetterFleet shall support a dual-slot credential model so the current active key and the next pending key can coexist during controlled cutover.
  • BetterFleet shall retire old Profile 2 credentials after a bounded rollback window once the rotated key has been proven in service.
• Credential baseline:

• Rotation workflow:

  • Inventory the current Profile 2 credential state for every in-scope charger, including uniqueness, age, firmware support, and recent successful connection status.
  • Enable backend authentication logic that accepts both the currently active key and the next pending key for the same charger during the transition window.
  • Generate a new pending AuthorizationKey, persist a new key version, and deliver it over an already trusted device-management path.
  • Require the charger to acknowledge storage of the pending key before BetterFleet schedules a reconnect or cutover window.
  • Promote the pending key to active only after a successful authenticated reconnect using the new key.
  • Move the previous key to retiring, then to retired after the rollback window expires.

• Rotation triggers:

  • Mandatory hygiene rotation before Profile 3 pilot entry.
  • Immediate rotation when BetterFleet identifies vendor defaults, shared secrets, probable exposure, or installer transfer.
  • Re-rotation after charger refurbishment, communication board replacement, or equivalent identity-impacting maintenance.
  • Optional periodic rotation for chargers that must remain on Profile 2 longer than the target migration window.

• Failure handling:

  • If a charger stores the pending key but never reconnects successfully, BetterFleet may keep the previous key valid only for the defined rollback window.
  • If a charger firmware family cannot safely support dual-slot storage, that family shall not enter bulk rotation or Profile 3 rollout until an approved family-specific cutover path exists.
  • Bulk rotation jobs shall be rate-limited by charger family, site cohort, or region to avoid fleet-wide loss of connectivity.

• Relationship to the main requirements:

  • This appendix supports FR-009 directly.
  • The resulting key inventory and audit behavior is also consistent with FR-001, FR-003, and NFR-001.

Renewal and Validity Policy Retained for Design¶

• Intent:
  • Preserve renewal and validity policy as an explicit design concern so it is not lost between conceptual design and implementation.
  • Make these values configurable within BetterFleet lifecycle policy rather than hard-coded into one service or rollout script.

• Design principle:

  • Renewal timing, escalation thresholds, incident thresholds, and validity windows are lifecycle-policy inputs.
  • BetterFleet shall hold these values in a configurable policy source by certificate purpose, and where needed by device family, cohort, or operating model.
  • Implementations may start with a default policy, but the policy must remain editable without redesigning the lifecycle model.

• Policy items that should be configurable:

• Retained policy values for design continuity:

• BetterFleet interpretation:

  • The 180-day and T-30/T-14/T-7 values are preserved here as the current design reference for charger certificates.
  • Those values should be treated as default policy inputs, not as immutable constants.
  • Vehicle certificate validity remains purpose-specific and less numerically fixed in the current design because OEM, VDV 261, and operating-model constraints still need confirmation.

• Relationship to the main requirements:

  • This appendix makes the policy aspect of FR-003 explicit.
  • Charger-side thresholds directly support FR-009 and NFR-005.
  • Storing and auditing policy outcomes remains consistent with FR-001 and NFR-001.

Delivery Workstreams and Readiness Dependencies Retained for Design¶

• Intent:
  • Preserve the concrete delivery structure needed for execution so critical implementation dependencies are not lost as the specification is generalized.
  • Make firmware and other cross-team dependencies visible as planning inputs, not hidden assumptions.

• Design principle:

  • Profile 3 rollout depends on coordinated delivery across firmware, backend or OCPP, platform, PKI, and operations.
  • Firmware capability is a gating dependency for rollout readiness, not a downstream implementation detail.

• Retained workstreams:

• Firmware-specific readiness items that must remain visible:

  • Dual-slot AuthorizationKey storage is required if Profile 2 is retained during migration.
  • Local private-key generation and CSR creation are required for endpoint-owned charger identity certificates.
  • Trust-anchor install, certificate install, activation, and rollback behavior must exist on the charger before BetterFleet can safely cut over to Profile 3.
  • SecurityEventNotification, GetLog, and LogStatusNotification are operational dependencies for rollout observability, not optional extras.
  • Firmware-family capability variance must be tracked explicitly because rollout planning depends on which families support the required security message set.

• Other key retained dependencies:

  • Backend or OCPP implementation must provide the control-plane logic for Profile 2 rotation, Profile 3 activation, security-event handling, and certificate orchestration.
  • Platform and PKI work must exist before production rollout so issuance, revocation, trust-anchor distribution, and audit are not coupled to ad hoc manual steps.
  • Operations readiness must include cohort planning, exception management, and support runbooks because Profile 3 migration is a staged fleet change, not only a software release.

• Retained milestone spine for design continuity:

• Relationship to the main requirements:
  • Firmware readiness is a direct dependency for FR-006, FR-009, and FR-010.
  • Backend and PKI workstreams are direct dependencies for FR-003, FR-005, and NFR-003.
  • Operations and observability work directly support NFR-001, NFR-002, and NFR-005.

Firmware-Signing Trust Domain Retained for Future Design¶

• Current scope note:

  • Firmware-signing PKI is not part of the implementation scope of this specification.
  • The only current requirement is that firmware-signing trust must remain separate from operational certificate trust used for charger identity, vehicle identity, backend server identity, and ISO 15118 provisioning.

• Why the separation matters:

  • Operational certificate rotation or revocation must not undermine the ability to verify firmware authenticity.
  • A compromise of an operational identity certificate must not automatically imply compromise of the firmware-signing chain.
  • Firmware release control, artifact provenance, and boot-time verification have different security owners and lifecycle rules from session-authentication certificates.

• Future design expectations to retain:

  • Firmware signing should use a dedicated trust domain with its own root or intermediate hierarchy and its own issuance controls.
  • Firmware-signing keys should not be reused for charger mutual TLS, backend TLS, vehicle VAS identity, or ISO 15118 provisioning purposes.
  • Devices should validate firmware artifacts against a firmware-signing trust store that is managed separately from the operational trust-anchor bundles used for session authentication.
  • Firmware-signing trust updates should be versioned and rolled out through a dedicated release and rollback process rather than being coupled to ordinary certificate-renewal workflows.
  • Incident handling for firmware-signing compromise should have its own runbooks, because remediation may require release withdrawal, trust-store replacement, or secure update sequencing rather than only certificate revocation.

• Relationship to the current design:

  • This appendix preserves the trust-domain separation required by D-005.
  • It extends D-005 without expanding the current implementation scope.
  • Any future firmware-signing specification should integrate with the shared BetterFleet certificate inventory only at the level of visibility and audit, not by collapsing the signing PKI into the operational lifecycle model.

Cross-Reference to Architecture Document¶

• Companion document: architecture.md
• Relationship: This specification defines the conceptual lifecycle model, domain events, invariants, and requirements. The architecture document concretizes those into service assignments, AWS infrastructure choices, PKI realm design, deployment topology, and phased build order.

Decision Ledger Mapping¶

Requirements Mapping¶

Build Item Mapping¶

Domain Event Mapping¶

Reconciliation Status¶

• CertificateDeactivated: Now present in both documents.
• CertificateInstallRequested, CertificateRenewalStarted, TrustAnchorReleaseRequested: Now present in both documents. Originally introduced in the architecture; added to the spec as conceptual events.
• The spec's FR numbering and the architecture's FR numbering are independent sequences. The mapping table above provides the cross-walk; any future requirements tracker should reconcile these into one numbering scheme or use explicit cross-references.

Provisioning Event Naming — Open¶

• The spec uses Iso15118ProvisioningStateChanged. The architecture uses ProvisioningOutcomeRecorded.
• These two names reflect a real conceptual tension that should be resolved before implementation:
  • Iso15118ProvisioningStateChanged emphasises state progression through the provisioning lifecycle — prerequisite, delivery, pending activation, active. It is broader: it fires on every tracked transition, not only on outcomes. It also names ISO 15118 explicitly, tying the event to one provisioning domain.
  • ProvisioningOutcomeRecorded emphasises evidence capture from external actors — an external scheme returned a status, approval, fingerprint, or reference, and BetterFleet recorded it. It is narrower: it fires when external evidence arrives, not on every internal state change. It is also domain-neutral, covering Hubject, OCPI, OEM, and other brokered paths without naming ISO 15118.
• The difference matters because the spec's provisioning model includes internally tracked state changes (prerequisite met, delivery dispatched) that are not external outcomes. A single event name should cover both internal transitions and external evidence, or two events should be defined.
• Recommendation to resolve: Decide whether provisioning events should be one general-purpose event or split into internal-transition and external-evidence events. If one event, ProvisioningStateChanged (without the ISO 15118 prefix) is the most flexible name — it covers all provisioning paths and all transition types. If two events, keep ProvisioningStateChanged for internal transitions and add ProvisioningEvidenceRecorded for external evidence capture.