From this, I'd say that anyone who used the backdoor would basically be able to take over the chip completely. Which is somewhat scary, considering the author says it's used in weapons systems—hopefully the author's informed an intelligence agency with the specifics.

The configuration is commonly stored in a small serial eeprom (tiny 8-pin chip) and automatically read when the FPGA powers up. The content of this chip is often called "bitstream", this configuration eeprom/flash is sometimes also internal to the FPGA.

The key this configuration is encrypted with is supposed to be stored securely inside the FPGA, but they managed to extract it using undocumented commands on the "debug port" (JTAG) that the vendor explicitly claimed did not exist.

Note: This is an interface that normally is not easily accessible from the outside, but sometimes connected to a microcontroller to update the FPGA configuration.

Theoretically someone who gets access ("normal" computer backdoor over the network) to such a device might be able to re-program the chip thereby causing malfunction or add a flaw deliberately. The second scenario would be to decrypt the configuration information, "decompile" it and learn about secret algorithms or functions.

From the description I'm guessing an interface device that does something in the order of I2C/CAN/M on one end and external comms to the outside world on the other (why else would require "sophisticated encryption standard").

First, we must understand what these are used in: embedded systems. Typically, at the heart of most embedded systems you have two possibilities: a microcontroller or microprocessor, or an FPGA. The microcomputers run some kind of firmware (instruction set fed to a processor architecture) which is completely different then an FPGA which are actually re-configurable transistor arrays to implement fixed digital logic. This transistor configuration is typically loaded from EEPROM on power up - so it is stored/uploaded by a user somewhere after they've done some work in their CAD tool.

In either case, whether it be firmware written for a microprocessor based system, or the "firmware" for an FPGA (I forget what that logic routing configuration format is called - technically not firmware since it's not instructions) it is likely that whoever wrote it would want to protect it from being read or protect their device from having another firmware loaded on. There are many schemes to do so, it is possible that this is what has been compromised.