For an official Windows 11 .iso image it would be enough to format it as FAT32 and extract all the files.
Make sure that it has an EFI directory with a file EFI\Boot\bootx64.efi. That's what UEFI firmware will expect to find when booting a non-optical disk.
Back on the other computer I discovered it is formatted UDF. Formatting the key FAT32 does not solve the problem because one file is larger than 4GB, which cannot be handled by FAT32.
If it's the Install.wim file, use dism /Split-Image to deal with this problem. If you only have Linux, use wimsplit from the "wimlib" or "imagex" package.
According to MS docs, the regular Windows installer also supports looking for Install.wim on other partitions, so it's possible to have a FAT32 bootable partition and an NTFS secondary partition that only stores Install.wim.
Try downloading a different Windows image; if I remember correctly, the recent "public" .iso releases (downloadable for free from Microsoft.com) had an Install.wim that was already under the FAT32 limit. It depends on which Windows editions are included in it, as well as which drivers (and a "Recovery" image might have lots of stuff added).
Finally, some modern firmwares can actually read NTFS filesystems, so mkfs.ntfs and unpacking the .iso contents into that may also be an option.
I read that UEFI is not required to handle UDF (though this is the now-preferred format for DVDs) but is this true? UEFI can boot from CD or DVD where this format is frequently met.
It doesn't actually boot from UDF in this case – similar to how BIOS boot works with CDs, the firmware instead looks for a special "El Torito boot header" which points to a separate bootable file system image.
Originally CDs were not bootable and you had to boot a PC from a floppy disk that loaded a minimal kernel with CD support and proceeded to load the rest of the OS from the CD. With the "El Torito" format, it's very much the same – the CD filesystem is not booted directly, but rather has an image of a bootable disk embedded adjacent to the ISO9660 or UDF filesystem.
(As a side note, UEFI requires bootable UDF media to follow the "UDF Bridge" format which means they are actually dual UDF/ISO9660 filesystems, and El Torito is actually the procedure for booting from ISO9660 CDs.)
The specification allows a single ISO9660 filesystem to store multiple such images for different platforms, e.g. one for x86 PC and another for PowerPC Macs, and there is also a platform ID defined for "UEFI" in which the image would contain a tiny FAT32-based EFI System Partition. That's what is really being booted when the image is written to a CD or DVD.
AFAIK, Linux "hybrid ISO" images are often prepared so that the MBR or GPT partition table (for HDD/USB boot) has an "EFI System Partition" which references the exact same data as the El Torito boot image (for CD boot).
Using UDF on a USB flash drive mentions that default UDF block size is 4096 while USB keys expect 512. Could it be the cause of the problem? Should I reformat my UDF key with a 512-blocksize before copying data?
It's more about logical sector size than filesystem block size. Nearly all USB disks (and most internal disks) are addressed in terms of 512-byte sectors, while data CDs are addressed in terms of 2048-byte sectors.
Using filesystem block sizes larger than the disk sector size is completely normal, and the difference doesn't matter as long as the filesystem's structures are all defined in absolute values (bytes) rather than being relative to the disk sector size.
But it can result in funny things when an image built for one sector size is written to a disk that uses another. For example, you can actually fit a 34-sector GPT partition table inside the 16-sector reserved area of an ISO9660 filesystem, because the reserved area is actually 16×2048 bytes when the image is read from a CD but the GPT is only 34×512 bytes when it's read from a USB stick.
(For the same reason, the ISO9660 filesystem itself may not be readable when written to a USB stick; its header starts at sector 16, so the image would have it at byte offset 16×2048, but if such an image is written to a 512-byte-sectored USB stick, this byte offset ends up at sector 64 instead – far away from where the firmware is expecting to find it!)
