1. Introduction
In the FDO specification, section 4.4 has a table called "Cipher Suite Names and Meanings" that gives the Key Derivation Function "KDF" to use for each supported cipher suite. In this table, the AES128 and AES256 authenticated encryption suites all use the same KDF with HMACSHA256. This document discusses the implications of using this KDF with AES256.
The Key Derivation Function is described in section 3.6.4 of FIDO Device Onboard. It is based on KDF In Counter Mode from section 5.1 in [SP800108]. The FDO specification section defines how the KDF variables from [SP800108] are realized. The PRF is given as HMACSHA256 or HMACSHA384, and references the abovementioned "Cipher Suite Names and Meanings" table in section 4.4.
1.1. SP800108 and KDF description
The description of the KDF in the FIDO Specification has been reviewed in the past and meets the security requirements of the FDO protocol. SP800108 has since been updated by the NIST, as SP800108r1upd1 [SP800108r1upd1]. However, the KDF in Counter Mode is unchanged across the versions.
The original document [SP800108] refers to the "machine integer size" for some variables (e.g., the variable L), and the FDO specification gives specific values for all machines to use, so that the computation will be the same on all machine architectures, including where machine word sizes and byte ordering might vary.
This means it is possible that any given crypto package might support this KDF, but not be compatible with FDO. We have seen this to be true, for example, in a Javabased crypto package. Although this incompatibility is annoying to implementors, it does not represent a weakness in the FDO specification. It may pose a burden on implementors who wish to obtain FIPS certification since the precertified KDF in the crypto package cannot be used with FDO.
1.2. Choice of Hash for KDF
The KDF for FDO uses an HMAC based on SHA256 or SHA384. The definition of the HMAC is given in [FIPS1981] "The KeyedHash Message Authentication Code". The readers and implementors are directed to this source; the following is for illustration purposes only.
The HMAC in [FIPS1981] can be simplified to:
HMAC(text) ::= SHAN( (secret XOR 0x6363...)  (secret XOR 0x3636...)  text )
Where:

SHAN is SHA256 or SHA384

the elipsis (...) indicates a repeating pattern for 256 or 384 bits

the  operator is bitwise concatenation

"secret" has been extended to cover 256 or 384 bits
We can see here that the cryptographic strength of the HMAC is based on the strength of the hash function in use, which is either SHA256 or SHA384. The cryptographic strength is thus bound by the strength of SHA used.
The defined KDF uses a SHA256 for all cipher suites containing AES128. For cipher suites containing AES256, the defined KDF is inconsistent, with SHA256 used for A256GCM and AES256CCM64128256 ciphers, while SHA384 is used for the AES256/CTR/HMACSHA384 suite.
To be honest, the authors intended that SHA384 be used as the KDF for all the AES256 suites. The smaller SHA256 value for AES256GCM and AES256CCM64128256 can be thought of as a typographic error in the spec. At question is whether this error results in a weaker strength of cryptography.
NIST SP80057, part 1, revision 5, table 3 [SP80057pt1r5] gives maximum security strengths for hash and hashbased functions. The table gives security strength for digital signatures and also for Key Derivation Functions (the difference is that KDF does not require collision resistance).
We excerpt the part of the table that is apropros to this discussion:
Security Strength  KDF 

128  SHA1 
≥ 256  SHA256, SHA384, SHA512 ... 
The cryptographic strength of AES128 is 128 bits and AES256 is 256 bits.
So we can see that:

SHA256 combined with AES128 gives a security strength of 128 bits

SHA256 combined with AES256 gives a security strength of 256 bits

SHA384 combined with AES256 gives a security strength of 256 bits
As a side note, NIST recommendations for resistance to PQ computing for 20192030 is a key strength of 192 bits [SP80057pt1r5].
[As of this writing, the following website has a nice summary of multiple NIST and other sources: https://www.keylength.com/en/4/]
So we can see that in the FDO specification table in section 4.4, that the smaller HMAC size does not impact the cryptographic strength of 128 bits for all 4 ciphers, since the strength of AES is the limiting factor in all cases.
Cipher  KDF strength  Security strength 

A128GCM  128 bits  128 bits 
AESCCM64128128  128 bits  128 bits 
AES128/CTR/HMACSHA256 AES128/CBC/HMACSHA256  256 bits  128 bits 
A256GCM  256 bits  256 bits 
AESCCM64128256  256 bits  256 bits 
AES256/CTR/HMACSHA384 AES256/CBC/HMACSHA384  384 bits  256 bits 
For FDO 1.2 we can consider bringing upgrading AES256 suites to use the larger hash for consistency.
As an aside, for FDO 1.2, we can consider using SHA512 in place of SHA384:

SHA384 uses SHA512 with part of the key fixed (i.e., computation of SHA384 and SHA512 is essentially the same)

Additional overhead of storing 512bit HMAC key versus 384bit HMAC key is small.
1.3. Conclusion
For users of FDO 1.1, for situations where existing users of FDO need the strongest cryptographic strength, we recommend using any of the cipher suites with AES256:

A256GCM

AESCCM64128256

AES256/CTR/HMACSHA384.
For FDO 1.2, we may choose to provide larger cipher suites to protect against attacks from early quantum computers. This could involve updating the hash further from SHA256 and even from SHA384 to SHA512.
As an alternative, we notice that TLS1.3 uses the HKDF as defined in REF #RFC5869. This KDF is very similar to the KDF used in FIDO Device Onboard:

HMAC is used over text with a counter to create random bits.

Context information is added into the mix (e.g., the string "FDO 1.2")

A counter is used to expand the KDF to more output if needed.
In addition, the KDF formula is commonly implemented by crypto packages and (because it is used in TLS) is implemented consistently on multiple computer architectures.