An external 16550 UART, like this one, performs a conversion of the UART's serial data to and from parallel ports that can be read by a microprocessor/microcontroller. It is addressed as any external parallel I/O port, and has control registers for setting various modes, another for baud rate, another for status, one as a receive (Rx) buffer, and one for a transmit (Tx) buffer. (The Rx and Tx buffers may be tied through FIFO's, but that's the immaterial to this question. There are also other types of UART's that are accessed over I2C or SPI busses; that also has no bearing on the question.)
For received characters to have any effect on the microprocessor, a driver must be running that is responding to the UART. In addition, there must be a higher level of firmware that is communicating with the driver.
If you are running "bare metal", without an OS, then without code that explicitly writes to the registers in the UART to enable it for receiving data, nothing will happen. Even if the UART and receiver functionality is enabled, still nothing will happen except the character(s) will show up in the Rx buffer, and depending on the how the program is setup, the driver may or may not receive characters in an interrupt routine, where they will usually put into a internal software FIFO buffer. If there is no firmware to retrieve these characters, the buffer will just wrap around and overwrite itself.
If you are running on an OS, then you probably have to open the UART port to enable any receiving of data. Ports are almost never opened without explicit calls to the OS to do so. Even if this was done, if there is no firmware to handle the incoming characters, they will just be thrown away as the FIFO overflow. Nothing bad will happen, except that if characters are arriving at a very fast rate, then the UART interrupt handler will be getting called on every character and this will have some effect on your processor load. So it is best not to have the UART port open.
The only possible issue would be if the firmware both enabled the UART, and then enabled receive interrupts, and no interrupt handler was provided. Then when a character was received, the program would go off into never-never land. But this won't happen by itself, it would require the firmware to explicitly set things up to fail in this way. It would obviously be a serious bug to enable the UART and its interrupt capability and then not provide a handler.